The Linux kernel has been purged of a bug that gave root access to untrusted users – again. The vulnerability in a component of the operating system that translates values from 64 bits to 32 bits (and vice versa) was fixed once before – in 2007 with the release of version 220.127.116.11. But several months later, developers …
** Sigh **
This is what happens when you develop an operating system that purports to work "the same" across multiple architectures: It doesn't.
By looking at the code for both the bug and the exploit, they each appear to be heavily x86-32/x86-64 dependent.
I would venture that there is a high degree of probability that this bug/exploit combination does not exist, for example, in versions of the Linux kernel developed and compiled for IBM's midrange (AS/400 / System i / System p) and mainframe (S/390 / System z) iron, in versions of the kernel developed to work on Cell-based parallel processing systems, or in versions compiled against SPARC machines.
This leads me to believe that it is perhaps the x86-32/x86-64 architecture that is at fault, at some lower level, for not properly securing access to 32-bit facilities provided by 64-bit processors. This kind of bug could **conceivably** be used to compromise Linux-based x86 hypervisors, by allowing an intruder to context-switch out of the virtual machine and into the host OS.
Granted, the fact that a regression of this magnitude was re-introduced into the Linux kernel is regrettable, but it isn't difficult to understand how such a mistake can be made, given the kernel's rather heterogeneous target audience. No one person, or group of persons, can be an expert on all of the different processor architectures supported by the Linux kernel.
No frickin title
"This leads me to believe that it is perhaps the x86-32/x86-64 architecture that is at fault, at some lower level, for not properly securing access to 32-bit facilities provided by 64-bit processors".
I have a different suspicion, having just written (with some difficulty) a device driver that runs on i686("x86_32")/PAE. It turns out that, on x86, a significant portion of the driver core was written specifically on the x86_64 branch, completely separately from mainline x86. It wasn't back-ported, and x86_32 has significant problems, particularly if you're on PAE. This is made much worse by the fact that the 'documentation' and the relevant book are several years old, and talk extensively about features which the reader assumes will exist on any current kernel, but which in fact didn't work on the most common port at the time, and still don't.
In short, I'd be surprised if the processor is the problem here. Linux is my preferred OS, but it's obvious that there are significant management failings in the kernel development.
You're assuming that IBM/SunOracle by default would be "safe" by virtue of being different, this is an argument from obscurity, in reality the is more scruitiny of x86/x64 because of the availability and number of installations so issues are more likely to be found, these less common architectures aren't somehow magic. I would concur that this particular bug/exploit/weakness probably doesn't exist (byte order might, for example affect it), but that doesn't mean there isn't something unique to these architectures that x86 doesn't have.
The "heterogeneous target" excuse is also faulty, for example, the 10 year old bug in SPARC Solaris that allowed direct root login using telnet was re-introduced into Solaris 10, OK telnet is old hat and probably not active on most Solaris 10 installs, but it's just a well publicised example.
> You're assuming that IBM/SunOracle by default would be "safe" by virtue of being different...
In this case, yes. Given an examination of the code, there seem to be a considerable number of explicit references to x86-32-specific and x86-64-specific registers and features (%rax, %eax, %ecx, %edx, %rsp, etc.), which would obviously not exist on POWER or SPARC architecture CPUs.
> The "heterogeneous target" excuse is also faulty, for example, the 10 year old bug in SPARC Solaris that allowed direct root login using telnet was re-introduced into Solaris 10
I disagree on this point. telnet is an application, and so is not inherently architecture-dependent at the source-code level.
The x86-32/x86-64 call stack translation subsystem, being a hardware-oriented component of the Linux kernel specific to the x86 architecture, **is** architecture-dependent at the source-code level. This makes it very likely that this bug would not be reproduced in Linux kernels compiled against other CPU types.
You know the noise "facepalm" makes?
That's really more of a *headdesk*.
"This is true, but the existence of vulnerabilities like these are a big deal in corporate, government and educational environments, where Linux is a mainstay. "
Well, I find the above flattering to the Linux community. Which is great. But can it be supported with some proof? Wouldn't something like "where Linux has a significant user base" or "where Linux is deployed in significant numbers" been a more defensible position?
Linux IS A Mainstay
Deutsche Börse - leading derivatives platform - soon all Linux
Google - all Linux
Facebook - all Linux
CERN - leading end-the-world-fear-attractor/Master Proton Smasher - all Linux
Android - Linux
countless faceless devices like DSL routers - Linux
Even though the financial sector has the money to buy from IBM and MS, they have discovered that it makes much more sense to go with the Google approach (hire smart and expensive people, use Linux and other FOSS).
Adobe, MS and Oracle demonstrated this year that their ability to adapt and fix problems is comparable to the ability of a slug to cross a highway. Eventually they will make it.
Linux fixes exploits in two days, normally. Now somebody fixed Adobe's crap with a hex editor. They don't manage even though they have the source. I guess their developers don't have time for that because they busily update their "personal performance metrics and professional development" Excel sheet. If they are not held up by a "global business intelligence meeting". Or by fixing their Visual SourceSafe code-fermentization&decomposition facility.
I once worked for Quark, and they did use VSS.
Can you cite a few sources for your linux use? I know for a fact that Google are pretty heavy Windows users, their servers may well be linux, but do you remember the rather large hack from China earlier in the year?
CERN and Other Scientific Linux Users
Tokio Stock Exchange
Facebook & Linux
Google and Linux
AFAIK, all servers at Google are Linux. I interviewed with them and Windows was never asked about. But questions like "how do you kill a process if the max number of processes is executing" ?
Deutsche Börse & Linux
@Fraser: Don't need a source, just a brain.
Given the kind of computing power needed to do the indexing Google does to support as many users as Google does, if they were paying MS for even a significant minority of their servers, MS would be a far more profitable company than it is.
Some sources of Info...
As I understand it the hack attack on Google was not their public search engine servers et all but against the corporate infrastructure, i.e. the network of desktop machines used in the corporate offices. See http://techcrunch.com/2010/01/12/google-china-attacks.
Google has also been reported to be kicking Windows to the curb in its corporate infrastructure. See
for more on that one.
@Tom - I do have a brain, my brain says to me that the hack of Windows machines that was plastered all over the Internet a few months ago suggests that Google are Windows users. I made no statement suggesting that they are exclusively Windows users, which would be idiotic as they are obviously heavy Linux users. Many companies run heterogeneous networks, it's very rare to find companies which use a single OS/Hardware platform.
@Stephen - Thanks for the serious reply...
"valid account on the machine" is stretching things a bit
let's say your linux PC is a mail server, and it scans incoming mail for viruses. Let's also say there's a bug with the archive tool you use, meaning a malformed archive can be used to execute code on the machine (it's happened)
congratulations, you now have a "valid account on the machine" and can use this exploit. see also: anything that manipulates images, and a malformed image, etc. etc. etc.
you don't need to have SSH access; you just need to be able to run commands on the machine
Grows and changes every three-ish months.
Not to diminish this as having significance, but the Linux kernel is the largest software project on earth... it is always changing... that kind of makes it a moving target as far as exploits are concerned.
Currently it is at 2.6.35.x I think. The system is inherently safe anyway.
> The system is inherently safe anyway.
Not sure what you mean by that... No computer operating system, application, or platform can be called "inherently safe" unless it was specifically designed for safety from the ground-up. Very few general-purpose, consumer- and commercial-grade operating systems and platforms fall into this category.
Telco-grade Class 4 (4ESS) and Class 5 (5ESS) circuit switching equipment, certain automated railroad signalling systems, some types of industrial control equipment, and various medical device control systems fall may fall into the "inherently safe" category, but your home or office PC, even if it runs Linux, most assuredly does not.
I'm an ardent GNU/Linux supporter, and have been using it almost exclusively as my OS of choice for the better part of 10 years now (none of my home PCs run Windows or Mac OS X). Even so, I would be foolhardy if I trusted it to be "inherently safe."
While I do believe that GNU/Linux-based operating systems are **safer** in many ways than Windows and Mac OS X, I have seen my share of GNU/Linux boxes crash-and-burn (figuratively) because of poor configuration, lackadaisical patching, improper oversight, and yes, even the not-so-occasional bugs (both new and regressed).
> The system is inherently safe anyway.
You're not related to Steve Jobs are you?
General purpose, inherent safety
To clarify my earlier position: That is not to say that general-purpose computing systems with inherent safety don't exist. They do; they're just not very common.
One general-purpose computer design that **may** be considered "inherently safe" -- if properly implemented -- is a so-called "Harvard architecture" machine. This type of computer has physically separate data and code (program) buses and memories, so data can't grow to overwrite code, and code can't grow to overwrite data. The IBM ASCC/Harvard Mark I was the basis for this type of design. Modern examples of this kind of architecture include embedded systems based around AVR (Atmel Corp) and PIC (Microchip Technology, Inc.) microcontrollers.
"... the Linux kernel is the largest software project on earth... it is always changing... that kind of makes it a moving target as far as exploits are concerned."
Yes indeed, if all existing installations are patched or upgraded as soon as the new version is available.
What percentage of installations still use the original vulnerable kernel? What percentage use the first fixed kernel? What percentage use the second vulnerable kernel? What percentage are going to be patched today with the fixed fixed kernel?
How many users (home or business) actually upgrade the kernel every three-ish months?
It might be a moving target, but if it's a mile long it takes a minute to pass through your sights at 60mph... plenty of time to get quite a few shots off...
RE: General purpose, inherent safety
There have been some more general purpose examples of "Harvard architecture" machines, one example was the souped up StrongARM cpu released for the Acorn RiscPC.
I remember at the time a number of apps/utilities falling over as their self-modifying code tricks would no longer work (one legit use was executables that would self decompress and run back when hard drive space was a lot pricier).
I don't know if any of the subsequent ARM designs continued to make use of this or not.
To answer your question...
The ARM7 is von Neumann; the ARM9 is Harvard.
Just-In-Time Compilation is a modern case which Harvard architectures can't handle, either. Basically, any program that builds or modifies code to be executed on the fly (IOW, a program that necessarily blurs the code/data divide) cannot work in a Harvard architecture.
Your Stack is still unprotected, as the program *must* be able to change it. It is a bit more complicated, but still possible. Stack smashing does not necessarily include injecting machine code.
there is a
int exec_shell(char* cmd);
function. All you have got to manage is to put "rm -rf /" on the stack, change the return address to the function above and you are set to delete the whole file system of that machine (assuming it is a root process).
This is just one of the simple examples, btw.
Harvard architectures are not guaranteed-secure
Just because the data and code memory sections do not overlap does not mean it is impossible to attack a Harvard architecture machine. While they make it much less likely to *accidentally* break the machine by overwriting code, it is still possible to use code that already exists to form programs. For instance, appropriately changing function return addresses to take you into very specific parts of known libraries, then forming those bits of known code into programs.
For reference, see "Code Injection Attacks on Harvard-Architecture Devices" by Francillon and Castelluccia at the 2008 ACM Computer and Communications Security Conference. You might also be interested in looking into return oriented programming, e.g. "The Geometry of Innocent Flesh on the Bone: Return-into-libc without Function Calls (on the x86)" by Hovav Shacham at CCS 2007.
title, I don't need no frackin' title
1/2 mile @ 60mph=1/2 minute
> Just because the data and code memory sections do not overlap does not mean it is impossible to attack a Harvard architecture machine.
I never indicated that attacking a Harvard architecture machine was impossible. I indicated that Harvard machines may be considered "inherently safe," depending on implementation.
Hence the " **may** be considered 'inherently safe' -- if properly implemented " bit.
It should be kept in mind that some of the more modern Harvard architecture machines are microcontrollers in embedded systems, which are (generally) more readily hardened against code infiltration and code rewriting attacks, by virtue of requiring the chip containing the software to be physically removed and mounted in an EEPROM programmer to modify the programs stored within.
However, even this level of protection only gets you so far. Not even a Harvard machine will stand up to a highly sophisticated attack, if the attacker can gain access to the processor's address and data buses, divert the bitstreams to an external system for processing and analysis, then inject specially-crafted data back into the system.
A given system can therefore only be considered "inherently safe" with regard to the purpose for which it is designed. A microcontroller implementation which is suitable for telco use, and considered "inherently safe" by the telecom industry, may not be suitable for running a nuclear missile launch control system. The device is thus "inherently safe" for one application, but not another.
Current Linux Version
> Currently it is at 2.6.35.x I think.
Actually, as of today (Friday, September 17, 2010), the current version is:
Linux Kernel 2.6.36-rc4-git3 (includes the patches for the most recent exploit)
I just downloaded applied the patch, compiled and installed it on my box.
[ejm@Galicja ~]$ uname -a
Linux Galicja 2.6.36-rc4-git3-ARCHMOD #1 PREEMPT Fri Sep 17 13:17:59 CEST 2010 x86_64 Genuine Intel(R) CPU 575 @ 2.00GHz GenuineIntel GNU/Linux
Patch Promptly Applied
> Yes indeed, if all existing installations are patched or upgraded as soon as the new version is available.
Patch applied and kernel upgraded.
[ejm@Galicja ~]$ uname -a
Linux Galicja 2.6.36-rc4-git3-ARCHMOD #1 PREEMPT Fri Sep 17 13:17:59 CEST 2010 x86_64 Genuine Intel(R) CPU 575 @ 2.00GHz GenuineIntel GNU/Linux
It was a cake walk!
> How many users (home or business) actually upgrade the kernel every three-ish months?
I upgrade almost every time a significant patch comes along, and that can be once per week.
Maybe we should just make the kernel 'closed source' and then no-one would ever know about vulnerabilities.
Amazing how the cliky-clicky brigade gets all horny when a weakness in Linux is exposed.
Get a life. :)
is the poor little linux boy getting upset because someone is getting a taste of the same medicine every other OS gets when a fault is found.....
Be careful getting off your high horse - it's a long way down.
[Imagine catchy title here]
Being closed source hasn't kept Windows vulnerabilities from being made public..... Malware developers don't let a simple license clause making it illegal to disassemble code slow them down.
No matter what the OS, there will be vulnerabilities; even the old VIC-20 and C64 had their weak spots that would render them useless permanently.
I prefer using Linux over any other OS, but don't operate under a delusion that it is 100% safe. Among the reasons I am such a fan of Linux and other open source software is that I love to play around with the code under the hood.
Being open source...
...shouldn't this have been found and patched ages ago?
Oh wait, it was.
A Bug versus a Virus.
> is the poor little linux boy getting upset because someone is
> getting a taste of the same medicine every other OS gets
> when a fault is found.....
It's not the same "medicine" at all.
When Windows has a problem it's usually much more meaningful and real malware is released to the wild and people's systems actually get infected. The architecture of the system makes a bug like this far less dangerous.
Local root exploits are as old as Unix and predate Linux entirely.
its a legitimate point
No, the point he's making is that other OS's try to hide their crap code by keeping it secret.
By the way, if you have no strong views on the CofE being established or not, then your handle is a bit sad. I think I've made a similar point to you in the past. You do know what your handle refers to, I presume?
My handle, however, refers to something that I do frequently, one way or another.
"No doubt, Linux fans will be quick to point out that the bug can be exploited only by those with a valid account on a targeted machine in the first place."
This Linux fan tells you that it's a valid point, no matter you try to bashing it. Do you want to discuss the Print Spooler privilege escalation bug on Windows XP? I'm asking it because the existence of vulnerabilities like these are a big deal in corporate, government and educational environments. Sigh...
Are the Windows "news" of critical bugs boring nowadays?
Someone help me out here
...but is there even coverage on privilege escalation issues inside Windows?
I don't think there was any to-do being made after this Defcon presentation (http://vimeo.com/14581715) and, unless I missed something, there isn't any current defense against the escalation exploits much less "fixes".
Maybe I'm off base with that statement. I know the guys had practiced their demo, I know they could break into lots of things - including Linux - but the way they described what they were doing with Powershell appeared to indicate that there was a huge hole allowing you to do pretty much whatever you wanted once you authenticated.
Gee, thanks Red Hay. Nice one.
RE: t"he Linux kernel is the largest software project on earth."
I've never heard that before, is it true or just something that seemed cool to write?
Re : Largest? Really?
"I've never heard that before, is it true"
No. The latest release (2.6.35) has about 13.5 million lines of (non-documentation) code in it however, so it is quite substantial.
" or just something that seemed cool to write?"
Or is it?
If you think of the number of developers working on it, and the length it's been running as well as the code size, it might well qualify
That's some serious bloatware. No wonder they keep finding these bugs. Let's hope it never really goes mainstream or we could be in some big shit,.
Open = Secure?
Its an operating system. Bugs are part of the process, as are security vulnerabilities. Fortunately the Unix/Linux/Mac world is built on an inherently secure foundation (which is why in almost every corporate, government, and education environment some distant relative of BSD System V has a significant installed base) and why these vulnerabilities are rarely seen in the wild - it still happens and part of the inherent security is the relatively small adoption among non-technical users. Windows might be more vulnerable indeed, but its vulnerability is heightened by the large numbers of users not regularly patching, and not using security software which the OS developer says is needed, its part of their security strategy like it or not. I don't think Linux is the second coming of anything, but this is just one of those things that happens during the process, not worth going all chicken little about.
Mr/Ms/Mrs/Dolphin captain_solo, it would really help your case if you didn't just *say* that unix-clones are inherently secure, but also provided some *evidence* of this Inherent Security.
Sounds like a code fork BORK
All multideveloper code has forks all over the place.
Something has happened to allow this bug back in to the codebase. The question is what ? Across the board the fact that this is not a frequent issue indicates the codebase management tools are pretty good.
Sheesh I can't even manage my own projects properly ! Or maybe I just can't program very well.
Who am I to criticise ?
Yes, this is indeed a problem
We should not look at *JUST* the bug but *HOW* it was allowed to happen and try and put safeguards against such a future recurrence.
Human beings will always make mistakes but we should try and minimize them.
One cannot deny this was sloppy.
However, one should look at the positive side of it. The bug currently in question was found and reported because someone out there could look at the source. And there are people out there constantly looking at it. It is definitely a plus that we can do this.
Who knows how many bugs remain hidden in, for example, windows because it is still closed?
we think a measured WTF is in order.
Is this official El Reg policy?
... what is the accepted unit of WTF with which it should be measured?
(icon is apt though not in the way originally intended)