Slashdot Mirror
EFnet Paralyzed By Vulnerability
An anonymous reader writes "EFnet member Fionn 'Fudge' Kelleher reported several vulnerabilities in the IRC daemons charybdis, ircd-ratbox, and other derivative IRCds. The vulnerability was subsequently used to bring down large portions of the EFnet IRC network."
By crafting a particular message, you can cause the IRC daemon to call strlen(NULL) and game over, core dumped.
1998 called and want their attack vector back.
The world's burning. Moped Jesus spotted on I50. Details at 11.
This is the problem you get when your strings don't know their allocated size like in that ghastly language Pascal.
I wonder if the whole ancient IRC standard needs a steamrolling anyway. A lot of the new services are implemented by ugly hacks, bubblegum or bots. Things like registering a nickname, maintaining the administrators of a channel or handling netsplits, these could all be handled much more nicely. IRC needs a redesign from scratch...
Now I can finally get that nickname I have been wanting since 1999 !!
There has been a lot of work in this area with a few projects now... Microsoft's IRCX, then IRCNEXT, IRCPLUS and now atheme.org's IRCv3. IRCv3 is becoming the defacto standard at this point, supplanting the traditional IRC protocol, as almost all vendors that are noteworthy have adopted support for revision 3.1 of the protocol already.
Both Atheme and Anope can be interacted with via RPC from scripts allowing for web integrations. Also, there are immersive web clients which provide a lot of useful metadata to clients.
While you're at it, please redesign SMTP.
Disclosed how? by example?
Sounds like when I found that if you put %s in a CounterStrike player name, the client would crash when showing the scoreboard, I tried %s after I noticed "%dxxxxxxx%" became "32401xxxxxxx%".
I reported it to Valve as soon as I figured out what it was, but it was a fun few days until they fixed it, "Hey look at that guys name!", server empties as people hit tab to show the scoreboard. I was server admin anyway, but it still was fun.
"Anope can be interacted with via RPC"... Yes, Anope 1.9. That's the development release, though. As much as I'd like to share your idealized view of IRC becoming a better place (except for the fact that I definitely wouldn't want to create an IRCd from scratch these days -- linking protocol and especially these goddamn CAP negotiations are just as bad as doing SSL from scratch. Who had the idea of message intents anyway?), fact is that the majority of networks that use Anope (and there are, due to the fact that quite a number of admins believe that levels are easier/better in some way or that Atheme is too much work to set up) use the stable 1.8 version.
Unlike the 1.7 dev version, 1.9 has not been widely adopted. This is mainly due to the fact that Anope 1.8 does just nearly enough out of the box to be still considered modern services, it's more hackable due to being coded in C (writing a module in 1.8 is definitely easier than in the C++ using 1.9 version. It's also easier to make it a complete fucking hackjob in 1.8) and has a bigger modding community (see http://modules.anope.org/ for pretty simple proof of that).
Additionally, it's still a mystery to me how IRCv3 works as an organization. It's described as a "meritocracy", but who is calling the shots in the end? You, nenolod? If so, then I'm not sure if the description shouldn't be rather "oligocracy" but that's pretty bad for the image of anything these days.
Furthermore, I would like to point out that, while four major IRCds are part of IRCv3/implement it, a big part of the implementations (especially so in UnrealIRCd) have actually come from people in the working group (namely you). While that in and of itself can hardly be considered a bad thing, it does lower the bus factor for future changes to the protocol to... precisely 1.
I do, however, agree with your belief that IRC needs a change, but I believe this is heading in the wrong direction. This is just cleaning the protocol up a bit. What we actually need are radical changes, which you'd need to discard all the old diehard IRC brigade for. Analyze what is currently popular: Xat, Facebook, IMs. Observe how two of those are web-based. Does IRC have a web-based client? Yes, it does. Mibbit, qwebirc and KiwiIRC (as well as IRCCloud, but they are absolutely uncooperative with any network). Mibbit sucks downright and is missing the oh-so-important colors to today's generation for the most part. qwebirc is tied to a network each. While that might simplify the handing on the user's part (one website for one network), it still sucks as a client (same color issue as Mibbit, even) and the entire concept of a network just rapes the minds of users. Users today don't know and they do not WANT to know that there are multiple IRC networks. They just want a chat room. Centralization is key. You can't talk of "a Xat chat" or "the Facebook chat" or "ICQ" or "MSN (Messenger)" in the same way you talk about IRC because the decentralized nature is included in none of them (though, if Jabber had found broader adoption amongst non-techies, which will not happen because of this precise very same argument, that would be a basis to work off). KiwiIRC looks promising, but no network has webirc blocks for them yet. Facebook wins because everybody else is already there, not because their chat technology (or anything else for that matter) is particularly innovative or good. Speaking of centralization, having multiple clients and networks is just even more confusion for new users. There is no "the IRC client" and there is no "the IRC network". That is not what users want. Janus links are a step in the right direction (as ugly as they may be), but not a solution.
On the topic of webirc blocks, banning people on IRC is an ordeal. It is a brutal pain in the neck. Other systems may require and enforce registration, so banning is very easy: Right click -> Ban. Or at least they abstract the banning itself away in some manner. You can't do that on IRC. You'll first spend