Hacker News Reader

Comment by _rrnv | Hacker News Reader

Great work! This is my favourite type of vulnerability, simple, effective and brutal. Reminds me of a time two decades ago when with a friend from uni we theorised about a perfect server vulnerability where you’d exploit a machine by pinging it. And of course, two years ago it was in fact discovered as CVE-2022-23093.

View on HN

Ping of death was already a thing two decades ago.

https://web.archive.org/web/19981206105844/http://www.sophis...

This link doesn’t show me anything useful.

Try scrolling down. On mobile (maybe because of ad blockers) Wayback pages have a full screen of white space above the page contents anymore for me. This happens on pretty much every Wayback page I've tried. It's also relatively recent and I'm not sure the exact cause.

Try https://insecure.org/sploits/ping-o-death.html

It was actually almost 3 decades ago, making me feel extremely old - the period right at the end of '96 and into mid '97 when this was a popular way to cause mischief via IRC was truly a magical time

Hard to believe that during those times in IRC, you were used to automatically (and proudly) advertising your IP address, your exact client version, and the means for a direct connection to your client without any server in between (CTCP, literally “client-to-client protocol”). And all of that most often with no packet filter whatsoever, not even NAT, in between.

Everything was plaintext, including “authentication”, which was (at best) just asking the “ident server” on the same machine as your client who you claimed to be, which was considered sufficient because, after all, to run identd on its “privileged” low port meant you were an “administrator” (i.e. root of a unix machine).

CTCP messages still go through the server. DCC (direct client connection) are the p2p connections you are thinking of, but they of course don’t work behind nat.

I was behind NAT when I first got on IRC in ‘98. I set it up with ipfwadm.

Ah you are right, I mixed CTCP and DCC up. The former was also used to set up the latter I think? (Among other things.)

I joined IRC in the early 90s, there was no NAT then, packet filtering was uncommon, and practically nothing on the Internet was encrypted. It was a very different time.

Death on flaxxen wings

When I was in college circa 2001 we used to prank each other with the ping of death and other crash exploits. Also random IPs on the college network when we were bored. It was crazy how long it was around for and how easy it was to exploit.

DOS yes, but that freebsd cve I referenced is a theoretical RCE.

Back in the dial-up days you could disconnect someone by adding ATH commands to a ping payload field.

Only if their modem didn’t implement the Hayes command set properly or you could otherwise control the per-character timing of the OS sending. It required a pause (1sec by default), “+++” with no pauses, another pause, _then_ the ATH command

Which was fairly common, as Hayes had a patent on those pauses.

Huh, TIL. I guess they might have used TIES

https://en.wikipedia.org/wiki/Time_Independent_Escape_Sequen...

I had an external USRobotics 56k modem, I was immune. But the many many "bulk" no-name modems were vulnerable. You could ping entire ranges of dial-up IPs and watch the results on big IRC channels. Uhmmm, allegedly :)

Commas provided 2 second pauses

Only in the dial string to ATD, surely?

I remember you could brute force passwords by brute forcing in sequence single characters to access anyone’s disk on a giant dialup network. Crazy times.

I’m too lazy to look it up but there was some string you could send over IRC that would make some routers drop the connection immediately - if you pasted that string in a big channel you would see dozens of people immediately disconnect.

An 0x01 control character (CTCP) followed by

    DCC SEND whatever 0 0 0

https://modern.ircdocs.horse/dcc#dcc-send

This caused the DCC ALG helper in ancient Linux kernels to close the connection, as they failed to parse 0 as a valid IP address. Users connecting to IRC servers over TLS were immune, as the ALG helper in the router could not observe the traffic.

This is what breaks DCC in general -- to use DCC on IRC while connecting to the server over TLS and behind a NAT, you must instruct your client to use a specific range of ports for DCC and preforward those ports to your machine in your router, as the ALG helper cannot mark the incoming connection as RELATED (and forward it through to you) as it cannot see the outgoing command that caused the incoming connection to occur. You must also instruct your client to determine the correct external IP address to advertise, as the ALG helper will be unable to rewrite it when the router does masquerading.

On AOL in chatrooms you could play sounds, so if you sent S{/con/con As the sound, you could crash anyone on windows that hadn't shut off user sounds.

My memory is a bit hazy and I don't want to look up the exact sequence, but that's close enough.

https://mazur-archives.s3.amazonaws.com/aol-files/breaches/c...

it was `{S /con/con`; my memory transposed two characters. the {S was the "system message" that AOL chatrooms used to send sounds, so that sequence of characters after a newline made your computer look for that sound. It was cool if everyone was trusted to not do the /con/con, people would have email chains with the audio files on them, like a proto-napster.

Hilariously, the PPP (Point-to-Point Protocol) is still used in modern IoT modules. It is actually the only way to run your own TCP/IP stack (and maintain control over TLS), as not all modules support QMI or MBIM.

Reply on news.ycombinator.com