5-Year-Old Linux Kernel Bug Fixed 127
rastos1 sends in a report about a significant bug fix for the Linux kernel (CVE-2014-0196).
"'The memory-corruption vulnerability, which was introduced in version 2.6.31-rc3, released no later than 2009, allows unprivileged users to crash or execute malicious code on vulnerable systems, according to the notes accompanying proof-of-concept code available here. The flaw resides in the n_tty_write function controlling the Linux pseudo tty device. 'This is the first serious privilege escalation vulnerability since the perf_events issue (CVE-2013-2049) in April 2013 that is potentially reliably exploitable, is not architecture or configuration dependent, and affects a wide range of Linux kernels (since 2.6.31),' Dan Rosenberg, a senior security researcher at Azimuth Security, told Ars in an e-mail. 'A bug this serious only comes out once every couple years.' ... While the vulnerability can be exploited only by someone with an existing account, the requirement may not be hard to satisfy in hosting facilities that provide shared servers, Rosenberg said."
This is the problem with Linux Security (Score:3, Insightful)
Linux and Greg K-H have both gone on record saying that security issues are just another type of bug, and don't deserve any type of special treatment.
This is crap. A bug that allows remote code execution or even a DoS is a much, much bigger issues than fixing the user experience or minor stability issues.
When you don't assign the significant to security issues that they deserve, they go unpatched for 5 years.
It's kind of a concern.
Re:This is the problem with Linux Security (Score:4, Interesting)
To expand on this, not only do they not assign security bugs the priority they deserve, they actively hide them.
http://arstechnica.com/securit... [arstechnica.com]
FWIW, I love Linux and used Slackware for almost a decade.
Re:This is the problem with Linux Security (Score:4, Interesting)
Re:This is the problem with Linux Security (Score:4, Insightful)
It's already trivial to do that. What would "clearly marking them as security vulnerabilities" gain?
Re:This is the problem with Linux Security (Score:5, Interesting)
Well it can't be patched before it was discovered but you seem to be implying this issue was known about 5 years ago.
How long from when it was discovered did it take to be patched?
Re: (Score:1, Troll)
The GIT entry for the bug was entered Dec 3, 2013. So that means at a minimum, the bug was known of and not fixed for 5 months. That's a bit excessive for 'A bug this serious only comes out once every couple years' kind of bug. I'll agree that 5 months is a lot shorter than 5 years, but it's still far too long.
Re: (Score:3, Interesting)
Was it? Where? The git commit linked in the article is for 2014-05-03. Given the number of fixes and revisions this patch went through, one has to actually hunt it down in the MLs to know.
So, can you please point us to the source of your information?
Re: (Score:1, Troll)
Given that the people in charge don't tend to disclose security vulnerabilities and actively hide them, it's difficult to say how long it was known for.
Re:This is the problem with Linux Security (Score:5, Insightful)
Taking off-topic potshots against FOSS in response to a misinformed post which incorrectly describes the date of the bug report in response to a post which inaccurately maligns the attitude of kernel developers towards security bugs?
For fuck's sake, we're three levels deep in FUD here. Someone throw me a rope so I can pull myself out of this quagmire of bullshit.
Re: (Score:3, Interesting)
The OP does not inaccurately malign the attitude of the kernel develops towards security bugs. Their stance is widely known.
Re: (Score:2, Informative)
Fact: FOSS proponents extremely frequently in the past claimed that OSS was security issue free because of all the review of the code that was happening.
Fact: The code shipped 5 years ago according to the story.
Fact: The story is about a security issue that shipped.
Therefore, pointing out that the proponents of FOSS are full of shit because a bug shipped is not off-topic for a story about a bug shipping in open-source software.
I was simply posting that the argument about when the bug was first reported is i
Re: (Score:1)
> FOSS proponents extremely frequently in the past claimed that OSS was security issue free
Nice strawman, there.
Personally, I'd say that the only frequently claimed advantage claimed for FOSS in the past was that it was, then, so niche that no one would find it worthwhile to try to exploit. Times have changed, now. For example: Firefox, Chromium, and, I'd say, even desktop Linux isn't safe anymore according to that criterion (server Linux never was safe, since servers are such juicy targets).
Re: (Score:2)
Sorry but your personal view is what others tried to point out as the advantage. The proponents claimed exactly what I wrote they claimed. Searching through Slashdot posts within the past 12 months find such claims.
Personally, I agree with your position on why most FOSS code has been exploited; that just doesn't fit what many proponents were claiming.
Re: (Score:2)
Here is an example of just such a claim and it is very recent. http://it.slashdot.org/comment... [slashdot.org]
Re: (Score:1)
>> So yes, I think their safeguards and failsafes extend beyond Windows Update and Norton.
>> Open sourcing their code reduces the black-box vulnerabilities well beyond that level to
>> begin with.
is the same as
> FOSS proponents extremely frequently in the past claimed that OSS was security issue free
eh?
I could analogously argue that your logical ability (which seems small), is zero. But I won't.
Small != zero, and conflating them can be a strawman argument, since it also means conflating
Re: (Score:2)
Fact: FOSS proponents extremely frequently in the past claimed that OSS was security issue free because of all the review of the code that was happening.
False. OSS proponents claim that OSS has less security issues than closed source software, and that they're easier to find and fix. Nobody ever stated that security bugs were completely inexistant. They're just fewer in number, and, usually, fixed faster.
Re: (Score:3)
Bugs have to be found, you can't expect every bug to just be easy to find. That's how things like Heartbleed, and the VDM bug don't get discovered for years. I'm sure there's probably bugs almost as old as Linux itself in the kernel, and i'm almost certain there's bugs in Windows affecting everything from 3.1 up.
But yes, i'd be very suprised if this bug was reported 5 y
Re: (Score:2, Insightful)
Well, in a normal situation, I'd say yes, but Linux's response to all bugs is similar, patch it as soon as there's a good patch. Now if it were a certain company in Redmond that scales its response based on customer "value", yeah, security bugs had best get fast-tracked. I honestly prefer the "fix all bugs and don't embargo fixes" response that linux does to the "when we discover bugs (heartbleed), we'll let the Cool Kids in on it first and then release it weeks later to the average user" response that Go
Re: (Score:3, Interesting)
You should read up some more on the clash between security professionals and the Linux maintainers.
Some bugs are more critical than others, and hiding them not to get negative attention or (rightfully) be pressured to fix them is pretty bad.
Re: (Score:1)
Don't see where your flamebait actually changes anything. It certainly provides nothing new, because you can say "they're rude" all day, the question is is the bug in question fixed, and when. Yes, the chances are very good that a bug submitter is going to get a "patch or GTFO" response. In the overall scheme of things, I'd say that's as good as can be expected, given many other groups respond with legal threats.
Re: (Score:2)
Excuse me, but what flamebait? I did not insult you or your argument, instead I made a valid counter argument.
Oh, and my point wasn't that the maintainers are rude. My point is that the security industry keeps insisting the the Linux team practice responsible disclosure, and they keep arguing there is no need or benefit.
Re: (Score:1)
Yes, the chances are very good that a bug submitter is going to get a "patch or GTFO" response.
Not my experience. If you report a serious bug wirth enough supporting information it's quite likely someone else will propose a patch.
Re: (Score:1)
Re:This is the problem with Linux Security (Score:5, Funny)
Re: (Score:1)
If you're going to be so anal to question an obvious typo, I guess I could ask what the point of your post is, as it only contains quotes.
Re: (Score:1)
Re: (Score:2)
It contained nested quotes. I see no text that can be attributed to you.
Re: (Score:2)
I agree security vulnerabilities are worse than simple bugs. However DoS is not. Our entire network infrastructure is already vulnerable to DoS, so vulnerabilities of this sort are just par for the course really.
Re: (Score:1)
Might want to check the GIT report again. To quote: ... which allows local users to cause a denial of service (memory corruption and system crash) or gain privileges by triggering a race condition involving read and write operations with long strings. ...
Notice that the bug permitted an easy denial of service attack. And with more effort a privilege elevation.
Re: (Score:2, Informative)
There's no such thing as "GIT report" mentioned anywhere here, only GIT commits and they're too recent...
Did you mean CVE? CVEs reservation dates don't correspond with bug discovery date - for example, CVE numbered one less than this one is not even created yet [mitre.org], but it lists the same "20131203" reservation date.
Re: (Score:2)
I'm not referring to any specific DoS, just DoS as a general class aren't necessarily security vulnerabilities, ie. specific DoS vulnerabilities might also be security vulnerabilities, but being a DoS vulnerability does not automatically also make it a security vulnerability.
Re: (Score:2)
Any bug that allows a remote attacker to compromise a system, be it stealing data or denial of service, is a security vulnerability. All DoS vulnerabilities are security vulnerabilities by definition.
Re: (Score:2)
You're missing the point: our network infrastructure is already DoS vulnerable. A remote DoS is just another drop in a full pool. To suggest that a DoS vulnerability "compromises" the remote system doesn't seem justified.
Re: (Score:2)
Fair enough, I think we're talking semantics here now. All I know is a lot of my clients do, and rightly so, consider DoS to be a security issue.
Re:This is the problem with Linux Security (Score:4, Interesting)
I completely disagree. The reason I use a OS is because its features work and it doe snot crash all the time, I could not care less if it were 1% more secure.
I gotta say (Score:2, Funny)
a "doe snot crash" sounds pretty bad to me. Just sayin'. Do you have deer hanging around your computer?
Re: (Score:2)
Do you have deer hanging around your computer?
Yeah, plenty of goldeer [wikia.com] and even a few eldeer [wikia.com].
Re: (Score:2)
Stability and security are not mutually exclusive.
Although if you care about stability, then you should also care about security since many malicious attacks can affect stability.
Re: (Score:2)
Although if you care about stability, then you should also care about security since many malicious attacks can affect stability.
True, but most stability problems do not stem from malicious attacks.
Re: (Score:1)
Look at the GIT entry. It was entered Dec 3, 2013. A few months earlier than "end of last month". Also the disclaimer on the GIT entry means that the bug could have been discovered even earlier, so the Dec 3 date is merely a "no later than" boundary on the discovery date.
Re: (Score:1)
And by "GIT entry" you mean "CVE entry", which clearly says "Disclaimer: The entry creation date may reflect when the CVE-ID was allocated or reserved, and does not necessarily indicate when this vulnerability was discovered, shared with the affected vendor, publicly disclosed, or updated in CVE."
Look at the CVE entry. None of linked documents are earlier than last month.
Re: (Score:2)
Your argument does not convince. Why reserve a CVE Id and sit on it for six months? Maybe there is a reason, I'm not familiar with how CVE internals work. Your argument is pointless without more support. Sounds like you don't understand the system you defend, which seems rather silly.
Re: (Score:2)
Re: (Score:1, Troll)
but this is open source and open-source proponents have always claimed in the past that the advantage of open-source is that the bugs are discovered by the thousands of pairs of eyes before they ship. So the truth is that this bug was discovered five years ago but not fixed. Either that or there is no inherent security advantage to open-source. Which falsehood have you been telling all these years, boys?
Re: (Score:1)
Re: (Score:1)
Re: (Score:1)
If you can't tell who was meant from the context, you should probably head on over to some other, simpler website. Perhaps Mac Rumors.
Re: (Score:2)
A bug that allows remote code execution or even a DoS is a much, much bigger issues than fixing the user experience or minor stability issues.
You are right, but it doesn't apply in this case. This was a privilege-escalation exploit, which means you already need an account on the computer to do anything.
It's still a problem and I'm willing to bet there are more of these in the Linux kernel, just because they're so tough to clean out.
Re: (Score:2)
The examples I used in my post were just that, examples. They were not meant to be specific to this story, as I think the issue is greater than just this story.
Re: (Score:2)
Any account would do. Even say, "nobody".
All you need is the ability to run an arbitrary binary, which a buggy CGI script is more than adequate. Basically, if you have a bit of shellcode, that's sufficient. Once you have that going, then you can easily exploit your way to more priviledges.
That said, for the time being we now have a good way to root our Android phones.
Re: (Score:2)
That said, for the time being we now have a good way to root our Android phones.
.......until you reboot. Unless you can get at the bootloader.
Re: (Score:2)
A bug that allows remote code execution or even a DoS is a much, much bigger issues than fixing the user experience or minor stability issues.
May be. But this particular bug does not allow remote anything. It requires a local malicious user. PFTFCVELITS (Please Follow The Fine CVE Link In The Summary)
Re: (Score:1)
> This is crap. A bug that allows remote code execution or even a DoS is a much,
> much bigger issues than fixing the user experience or minor stability issues.
You're not a security professional. You should have to put that in your sig file. The linux kernel is used in many different situations, and clearly some security problems only pose a risk in some of those situations. IE. a lot of embedded systems will never be vulnerable to this particular issue.
A bug is a bug. All bugs should be triaged an
Re: (Score:2)
A bug is a bug. All bugs should be triaged and then treated accordingly. You don't pretend a bug is more important because security is the flavour of the month.
But a bug which can be exploited to give a security hole necessarily deserves a high priority, no?
You're not a security professional
don't pretend a bug is more important because security is the flavour of the month
A bug which enables a remote attacker to compromise a server is necessarily a serious one, no? I really don't get what your point is with this flavour of the month thing.
Re: (Score:1)
Actually, I am a security professional, working for one of the largest security companies in the industry.
It's clear you are not however.
Re: (Score:1)
> Actually, I am a security professional, working for one of the largest security companies in the industry.
Hm, let me guess. You work for Microsoft, in the team developing Microsoft Security Essentials?
Re: (Score:2)
No Sir. I said a security company. Not a company with a security department.
Soooo..... (Score:1)
'A bug this serious only comes out once every couple years.'
....in the time it took to fix this bug they got two more just as bad?
One step forward, two steps back.
Re: (Score:2)
Oh don't worry too much about it.
It is only notable because everyone is desensitized about commercial software bugs.
Compare it to Windows. How many patches do they make which are major or critical each year?
Re: (Score:2, Insightful)
Compared to Hartbleed and this, I don't know of any of similar critical level and impact.
Any remotely exploitable bug that allows for remote code execution / priviledge escalation without user interaction is just as bad or worse.
After all, heartbleed was "just" a remotely exploitable memory "leak"; but if you have remote code execution, you can scan the memory and send home anything interesting; to the same effect as heartbleed, plus anything else you might want to do once you are running on the system.
Win
Re: (Score:2)
OpenBSD is and mostly always has been a joke.
"Secure by default" isn't the same as auditing a few core services and disabling the rest.
They do a great job of maintaining OpenSSH though.
5-year-old allegations (Score:2)
This is the problem with Windows Security (Score:1, Insightful)
count the # of remote exploits patches in each version of Windows and how many years between patches where the OS was vulnerable.
I owe it all to Explain Like I'm Five (Score:2)
5 year old tempest in tty pot (Score:4, Interesting)
Re: (Score:1)
Curious enough it were not Linux server systems like RedHat Enterprise who have been vulnerable for almost 5 years, but the popular Linux desktop distro's like Ubuntu.
Wrong. RHEL 5 isn't affected, it uses an old kernel. RHEL 6 is affected: https://bugzilla.redhat.com/sh... [redhat.com]
Re: (Score:1)
The old guy screwed up, was replaced, and the new guys screwed up too. Does that mean replace or do not replace?
Or just that you remember old news?
If the latter, stick to tagging dupes here.
POC doesn't work here. (Score:5, Interesting)
I read through the POC, it seemed safe enough to play with, so I've tried it out on a few different servers here (CentOS & Debian Stable). On the CentOS boxes it dies before it even gets started trying to overflow into a tty, and on my Debian machine it's been going for 5 minutes (using up to 90% CPU, but still leaving the machine quite usable), and still hasn't got anywhere.
This isn't quite the "instant ROOT ACCESS!" privilege escalation that scares keeps sysadmins up at night. (unless I'm missing something...)
Must mention microkernels (Score:3)
As something like this would be impossible with the driver executing in an isolated process. Memory corruption would still be possible of course (unless the driver was written in a secure language) but it would be local.
+1 -- must mention microkernels & even languag (Score:2)
As I suggested in this thread here in Dec 2012: http://developers.slashdot.org... [slashdot.org]
"One thing of concern to me about this (not knowing the kernel communications culture or the previous interactions of Linus and this maintainer) is whether the Linux kernel (and development community) has maybe reached some point where old development methods are breaking down in trying to support an every growing monolithic kernel approach? I initially [resisted] using Linux in the 1990s because I knew there were alternative a
Re: (Score:2)
The L4 family, QNX, K42 and Nemesis/Expert shows that the kernel/userspace division is enough.
In fact there are systems that doesn't have even two "rings" and are secure. One example is the Microsoft research Singularity that uses a secure programming language, another is the Go component design (can't find a link sadly) that uses segmentation combined with a light-weight processor abstraction for protection. There are many others.
The L4 kernel have switching times as low as some hundred cycles between comp
openbsd (Score:3)
Openbsd defines any potential security issue as a bug. Emphasis potential. The interesting actual exploits these days are sometimes 15 unexploitable glitches strung together.
The Linux kernel is oriented towards supporting all the cutting edge hardware. This is not going to make security very practical. Openbsd is, ah, stodgy. But what openbsd brags on is "no remote holes in the default install" not "no local exploits".
I think that Linus cannot fix this sort of issue. Theo could take lessons from Linus on nasty around systemd but Linus has not been consistently nasty and I think it too late.
Send Theo money.