Slashdot is powered by your submissions, so send in your scoop

 



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:
  • Sigh... (Score:5, Funny)

    by MightyMartian (840721) on Monday December 31, 2012 @06:18PM (#42437125) Journal

    1998 called and want their attack vector back.

    • Re:Sigh... (Score:5, Funny)

      by skovnymfe (1671822) on Monday December 31, 2012 @06:20PM (#42437147)
      It's retro cracking. Old is the new new, y'know?
    • by faedle (114018)

      A 1998 attack vector for a 1992 network.

      • You can still do this in a modern language... like C#/.NET

        string s;

        if (s.Length....

        blammo - you should have checked if s was null first... Oh, and use that fancy try/catch stuff, all the cool kids do!
        • blammo - you should have checked if s was null first

          Unless you're using Objective-C, where the "nil" is a special object that implements all messages (that is, methods) as a no-op that returns a nil.

          • by TyFoN (12980)

            Ugh, this really sounds like the way SAS responds when you try to access a field that doesn't exist. It will just create it and initialize it to missing value.

            I'm sure the objc solution is creating a _lot_ more bugs than it "fixes".

          • by v1 (525388)

            it's better to react to an error than try to ignore it. Though I think I'd prefer a log entry to a core dump. I prefer to write bulletproof code, and I frequently benefit from it. Just this morning in fact I got a warning email that a directory create failed on a script. It wasn't a shell crash, it was an authentic "assertion failed" routine of mine getting called to fire off an email, when an rm -d returned nonzero.

            It was something that "should never fail". ("so why bother testing the return code?") Un

        • by pod (1103)

          blammo - you should have checked if s was null first... Oh, and use that fancy try/catch stuff, all the cool kids do!

          The solution is *obvious* (duh), but the problem is not. You can't be putting an exception handler around every function call.

          What most likely happened, is by the time the string got to the strlen function, it was either assumed to have been security checked and data validated, or, the set of validations run was not complete.

          Shit happens.

        • by Hentes (2461350)

          The difference is, you can't catch a segfault in C++.

    • by waspleg (316038)

      You're laughing but I had to tell the developers of a small indie MMO, with-in the last year, that their ircd was vulnerable to remote exploits and it was running on the same thing that hosted the game itself, true story.

  • by cheesybagel (670288) on Monday December 31, 2012 @06:21PM (#42437153)
    This is the problem you get when your strings don't know their allocated size like in that ghastly language Pascal.
    • Re: (Score:2, Insightful)

      by cheesybagel (670288)
      Not to mention the whole C issue where pointers to something and arrays of something are sort of the same but not really.
      • by cheekyboy (598084)

        Yes too much management needed in C.

        Even if you had a *ptr holding the data type. You have to check.

        Pitty intel didnt implement string functions in the CPU.

        But damn, the libc guys should check input pointers themselves.

        • by Lunix Nutcase (1092239) on Monday December 31, 2012 @07:58PM (#42437767)

          Pitty intel didnt implement string functions in the CPU.

          They did. [pku.edu.cn] Welcome to decades ago.

          • by oursland (1898514)
            The Intel 8086 included string instructions. It was released in 1978, which puts these instructions back at 34 years ago. Decades? A third of a century ago!!!
        • by nedlohs (1335013)

          But damn, the libc guys should check input pointers themselves.

          And do what? Return a clearly wrong value so the caller can blindly continue? Burn some cpu on every call so that a broken caller can run a little longer and mysteriously crash later on or maybe just produce garbage output?

          That said, undefined behavior is undefined, if I was writing a libc it'd have to return 97 just for the heck of it.

          • Return 0, or -1? The fault isn't that of the libc developers, of course, it's the fault of the specification writers, who wanted to make it possible to save a few bytes. The other one that always irritates me is strcmp(), where it should be trivial to say that two NULL inputs are the same, but otherwise NULL comes before any other input and then you wouldn't need to bracket every single call in a NULL check. And since it's not part of the standard, even if one libc did do something sensible, you couldn't
            • by nedlohs (1335013)

              0 would be terrible, since it isn't a zero length string and that's lying to the caller. Crashing is a better option, at least you stop the damage there and then rather than the program generating garbage output. An exception is better still, but C doesn't have those - segfaulting sort of works as one if you squint.

              -1 isn't an option because the return value is a size_t which is unsigned.

              Sure it's far from an ideal setup, but C is language built on a philosophy that the compiler and libc should be relativel

            • by fatphil (181876)
              -1? *snigger*.

              And strcmp compares strings. NULL does not point to a string, therefore you shouldn't expect string functions to work.

              C expects the programmer to know what he's doing, that's all.
    • Re: (Score:3, Informative)

      by ls671 (1122017)

      An uncaugh NullPointerException on a call to aString.length() in java would have the same effect and kill the running Thread, the program if it is the main Thread.

      http://stackoverflow.com/questions/5796103/strlen-not-checking-for-null [stackoverflow.com]

      • Re: (Score:1, Flamebait)

        by cheekyboy (598084)

        Hmm

        Option 1 : 50 dozen try/catches every where making java slower, and coding more manual.

        Option 2 : If length() returned zero even on a null object, it still is sort of correct, the string is zero sized.

        Coding should be made easier not bloated.

        Should there be 100000000 instances of checking for pointer before calling strlen(), or should strlen() it self check for ptr?

        This is where libc sucks, so just make your own strlen() from libc, as a static strlen(), which behaves nicer. A length of a 'NULL' obj

        • Option 2 : If length() returned zero even on a null object, it still is sort of correct, the string is zero sized.

          null isn't an object in Java, which is where the problem is coming from.

        • by muridae (966931)
          So, you have a pointer to string S, and you want *S.length() to check whether S is null? Do you propose that all functions on null pointers return 0? If so, how would you determine if it's a null pointer, or if the answer really was 0?
          • by isorox (205688)

            So, you have a pointer to string S, and you want *S.length() to check whether S is null? Do you propose that all functions on null pointers return 0? If so, how would you determine if it's a null pointer, or if the answer really was 0?

            If (s==null)

          • This is exactly what Objective-C does. The method lookup function (objc_msgSend() and friends) contain a short-circuit path that returns 0 if the receiver is nil.
      • by Teckla (630646)

        An uncaugh NullPointerException on a call to aString.length() in java would have the same effect and kill the running Thread, the program if it is the main Thread.

        The JVM would continue running as long as there are running non-daemon threads. Whether or not it is the main thread is irrelevant.

        You are correct, however, that calling .length() on an object of type String that is null will throw a NullPointerException; however, it may or may not kill the current thread. It depends on whether or not the exception is caught, which is often the case, especially in servers where robustness is important.

        • especially in servers where robustness is important.

          Ditto for C/C++ applications "where robustness is important". Implementation looks different, but same in the essence.

          Some memory debuggers and code analyzers (Insure for example) can even catch the error during compilation (IIRC so called "wild pointers" in the Insure speak).

          Experience we made with HA software, null pointer problems are (often but only) nasty in C/C++ and are horrible in Java. Some stats. As new release went into tests/production, we found in total about 200 *crashes* due to null point

          • by Teckla (630646)

            Experience we made with HA software, null pointer problems are (often but only) nasty in C/C++ and are horrible in Java. Some stats. As new release went into tests/production, we found in total about 200 *crashes* due to null pointers in C/C++ apps. In Java part (about half the size of the C/C++) there were about 20 null pointer exceptions - with one which was occurring only in the production. This sole exception cost about 6 month of work to localize - because unlike core dump, Java's stack trace (due to your "which is often the case") was already unwound and couldn't point to the location of the show-stopper problem. This particular case (and it's not a sole Java debacle) became famous, because CTO of the customer, during a meeting, exclaimed that he wished the software was written in C instead, so that developers can see from core dump where the problem is.

            That's interesting. My experience has actually been the opposite. I spent a few decades programming in C, and about a decade ago switched to Java.

            In my experience -- which is, of course, just anecdotal -- C presented more difficulties. Core dumps are useful, of course, but it meant the entire process -- including all the threads -- went down. For high reliability requirements, we typically used a watcher daemon to restart processes that crashed unexpectedly.

            In Java, unless you go out of your way to catch Nu

            • Core dumps are useful, of course, but it meant the entire process -- including all the threads -- went down. For high reliability requirements, we typically used a watcher daemon to restart processes that crashed unexpectedly.

              We allow to start several instances of the same process: if one goes down, others are still there.

              However, I'm not recommending Java over C, or vice-versa, though. I consider the application domains where C and Java compete to be pretty small these days, so typically I consider the correct choice to be dictated by the application domain.

              In all fairness, I'm not a specialist in Java. Probably your experience is more relevant than mine.

              But I have seen already enough of spaghetti Java code to stop believing entirely the fairy tail of "better language will solve all problems."

              In Java, unless you go out of your way to catch NullPointerExceptions and then purposefully eat the attached stack trace, you should know precisely where and why it happened.

              Simple response: interface layer of libraries. It's pretty much given to find there some exception-munging code: after all we do not want to expose with exceptions the inna

              • by Teckla (630646)

                But I have seen already enough of spaghetti Java code to stop believing entirely the fairy tail of "better language will solve all problems."

                Easier/safer languages are a double edged sword. In the hands of a master, it makes the master that much more productive, because they're not wasting wetware cycles on details like "will concatenating this string overflow my destination buffer?". But, at the same time, it makes programming more accessible to people who really shouldn't be doing software development.

                I like to think I'm a good software developer and that using Java makes me more productive, but I readily admit that your average C developer is

                • [...] In the hands of a master, it makes the master that much more productive, because they're not wasting wetware cycles on details like "will concatenating this string overflow my destination buffer?".

                  Bad example.

                  A good sign of a non-master is attempt at concatenating string. Think of it, even Java *cannot* concatenate strings. :)

                  Contemporary C master wouldn't even think about it. Far cry from StringBuilder, but all the functions for safe string handling are already there - one only has to use them. (Although some thought might go into defining the limits for the buffers.)

                  Simple response: interface layer of libraries. It's pretty much given to find there some exception-munging code: after all we do not want to expose with exceptions the innards of the library.

                  This used to be a more serious problem, but fortunately, these days you can wrap an exception in a new exception and not lose the underlying stack trace. It's the common idiom now. For example: catch (IOException e) { throw new MyLibraryException(e); }

                  A link/name for the idiom I can pass to our Java people?

                  • by Teckla (630646)

                    A link/name for the idiom I can pass to our Java people?

                    I think I would just point them to the Java API documentation [oracle.com] and point out these constructors for java.lang.Exception:

                    Exception(String message, Throwable cause)
                    Constructs a new exception with the specified detail message and cause.

                    Exception(Throwable cause)
                    Constructs a new exception with the specified cause and a detail message of (cause==null ? null : cause.toString()) (which typically contains the class and detail message of cause).

                    These two additional constructors were added to Jav

      • It isn't a matter of checking every object.

        Just the ones that come from outside.

        That takes lazy^stupid to miss, not just lazy/stupid.

    • Re: (Score:2, Interesting)

      by nenolod (546272)

      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.

      • The main thing is that we need a language which provides scalable data structures, as servicing IRC messages involves many data lookups.

        Are you CTO per chance? VP of tech? You talk like one.

        But if you want it to be addressed in a programming language.

        Until language developers suck it up and start making languages that allow for opposite concepts in the same language, it would remain the same.

        For example.

        Most stupid errors in strict typed languages are in the code for some type weakness - because, duh, strictly typed languages provide zero standard facilities to implement weak typing when you need it. So you have to roll out your own

    • by Anonymous Coward

      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,

      • Re: (Score:2, Funny)

        by Anonymous Coward

        Can these solutions be used in a Hosts file?

        • That's not sporting at all. He actually posts something informative about something else and you troll him? OK, I'm known for teasing apk, but he does something positive and you try to pull him down? Not fair. Rachel. Not bloody Barbie or whatever, Rachel.

      • by ls671 (1122017)

        From your link:
        "It makes the function look complicated as it has multiple exit points (return statements)."

        hmm... you mix up 2 things. It is more like you add complexity by introducing multiple exit points.

        There is ways around it you know... Beginning your fucntion with a temporary variable set to NULL and returning that temporary variable in one exit point at the end of your function is one.

      • Where are my mod points now that your posts are on topic....
    • by Anonymous Coward

      This is the problem you get when your strings don't know their allocated size like in that ghastly language Pascal.

      I would have to say that is an outright falsehood and misunderstanding of the language.

      This is the problem you get when the programmer makes a serious error, who is the one and ONLY one who should be keeping track of the size of strings.

      The entire C language is based around the idea that the programmer knows best. That's why it doesn't do unneeded things for you a bunch of times for each call.
      So of course when the programmer does something stupid like not keep track of the size of strings, and pass what th

    • by BitZtream (692029)

      Yea, adding unneeded checks to every operation because of lazy/shitty programmers is a much better idea.

      Guess what, exploits happen in languages with managed arrays too!

      Languages can't fix shitty programmers or mistakes, deal with it and stop blaming the language.

      • by Rockoon (1252108)

        Yea, adding unneeded checks to every operation because of lazy/shitty programmers is a much better idea.

        I think the point that you are missing is that those checks are needed because the majority of programmers are both lazy and shitty once they are dealing with a large codebase. Here we have an obscure input causing the problem because its not obvious (lazy, shitty) that a variable might be null.

    • by Sulphur (1548251)

      This is the problem you get when your strings don't know their allocated size like in that ghastly language Pascal.

      At least in the case of Turbo Pascal, there is an allocated size and an actual size (length) for string variables.

    • Pascal is still a great language to learn how to code. I will never knock it.

  • Who needs security vulnerability when you have a complete lack of services and modern IRC features?
    • 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@ g m a il.com> on Monday December 31, 2012 @06:41PM (#42437279) Homepage

        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.org]. 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.

        • Re: (Score:3, Interesting)

          "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

      • by ls671 (1122017)

        Well, I still like the distributed design of it so keep it please. See picture here:

        http://en.wikipedia.org/wiki/Internet_Relay_Chat#Client_software [wikipedia.org]

      • by Vermyndax (126974) <vermyndax AT galaxycow DOT com> on Monday December 31, 2012 @06:49PM (#42437321) Homepage

        While you're at it, please redesign SMTP.

      • by mysidia (191772)

        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.

        • by nenolod (546272)

          MUC is extremely inefficient though. There is no multicast notion in XMPP, so MUC works around this by sending duplicate messages to each user directly.

          • by mysidia (191772)

            Jabber + PSYC [about.psyc.eu]

          • by dkf (304284)

            MUC is extremely inefficient though. There is no multicast notion in XMPP, so MUC works around this by sending duplicate messages to each user directly.

            That's also pretty much how IRC works (though the message formatting is rather different). For real efficient multicast, you need to implement it at the network level so that messages are sent directly to the other listening parties by the hardware, but IP multicasting is complex and full of all sorts of "interesting" problems when you use it at larger scales than the LAN. Re-transmitting messages (even with updated IDs and other such info) is far simpler in practice. Really.

      • by Anrego (830717) *

        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!)

    • Who needs security vulnerability when you have a complete lack of services and modern IRC features?

      Lack of services and IRC-features? Like what?

      • by nenolod (546272)

        EFnet does not provide NickServ or ChanServ, which is a common criticism of the network. Due to not providing centralized authentication or channel ownership services, the other aspects of the modern IRC protocol mostly do not apply.

        • by Krakhan (784021)

          Also when I checked there a year or so ago they still don't cloak the ip address on your hostmask like a lot of modern irc networks do now by default as well.

  • which projects are now going to close their doors to full disclosure? this was posted on the ircd's own bug reporting systems and was publicly visible. if it were not, and only the developers and higher level users (such as the nodes of efnet or freenode) should be able to see reports of this nature, this sort of attack may not have happened and the ircd's could have been silently patched without anyone knowing.

    on the other hand, if you close your doors, you obviously have something that requires hiding, dr

    • by nenolod (546272)

      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."

      • 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 Anonymous Coward

      You cannot "close your doors" to full disclosure, that doesn't make any sense. If someone wants to publicly announce a problem, they will always be able to do that. If someone wants to privately bring something to the attention of devs, they can always do that too. You cannot force people to use a disclosure method that they don't want to use.

    • by AndroSyn (89960)

      I don't see any reason to hide from bugs like this, people make mistake, code suffers from bitrot, etc. It's sure as shit embarrassing when a mistake in your code ends up on /. though.

      • by BitZtream (692029)

        Because EFNet is more or less non-functional since it was publicly disclosed?

        Because no thousands of people pretty much can't chat, because someone else like you was too short sided to understand that some actions have larger overall consequences?

        Because its fucking stupid to tell the world how to break something until its been fixed and thats only left for fucking jackasses to do.

        • by nenolod (546272)

          He did not disclose it, the person who disclosed the vulnerability did so in a public space for development discussion on charybdis. Once it was out in the open, we quickly jumped into action to start mitigating it across all fronts including EFnet. The ratbox developers were notified at least an hour before the exploit was unleashed, with a patch to deploy and everything, so really we did everything we could possibly do to mitigate the possibility of fallout.

          Once people started running the exploit on EFn

          • by BitZtream (692029)

            1 hour? Give me a fucking break. Doing it in public is as good as launching the attack yourself.

            The patch could have been discussed behind closed doors. If you wanted to get someones attention about the real threat, you could have popped a single server ONCE without making it public.

            Do you have any idea what its like running a network like EFNet and coordinating upgrades across all servers? Do you think there are admins awake and ready to be your bitch and patch their servers on your command in all time

            • by AndroSyn (89960)

              1 hour? Give me a fucking break. Doing it in public is as good as launching the attack yourself.

              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.

              The patch could have been discussed behind closed doors. If you wanted to get someones attention about the real threat, you could have popped a single server ONCE without making it public.

              Indeed the patch could have been discussed behind closed doors, but some

  • Great! (Score:5, Funny)

    by lemur3 (997863) on Monday December 31, 2012 @06:38PM (#42437261)

    Now I can finally get that nickname I have been wanting since 1999 !!

  • by AndroSyn (89960) on Monday December 31, 2012 @06:42PM (#42437285) Homepage

    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

  • They should change the name from EFnet to EFFYOUnet.

  • by seifried (12921) on Tuesday January 01, 2013 @02:12AM (#42439567) Homepage
    As per http://www.openwall.com/lists/oss-security/2013/01/01/3 [openwall.com] 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 [redhat.com] for details.

To avoid criticism, do nothing, say nothing, be nothing. -- Elbert Hubbard

Working...