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 …

Silver badge
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.

2
18
Reply
Linux

Re: Not Again

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

20
2
Reply
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.

14
2
Reply
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.

14
2
Reply
Silver badge

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.

17
1
Reply
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.

9
2
Reply

Re: Not Again

Read the article properly, it was fixed in 2013.

3
2
Reply
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.

3
0
Reply
Silver badge
Stop

Re: Not Again

Gentlemen: Please do not feed the troll

3
1
Reply
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).

1
2
Reply
Silver badge

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.

1
0
Reply
Joke

Fools

If only it was written in C++

11
8
Reply
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.

8
6
Reply
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.

5
1
Reply
Silver badge
Joke

@AC Re: Fools

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

15
4
Reply
Thumb Up

@AceRimmer Re: Fools

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

4
1
Reply
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
0
Reply

This post has been deleted by its author

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
1
Reply

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.

4
2
Reply
Anonymous Coward

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

2
0
Reply
(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.

9
0
Reply

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.

4
1
Reply

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

1
0
Reply
Silver badge
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....

3
0
Reply
(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.

3
1
Reply
Silver badge

Re: Yay!

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

4
1
Reply

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.

0
0
Reply
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.

1
1
Reply
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.

7
2
Reply
Silver badge

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

1
0
Reply
Anonymous Coward

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

4
6
Reply
Def
Silver badge

Still using C today (or the C-Runtime Library in C++) has always baffled me to be honest. It's obviously not designed to be secure (yes, there are more secure variants of most functions these days) so I don't understand why people act so surprised when exploits like this are discovered.

6
6
Reply
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.

2
8
Reply
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.

6
1
Reply
Def
Silver badge
FAIL

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

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

You can blame the programmers all you want, but at the end of the day, your language/library of choice either allows programmers to make such mistakes, or it doesn't.

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", because at some point in time if someone can fuck up they will, and the easier it is for someone to fuck up, the more often it will happen.

You could be the best programmer on the planet, and you'll still make mistakes - probably on a regular basis. The more mistakes that can be caught before you even attempt to run your code the better.

2
6
Reply

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.

2
1
Reply
Def
Silver badge

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

I agree that the design goals of C didn't include security. Back then I'm sure people were too busy being excited about every little thing they invented. I totally get that.

But that brings me back to my original comment. Technology has moved on. Times have changed. We've grown up and matured as an industry and as individuals - well most of us have. Anyone can write software today, not just people who spend their days in labs wearing white coats and smoking pipes. And because of this, our tools and technologies need to mature as well. No longer should we be making it so easy for programmers to make what are, essentially, simple mistakes. Sure, the languages of today can allow access to hardware and allow programmers to overrun buffers, but these things should not be considered the norm. There should be better alternatives in place for 99.99% of the tasks developers need to perform.

A lot of C/C++ compilers these days can issue warnings if you use unsafe/legacy functions. Turn those warnings into errors and let's move forward together as an industry.

2
0
Reply

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.

0
0
Reply
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.

1
0
Reply
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
0
Reply

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

0
1
Reply
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....)

3
0
Reply
Silver badge

Re: Safe functions

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

4
0
Reply
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.

2
0
Reply
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.

0
0
Reply

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

4
19
Reply
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.

5
2
Reply

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

0
1
Reply
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.

2
5
Reply

Page:

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

Biting the hand that feeds IT © 1998–2018