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.
you do not know what you are talking about. the actual bug was disclosed in the IRC channel for charybdis. there was no "bug report."
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.
This is a good case of bitrot here, code that had made assumptions about what the other parts of the code were doing..and fail. Brown paper bag day for me on EFnet :P
Google wave?
While you're at it, please redesign SMTP.
Using error handlers, & two pointers (this goes for ANY array, & strings are just arrays of characters/array of char):
---
1.) You send two pointers into/@ the array/string buffer allocated, as follows:
2.) 2nd "double-sized" one (positionally) is ALWAYS double the size (position) of the 1st.
3.) When the 2nd "double size of the first" FAILS (& the err handler catches it, ala try-catch/try-except type constructs)?
4.) The error handler passes back the size of the 1st "half-size pointer" location, & doubling it gives you the size of the array/string!
---
* THIS COULD BE USED TO TEST THE SIZE OF THE ALLOCATED SPACE FOR THE STRING BEFORE WRITING TO IT, first!
** ONLY PROBLEM IS, original C & Pascal implementations DON'T HAVE ERROR HANDLERS like Try-Catch/Try-Except/On Error GoTo etc./et al that C++ &/or Object Pascal do!
BUT YOU CAN "RIG IT" for error handling ala -> http://blog.staila.com/?p=114
(@ least afaik - I haven't worked with THOSE languages in almost 20 yrs. & certainly not ALL implementations, more modern ones MAY... I don't even remember if there is a way of "rigging" that into them vs. structured error handling built into their compilers).
---
However - Delphi Object Pascal has this (but not sure on original pascal implementations though, been DECADES since I did Turbo Pascal for DOS even).
Then - Even C has strlen... & that could be used to check this "hole" they are having a problem with, don't ya think?
* Any takers on that? Should work, in theory @ least, on C strings & their size... because it does on arrays you don't know the length of!
Lastly?
STRAIGHT Pascal, for lack of a better expression here (not Delphi, that's Object Pascal) could be done the same since it has pointers & can do the same type of testing the string array buffer, & it too, by the by - since it has a LENGTH function that can determine the size of a string as well...
You can "bust my balls" on this one IF I am off, I didn't read the article, but... it's an idea here, that *MAY* work!
APK
P.S.=> And, there you are... & not that THIS really matters, but, ONCE YOU HAVE THAT - you can "Trim" function the string chopping off the rest of it leading or trailing: There's examples of that in C & PASCAL all over online!
(I know for a fact Delphi Object Pascal has trim/rtrim/ltrim type functions built in, and C++ has functions you can find even online for it, since I don't recall it being part of the "std. string library of functions" but it may be in diff. dialects of it though, like C++ Builder) if its blanks etc./et al...
... apk
IRC needs a redesign from scratch...
Sounds like a great idea... I even have an idea of what we could call the redesign: Jabber / Conference Room.
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.
Throwing C++ into the same category as C is a bit retarded, is it not?
Yeah, but redesigning something that has been around forever is hard (see: IPv4). Way too much legacy stuff out there dependant on the messed up way IRC works.
That said, gradual introduction of saner behavior is possible (see: Atheme/IRCv3).
If you build something from scratch you'll just end up with a potentially technically improved (or just broken in different ways) but largely ignored solution (and for this, see: jabber conference!)
Jabber + PSYC
What language would you advocate, exactly?
The *EXACT* same problem (abrupt program termination) would have plagued the software if had been written in either C# or Java unless exception-handling code was in place to prevent it. Not so coincidentally, the effort spent writing such exception handling code in C# or Java could just as easily be spent on a simple null pointer check before passing a value to strlen in C. Not to mention the fact that neither C# nor Java even existed when ircd was invented.
This was a flaw that exploited nothing more technical than programmer oversight, which can happen just as easily in software written in *ANY* language.
File under 'M' for 'Manic ranting'
only if you use it ,pretty much like a null ceack or a try catch;
Jehovah be praised, Oracle was not selected
As per http://www.openwall.com/lists/oss-security/2013/01/01/3 this issue was assigned CVE-2012-6084. Remember folks, you can get your CVEs in advance which makes life easier for everyone. Please see http://people.redhat.com/kseifrie/CVE-OpenSource-Request-HOWTO.html for details.
"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
EFnet was fixed within an hour or two for the most part. More importantly the hub servers were not impacted which helped with getting things working sooner.
Indeed the patch could have been discussed behind closed doors, but sometimes zero day things happen. The real question is how do you deal with it when it happens.
I personally fixed 4 or 5 efnet servers directly and got patches out to the efnet admin community pretty quickly. Neonlod also had patches out pretty quickly as well, sooner than I did actually.
TBH I'm surprised that it didn't happen sooner seeing that the bug had been there since 2004. The bug itself was a combination of errors. First was a code change that was supposed to do parameter count checking for the called function, however zero was put in for the parameter count that was required.
This didn't matter for a while though as the rest of the code didn't rely on that parameter count checking code. However when some additional code was added, it wasn't protected by the old code that didn't care about parameter count, but it expected that the new parameter count code was working(which it wasn't) thus a command with an empty parameter caused the core dump. Fail.