Slashdot Mirror
5-Year-Old Linux Kernel Bug Fixed
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."
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.
If you ignore ACs because they are anonymous - you're an idiot.
'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.
are demotions or dismissal. let alone actual proof. in a four-year administration.
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?
count the # of remote exploits patches in each version of Windows and how many years between patches where the OS was vulnerable.
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.
Windows XP early on (until SP1 or 2?) was remotely exploitable in this way as I recall. And there have been other exploits just as bad over the years.
Heartbleed was a big deal but its not singularly bad. There's been others before it.
a "doe snot crash" sounds pretty bad to me. Just sayin'. Do you have deer hanging around your computer?
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.
If you ignore ACs because they are anonymous - you're an idiot.
Would that be the result of a 5-year-old following Explain Like I'm Five for a while and becoming smarter than the average public school teacher (see recent story about public school failure)?
The problem was well discussed in 2009 here : A tempest in a tty pot https://lwn.net/Articles/34382... The result was that after a heated debate, Alan Cox was blamed for allowing old code to stay because emacs would loose terminal output and Greg KH was simmoned to stepup as the TTY maintainer. The new TTY/PTY guys became James Simmons, the Frame-buffer guy and C. Scott Ananian, the former jack-of-all-trades for the One Laptop per Child Foundation. 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.
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...)
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.
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.
As I suggested in this thread here in Dec 2012: http://developers.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 architectures available, like from QNX, Erlang, Actor, or Smalltalk, and I had hoped those alternatives would prevail. I started using GNU/Linux only when it seemed like the social momentum there was unstoppable. Thus my previous comment on "message passing" as perhaps a better architecture for software in the 21st century because if can help address theses issues of redundancy, modularity, and testability as ways to manage risk from complexity."
It comes down to priorities. The Linux Kernel community seems to have historically prioritized maximum speed over things like security, reliability, ease-of-use, or even driver developer sanity (like statements of Linux leaders saying stuff like like APIs can be changed at will and it does not matter how much time it takes driver developers to deal with it). I'm not saying they don't care at all about these other issues, just that historically it was not a priority. If they did priorities these other things, then a message passing microkernel (more like QNX) makes more sense. Also, using a language with better bounds checking and such might also be valuable, however with a microkernel choice of language may not matter as much since most of the code for most drivers could be outside the kernel.
Anger often comes from fear. What is Linus afraid of? A big worry must be kernel getting severely broken by some contribution, That's what really sets him off into profanity. The more code involved, the more likely that can happen. I would predict that the amount of profanity Linus needs to use to keep the Kernel team in order is a good inverse metric of Kernel design quality relative to current needs. :-) And I'd suggest the amount of profanity needed is growing given the current design and current community needs and it does not bode well. :-(
Personally, at this point, I would *gladly* use a computer system that was half as fast but never crashed, never put my privacy or security at risk by bugs, never required a "recompile" just to install drivers, never had weird problems dues to incompatible versions of drivers it could not detect or manage, was ported easily to any hardware so it was truly universal, was easily upgradable indefinitely, was transparently networkable with other hardware running the same OS as one big virtual computer, which had a community of developers making new useful stuff instead of being pinned down by just keeping up with kernel API changes, and so on...
One of the reason Linux on the desktop failed is because of all these things and the pain all these continual changes to a monolithic kernel cause a general user and what a pain in the butt it would be to get any hardware installed and configured. Linux had tremendous amounts of goodwill and human time devoted to it, but it seems much of that got wasted on dealing with a monolithic kernel which meant at best that Linux computers worked 30% faster (or as fast as next years models would otherwise) -- but only when they worked, which was painful enough that people just abandoned Linux on the desktop. That is true even people like me who ran Debian as a desktop for about five years and eventually got tired of all the random breakage and moved to the Mac (maybe regretting it a bit now with Apple's new annual OS releases and developers abandoning versions from just a year or two ago...) -- and while some of the break
A 21st century issue: the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.