Forgot your password?
typodupeerror
Communications Security

EFnet Paralyzed By Vulnerability 156

Posted by Unknown Lamer
from the blame-c dept.
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.
This discussion has been archived. No new comments can be posted.

EFnet Paralyzed By Vulnerability

Comments Filter:
  • by jones_supa (887896) on Monday December 31, 2012 @06:33PM (#42437219)
    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...
  • by nenolod (546272) <nenolod@NOSpAM.gmail.com> on Monday December 31, 2012 @06:45PM (#42437301) Homepage

    This was a NULL-pointer exception, not a buffer issue. But I do agree that it makes more sense to invest in building IRCd software which is written in string-safe and pointer-safe languages. Mozilla's rust language [rust-lang.org], for example looks promising for use in IRCd. The main thing is that we need a language which provides scalable data structures, as servicing IRC messages involves many data lookups.

    However, it is easier for most people hacking on IRCd to just pick up a 2.8-derivative.

  • by Anonymous Coward on Monday December 31, 2012 @07:04PM (#42437411)

    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 [staila.com]

    (@ 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

  • by Kaenneth (82978) on Monday December 31, 2012 @07:26PM (#42437553) Homepage Journal

    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.

  • by IllusionalForce (1830532) on Tuesday January 01, 2013 @03:07AM (#42439741)

    "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/ [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

The ideal voice for radio may be defined as showing no substance, no sex, no owner, and a message of importance for every housewife. -- Harry V. Wade

Working...