PAUL

PAUL

nice thread :)

<prgbot> loling so hard at butt and nigger

Fixed the bug. When I restarted the IRC half the people joined back with the nicks you changed them too. Funny as hell.

For the record, you were only able to do that because clients are too lenient and don't respect DA STANDARD. A single newline (or even two in succession) isn't supposed to signal the start of a new command.

>>4
What happened for us, non-irc using people?

>>5
Nothing. All that happened in the IRC is that someone was able to submit messages with a newline in the right place so that other clients were made to believe the IRC daemon was sending them and he changed people's nicks to "butt", "nigger", etc, and made it seem like people were getting kicked, but they weren't really. Again, it was a problem with clients being too loose with message parsing, taking "\n" or "\n\n" as a terminator instead of strictly "\r\n" and nothing else.

Nothing was compromised and no access was gained to anything. IRCd functioned normally.

>>6
wow, that was lame
I guess this is why the person on /lounge/ some months ago said that someone changed his name and gotkicked
stupid clients should read da fuggin standard

>>7

some months ago

https://bbs.progrider.org/lounge/read/1390433896/50

Was just a few days ago. I thought they were trolling and I'm in the IRC 24/7 and I didn't see this happen in the logs so it was probably just the person who figured this out trolling anyway.

Regardless it's not possible anymore.

>>8
sorry, it was a typo
anyway, thank you _kike admin-kun

>>6
While this is a funny hack, how the fuck did the person find out? Did he bother reading the source code for those clients? how did you "fix" it? The only way to fix this is for those people on IRC to change clients. Which clients are affected?

>>10
I just made it so that anyone sending messages that aren't probably terminated (i.e., stray "\n" or "\r" in the messages) gets their connection killed.

From RFC 1459:

IRC messages are always lines of characters terminated with a CR-LF
(Carriage Return - Line Feed) pair, and these messages shall not
exceed 512 characters in length, counting all characters including
the trailing CR-LF.

Technically clients should reject a message that doesn't conform to that (one with a stray LF). I suppose CR, LF, and NUL aren't allowed in the message either, so the IRCd now behaves appropriately anyway. Things like ChatZilla only use LF instead of CRLF and apparently all clients just take an LF by itself as a terminator even though they shouldn't. There might be some shitty daemons around that only use LF and therefore clients have just taken the path of least resistance and only look for an LF.

As far as how they figured out, I don't know, just guessing and messing around? Had the insight to see if there were errors in the protocol parser, which was the part I was most likely to forget something on.