back to article BOO! Grave remote-code exec flaw in GNU C Library TERRIFIES Linux

Security researchers have uncovered a critical bug in the GNU C Library (glibc), a key component of Linux and some other operating systems, which could render countless machines vulnerable to remote code execution attacks. The flaw, which was discovered by Qualys and assigned CVE-2015-0235, is known as the GHOST vulnerability …

  1. Nolveys
    Unhappy

    Not Again

    This one is going to be particularly hard to fix, what with this giant cartoon blow fish floating behind me and making coughing noises all the time.

    1. John Sanders
      Linux

      Re: Not Again

      Nope, it is not going to be hard to fix, at all.

      1. Anomalous Cowturd
        Linux

        Re: Not Again

        Hard to fix?

        That will be why the updated libs were pushed out this afternoon to my Ubuntu, Debian and Centos boxes.

        You're right, that wasn't hard at all.

    2. Doctor Syntax Silver badge

      Re: Not Again

      "This one is going to be particularly hard to fix"

      Really? I paused reading when I got to the sentence that said fixes were available, installed them which took less than a minute, carried on reading and then went to the comments section where, of course, I found exactly the sort of comment I expected.

    3. sisk

      Re: Not Again

      This one is going to be particularly hard to fix

      Apparently not. It was fixed in Debian before you posted your comment. And, I might add, before I heard about it.

      1. Destroy All Monsters Silver badge
        Holmes

        Re: Not Again

        And then you start thinking about embedded crud with problematic glibc libraries out there that is not going to get any updates soon.

        1. Frumious Bandersnatch

          Re: Not Again

          And then you start thinking about embedded crud with problematic glibc libraries

          Embedded generally means you're not using glibc anyway. It'll probably have newlib instead, or maybe μClibc.

    4. rtfazeberdee

      Re: Not Again

      Read the article properly, it was fixed in 2013.

    5. big_D Silver badge

      Re: Not Again

      It was fixed in 2013, but not marked as exploitable and therefore not flagged as a must-have update.

      Hopefully all "modern" versions of Linux have this already.

      If you distro is older than 2013 or the version (2.2 through 2.17) hasn't been updated to 2.18 or newer, then you need to get it patched.

      1. Michael H.F. Wilkinson Silver badge
        Stop

        Re: Not Again

        Gentlemen: Please do not feed the troll

    6. Rick Giles
      Linux

      Re: Not Again

      Can I have my up vote back? I thought you were joking, but looking at the rest of the herds comments I'm beginning to think you are being serious. Gotta get my lemming on.

      That, or they REALLY can't take a joke (much like Windows Fanboi's).

  2. AceRimmer
    Joke

    Fools

    If only it was written in C++

    1. Anonymous Coward
      Anonymous Coward

      Re: Fools

      Because C++ is buffer-overrun-proof? Come on, if anything, C++ provides more ways for memory buffer errors. True, if you restrict yourself to a "safe" subset of C++ it is a bit more robust, but nothing prevents you writing that exact same code and compiling it in a .cpp file.

      1. Dan 55 Silver badge

        Re: Fools

        Nothing stops you writing a Pascal or Java program which links to glibc and calls strcpy either. Whether you would want to is another matter.

      2. tfewster
        Joke

        @AC Re: Fools

        *whoosh!* ----------------------->

        1. Michael Wojcik Silver badge

          Re: @AC Fools

          The problem with the Reg's "Joke Alert" icon, of course, is that a large segment of the IT practitioner population is known to be red-black-white colorblind. Thus they're unable to see the logo. If it weren't for their custom stylesheets, they wouldn't even be able to read the site.

          It's sad that the Reg has not yet made an effort to accommodate this common usability issue, perhaps with a confirmation step when replying to any post tagged with the JA icon. Flashing text in red block-capitals, as seen on many TV procedurals, is recommended.

    2. mythicalduck
      Thumb Up

      @AceRimmer Re: Fools

      Obviously some people missed the joke, but made me chuckle.

  3. This post has been deleted by its author

  4. Ragequit

    Lol I read about this on another site that certainly gave this a completely different spin. Good to see that El Reg has their facts straight.

  5. Flat Phillip

    This family of functions is obsolete and anyone needing this sort of feature should be using the more modern (and IPv6 capable) ones instead. The fact that exim is the default for some systems and is remotely vulnerable is a little bit of a worry, but the default setup of exim is to connect to the localhost only. That moves it from a remotely exploitable bug to a privilege escalation one (if its the default setup).

    Still, it should get fixed if you have vulnerable versions. Debian Jessie and Sid aren't so no need to update for me.

  6. Anonymous Coward
    Anonymous Coward

    So how does it bypass NX? Sounds like exactly the sort of thing it's meant to protect against.

    1. diodesign (Written by Reg staff) Silver badge

      Re: NX

      Probably ROP - return-oriented programming. Overwrite part of the stack so EIP/RIP is popped with an attacker-controlled pointer to some code in the executable or library, like, say:

      pop rsp

      ret

      This moves a previously attacker-modified value off the stack into RSP - congrats, you've pivoted to an attacker-controlled stack. Then return, popping another address for RIP from the evil stack. That points to another bit of code like, say,

      pop rax

      call [rax]

      ret

      ...and so on. Chain bits of code ("gadgets") that end in ret. Use a tool to find ROP gadgets to build up your own program from the stack until you spawn a shell over TCP. All the gadgets you're chaining together are in the executable-enabled text or library sections. NX can't help you here.

      C.

    2. thames

      There's a link to the detailed explanation posted halfway through the story (look for "Qualys posted complete details of the flaw on Tuesday"). Here it is again: https://www.qualys.com/research/security-advisories/GHOST-CVE-2015-0235.txt

      It's really convoluted and I must admit I didn't take the time to understand fully how they did it. They really had to jump through a lot of hoops to make it work. Apparently they tried a number of other programs besides Exim, but couldn't find a way to make any use out of it with them.

      I'm running Ubuntu 14.04, which is the current LTS for Ubuntu. It was not affected, I'm assuming because it's running a newer version of the library which had the fix already before release. The same appears to be true for Suse SLES 12. The same may be true for other releases which have come out in the past year.

      1. wdmot

        @thames

        I'm running Ubuntu 14.04, which is the current LTS for Ubuntu. It was not affected, I'm assuming because it's running a newer version of the library which had the fix already before release

        Correct, it was fixed on May 21, 2013 (between the releases of glibc-2.17 and glibc-2.18). Ubuntu 14.04 was released about 11 months later. Similarly, Fedora 20 and SLES 12 are not vulnerable.

        Qualsys say it was not recognised as a security threat at the time, so the fix wasn't put into current long-term releases such as RHEL 6 and 7, etc. So it seems those systems would be the main ones to patch. Perhaps many embedded systems as well -- binaries clockdiff, procmail, and pppd are vulnerable (and maybe others), but I don't know if they'd be running and remotely accessible.

  7. JakeMS
    Mushroom

    Yay!

    More server patching! :-D.

    .... but hey, at least it gets fixed eventually right? :-).

    Patiently awaiting the CentOS rebuild of the fix...

    Also.. not sure if article author is aware, but that picture is NOT Ghostbusters, that is ScoobyDoo....

    1. diodesign (Written by Reg staff) Silver badge

      Re: Yay!

      "that picture is NOT Ghostbusters, that is ScoobyDoo...."

      "Scooby Doo", that's a Casper the Friendly Ghost episode, right?

      C.

      1. Destroy All Monsters Silver badge

        Re: Yay!

        The one where Scooby hammers on the door, crying for Wilma?

    2. Number6

      Re: Yay!

      Patiently awaiting the CentOS rebuild of the fix...

      I just did a yum update on my Centos VM and it pulled in a new glibc so I guess they've done something.

  8. Ragequit
    Facepalm

    oO for the record that was not sarcasm. Read ars article on this and even ignoring the hype they are a little misleading with the facts. i.e. while it is true that lots of software was found to use this call and might be vulnerable they do not mention that the researchers *have* tested them and have not found a working exploit.

  9. John Sanders
    Linux

    The bottom line is that the bug was inadvertently patched 2 years ago, but that because it wasn't listed as a security patch, it didn't get back-ported.

    Patches have been already released for most major distros, vast majority of set-ups not vulnerable, nothing to see here move-along.

    Of course old crud may remain vulnerable, like... always.

  10. Teiwaz

    Not really news then?

    Not worth commenting on it, so I won't.

    The picture though. I thought it was a Scooby-Doo / Pacman joint cartoon/game/theme park/handbag and deodernt set. Then the Ghostbusters reference confused me, a little. I often deal with twentysomethings, and references which I grew up with are lost on them, so I shouldn't be surprised by confusion between the Scooby Gng and Ghostbusters, but godammit...

  11. Anonymous Coward
    Anonymous Coward

    Using zero terminated strings in C didn't turn out to be the best design decision ever, did it?

    1. This post has been deleted by its author

    2. Anonymous Coward
      Anonymous Coward

      re Using zero terminated strings in C didn't turn out to be the best design decision ever

      Why the downvotes? Seems a perfectly reasonable comment.

      C pretty much makes buffer overruns the default behaviour. Nice one K&R, nice one.

      1. Nick Ryan Silver badge

        Re: re Using zero terminated strings in C didn't turn out to be the best design decision ever

        C pretty much makes buffer overruns the default behaviour. Nice one K&R, nice one.

        No it doesn't. Shoddy programmers who don't check length parameters are the fault here.

        While the other copy functions perform the parameter checks for the programmer, checking the length parameters before calling the function and gracefully handling any problems is often a better solution than passing off the checks to the function.

        1. This post has been deleted by its author

          1. SecretSonOfHG

            Re: re Using zero terminated strings in C didn't turn out to be the best design decision ever

            "The design goals of any language (or coding standard for that matter) should include make it as hard as possible for people to fuck up"

            Make that your own language design goals, not the ones K&R had in mind in 1978. The design goals for C included it to be a systems language, one you could use to write an operating system. So the ability to do weird memory manipulations was built into the language by design, including the ability to overrun a buffer.

            You may change your argument and say instead that C was/is not a good choice for OS services and/or end user applications. Perhaps that's true today, but 20 years ago there were not that many options if you wanted to have good performance and run on many platforms other than using C.

            1. This post has been deleted by its author

              1. Number6

                Re: re Using zero terminated strings in C didn't turn out to be the best design decision ever

                Back in the day, a lot of stuff didn't have the degree of communication with the outside world that it does now so security wasn't such an issue.

                1. JamesTQuirk

                  Re: re Using zero terminated strings in C didn't turn out to be the best design decision ever

                  "Back in the day, a lot of stuff didn't have the degree of communication with the outside world that it does now so security wasn't such an issue." ..

                  Thats the nuts of the Problem, Windows was a stand alone OS in beginning, I know cause I was using it, trying to teach others, my C64, I had @ home to play with, had better communications software & easy to use hardware @ times .. They have been patching - adapting - mending - expanding - upgrading the same core Philosophy, now really still in use, sorry but it needs more than a restart, maybe a rebore, or a new donk !!

                  Ms should have taken Crapples fix, and swallowed a linux dist as its new OS, and really did a proper job on user interface, backward compatibility issues, FIXING LONG TERM BUGS & just not making it look "pretty" & a "Spyware OS". Maybe MSX was already used when incorperated the Amiga's Chipset Features in their CPU & Boards, after helping to kill Commodore ....

                  I know the many issues that keep people using windows, but it boils down mostly to " it's what I have always used & my old stuff works ...", well sorry change is good, sometimes, and running wine on linux gets past most for me, a industrial strength VM may be required for some, the thing is it could have been sorted out, and MS would still be the industry lead, BILL saw the light & cashed in his chip's, & then he turns out to be a nice guy, after all the abuse I hurled while inside a PC's MS OS, fixing things ...

        2. Michael Wojcik Silver badge

          Re: re Using zero terminated strings in C didn't turn out to be the best design decision ever

          While the other copy functions perform the parameter checks for the programmer, checking the length parameters before calling the function and gracefully handling any problems is often a better solution than passing off the checks to the function.

          Agreed. I take issue with this bit from the article: "strcpy() is dangerous and an obvious target in an audit because it blindly copies the entire contents of a zero-terminated buffer into another memory buffer without checking the size of the target buffer."

          At least one C expert, Richard Heathfield, often argued that strcpy() isn't dangerous, because before calling it a well-written application knows whether the destination is too small, and knows how it wants to handle that case. Using, say, strncat() instead1 just means you've decided that silent truncation is the appropriate way to deal with the issue. But it almost never is.

          That said, I can't entirely disagree with those who say that programming languages should be designed to reduce programmer error (and account for the programmer's inclination to laziness). The simple fact of the matter is that C is not particularly well-suited to large, general-purpose computers running untrustworthy code and receiving malicious input. Decisions that (as I argued above) were often good for the PDP-7 and even the -11 are not the best for many of the platforms where C is used now.

          I write more C than any other language, though I use others substantially as well, and it is possible to write C code that is robust and resistant to attack. Learn the standard, particularly the non-obvious bits; study common vulnerabilities; refactor common functionality into higher-level operations that you can use in your main logic, so you can deal with the Standard Library's primitives safely in just a few places. But that requires a degree of discipline that few developers seem amenable to.

          1strncat() because strncpy()'s semantics are hopelessly broken. strncat's aren't great, but they're not nearly as terrible as strncpy's.

    3. Michael Wojcik Silver badge

      Using zero terminated strings in C didn't turn out to be the best design decision ever, did it?

      Certainly a number of people have advanced substantial arguments that in-band signaling is one of C's greatest faults. Lynn Wheeler made a number of them on Usenet (primarily in alt.folklore.computers) in the '90s, for example, and more recently there was Poul-Henning Kamp's controversial "The Most Expensive One-Byte Mistake" in CACM.

      As with two-digit year storage in many old applications prior to Y2K, though, it was arguably the correct decision at the time, given C's purpose and provenance.

      A more-sophisticated critique would be that:

      - strncpy() is fundamentally broken, and makes it more difficult for programmers to handle the issue properly. ANSI should have corrected the semantics of strncpy in C89 and to hell with extant code, very little of which would have been affected anyway.

      - After the initial C89/C90 standard, WG14 (the C standards committee) should have developed an extension to the library for safer string handling. WG14's position was that they were going to emphasize standardizing existing practice, but since C94 gave us such jems as trigrams, there was probably some wiggle room.

      - Better static diagnostics should have been used in every C implementation. Peter van der Linden rightly complains about the separation of lint from cc; that attitude pervades most C implementations to this day.

  12. Sceptic Tank Silver badge
    Unhappy

    Safe functions

    This is amazing. Still not using strncpy() or strcpy_s()? Or even better: std::string? (Although that would require broadening one's horizons...) Shouldn't it be a compile-time error by this time to use such archaic unsafe functions?

    (Mutter, mutter, mutter ... some people still driving ox carts in the space age....)

    1. Dan 55 Silver badge

      Re: Safe functions

      I read that as OS X carts but then again I've never liked Objective C.

    2. Chairo
      Happy

      Re: Safe functions

      Well, yes, the oxcart is retired now, but you have to admit, the A-12 was a cool piece of technology.

    3. Michael Wojcik Silver badge

      Re: Safe functions

      strncpy() is fundamentally broken. If you don't understand that, you shouldn't use it; if you do understand it, you won't.

      At the very least, using it requires an extra assignment afterward, possibly causing expensive cache or page effects, as well as cluttering up the code.

  13. JamesTQuirk

    yeah, and everytime MicroCrap releases another try @ a OS, there will be clickbait acticles like this, about a old bug in linux, that has been dealt with already, except by crapple & others ....

    the death throws of MS's Bloated Beast will take a while, especially now with Cortana, a 3d rendered paper clip with tits, least they will have company as they continually scan for virus's ...

    Hmmmm, maybe a personality virus ? or just mirror so cortana can see how system fat she has become ...

    1. Spasticus Autisticus
      Happy

      The new MS shill downvote bot accounts really don't like your '3D rendered paperclip with tits' comment, made me laugh out loud, its both funny and true.

      1. JamesTQuirk

        I think the trouble these "Cortana Slaves" they will create, instead of them using, will the PC be driving them, to shop ? (Amelda Marco's Virus, Cortana keeps ordering shoes from ebay !)

        These Windows People are INVESTED in it, they don't want the OS to go, they are unable too because, they paid MS bulk money for a certificate to say, they can use their "easy to use" system. All the software Licenses they got (or got the Boss to Pay for) for Win7/XP, I think if Microsoft wants to give 10 away, maybe, they should refund Win7 Government & Corporate users .....

        I saw same thing, long ago, "What do need 64K ram for, if u can't do it in 32k" a VIC20 person said to me, about the C64, I had just bought ...

        8" FDD became 51/4", Horror !!!, then 3" (amstrad), 3.5" everybody else, now it's USB ...

        The whinging when AmigaDos went from 1.3 to 2.1 ....

        CPM

        Windows2.0, & Dos 4.1 ?

        Windows3.0

        Vista .......

        and lost count of how many different Programming languages I have used in last 43 years .....

        The list of the retired is long, (me being part of them), these MS-Junkies will fight to keep what they know, as they are obvoiusly too thick&stupid to learn anything new, they now need thier PC is to "tell" what to do/buy/watch, and that they have friends ......

        i

  14. sabroni Silver badge
    Mushroom

    But it's holding off on making the attack code public, it says...

    ...until the vulnerability is no longer an immediate threat.

    No, you get 90 fucking days, that's your lot! C'mon, I know everyone on here agrees with this, I read it under an article about an MS vulnerability.

  15. Anonymous Coward
    Anonymous Coward

    Another shallow Open Source bug.

    So this vulnerability was only in the codebase from 2000 through 2013, eh? Good thing that the many eyes of Open Source mean that all bugs are shallow, or this could have hung around for a really long time.

  16. Daggerchild Silver badge

    Fuzzy Wuzzy

    How many apps have been found that *actually* crash to this? The exploit conditions are more delicate than a snowflake.

    Exim.. anything else?

  17. Colin Tree

    Slackware

    Slackware 14.1 has an upgrade for glib 2.17, etc.

  18. Ben Liddicott

    And your cheapo router

    When's that getting updated?

    I know routers weren't mentioned, but I'll bet they are vulnerable.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like