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.
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 …
"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.
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.
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.
This post has been deleted by its author
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.
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.
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.
@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.
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.
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.
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...
This post has been deleted by its author
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.
This post has been deleted by its author
"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.
This post has been deleted by its author
"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 ...
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.
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.
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....)
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.
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 ...
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