At least the fix is easy.
All complex code has bugs, some worse than others. This one's bad, but the fix is easy, and was delivered promptly, as usual. Thanks, Linus! :-)
Cue miscellaneous anti-Linux fanbois ... you may begin your yapping now.
"leaving the OS open to local privilege escalation that can completely compromise the underlying machine."
Does this not mean you must have physical access??
Can this be done remotely???
Needs to be fixed for sure but there is no need to panic. With physical access any machine can be owned.
Privilege escalation usually means that you are logged into a computer as a normal bog-standard user and using this trick you suddenly have root access, or at least some sort of access that you should not have.
If you have some valid remote way of getting in as a standard user, for example ssh or telnet then you don't need physical access. The real worry is if there is a two-step attack, where the first step is to get a normal user account through some other nefarious means and then use that account to get extra privileges.
Yap yap yap
But I'm running Firefox with AdBlock and NoScript so I'm safe right?
So this needs to be asked
Just how many bugs/exploits are going to be found when Linux finally starts getting more mainstream attention as an operating system?
Also, when this does happen are those who fanbois/girls of the OS going to continue saying that their OS is best?
And seeing as OSX is a variant of *nix does this affect them as well?
Cant wait to see what is going to happen.
/Let the flames commence
All very simple, but very hard to execute
From what I have read, it looks like what happened was that a pointer is dereferenced before it's checked against NULL, now, the compiler, being the clever chappie that it is, would see that dereference and then optimise out the check against NULL, because, who in their right mind, would dereference a NULL pointer, then check it against NULL, surely it should be, check it against NULL, then dereference it.
So a mistake by a programmer, put the dereference above the check, the compiler compounds the error by optimising AWAY (i.e. removing) the check against NULL, therefore the code is allowed to continue executing like the pointer was valid.
Of course, this only happens if the pointer is null to begin with, which only applies to a certain subset of people who as it says in the article, have kernel modules which DONT provide the method to begin with.
So, whilst being quite serious, looks like it would be quite hard to actually exploit. If you aint running an affected linux kernel module in the first place, you'd need root to install the new kernel module, to then exploit it and gain root privi....oh wait??? lol
Short version: we got lucky
isnt it wierd how no matter how serious the bug is when it is on linux its not a problem..dont worry the community will save us!!!! If it was Microsoft even if you had to log in as admin, be sat physically at the machine and require bill gates to provide a retina scan to explot the bug it would be the worst problem in the world ever and would show what a crap OS it is and how everyone should be donwloading linux immediately!
linux fanbois... lame
Code is never perfect
And the problem is that if and when Linux becomes a syatem widely used by...less capable... people than it is now, there will be problems.
If someone ever releases a PC running Linux that Joe Average can use to surf the web, do his banking, look for pron, etc, then Linux will be savagely attacked with all the vigour currently directed at Windows. At that point, all bets will be off. I would argue that all it takes is a financial reason to attack and it will be attacked.
No matter that it's used widely by businesses, the time it becomes worthwhile to attack is when the man in the street is using it for online banking, etc.
The question, of course, is if that will ever happen.
Well, if you are not happy with the security of Linux, maybe the NICTA seL4 microkernel is for you.
How easy to roll out, though
"This one's bad, but the fix is easy"
OK, now deploy it to all 60/600/6000 machines you have running Linux. Some of which are running mission critical applications. Don't forget, it needs a recompile of a kernel and a reboot to fix. And how many of these machines are running an old 2.4 kernel for application support reasons?
Bug fixing needs to take into account fix deployment as well as code changing.
Also, in many, many environments, there are very good reasons why machines cannot be upgraded immediately, even in best practices are followed.
I know the same issues would be there for Windows and OSX vulnerabilities as well, and they have the same problems. But the headache of having to patch and reboot every Linux machine is going to be large. Especially with the exploit out in the wild.
C#, Java, et al
This is exactly why we need an OS in a managed language like Java and C#. We have the hardware now. The bugtard C programmers have shown they cannot be trusted with powerful tools.
If Windows had something like this, the first person to spot it would in all likelihood be a blackhat, and there would be several pieces of really nasty malware out there.
At least all we have to do now is recompile our kenels. I've lived through 2.2 and 2.4, so I'm not afraid to do that!
Better to make a mistake and learn from it, than to pretend you never make mistakes.
"An attacker can just put code in the first page"
How, exactly? I think that you need the system to be configured in a particular way, or you need to find another exploit, in order to put code in the first page. So not all systems running a kernel that has this bug will actually be vulnerable. It would be useful if someone could tell us which releases of which distributions (with which software installed and which configurations) are affected. I guess it will take days if not weeks to work all that out, by which time anyone who cares will have installed a security update that fixes the bug. However, it can sometimes be useful to know that a certain system was exploitable in the past.
Executing code at NULL
Surely this should be a page marked with no execute? I'm pretty sure Windows does that.
This will have very little relevance with the anti-Linux fanboys as you put them.
How this could have been overlooked for eight years though, is the real matter. Does this mean that a trivial bug slipped through whatever QA process the community uses only to be overlooked again by the various white/black/grey hatters in the world?
Did we all just assume that Linux could not be affected like this? I think the answer may just be yes.
It may have been fixed quickly, but is the fix in the nightly unstable or the stable versions of the Kernal? Is the fix on the vendor's web sites, is it going to come down to my machines if I 'yum update' for instance? If it has been moved to stable, with appropriate testing, that is indeed impressive, but I have noticed lots of 'fixes' actually taking a fair ammount of time to turn up at my machines after they have been touted as being fixed.
On it's own this could not be used remotely, as Craig said a way of getting in as a standard user is required. However I'm not sure what Craig meant by a 'valid remote way' - certainly an ssh or telnet account would make it easy, but there are other ways that a box could comprised e.g. PHP Inject. Clearly if your box is open to the first step you have a lot to worry about - having an easy second step which gives root access gives you a fucking shit load to worry about. This really isn't one to be downplayed.
2.4 fixed, 2.6 isn't.
Curious - it seems 2.4 had this bug fixed yesterday (see www.kernel.org) but nothing has been done for 2.6. You'd think the current mainstream kernel would get a patch in long before one of the legacy ones. Oh well , perhaps 2.6 is now so complex that its not as simple as in 2.4.
Re: At least the fix is easy.
Writing the fix may be easy, but updating the kernel on every affected system (all of them pretty much) is an enormous task and not to be down-played. I'm no Linux-hater (I have managed Linux servers for fun and profit for years), but this is a pretty catastrophic PR disaster for Linux.
One of the nice things about Linux is that while - like any modern OS - it has a large attack surface, most of it is in user-space so you can update any buggy components without a reboot. Kernel bugs are a total pain in the arse by comparison.
While this bug isn't immediately exploitable in most cases without some other remote exploit, plenty of those exist and are discovered: it's raised the seriousness of a lot of other dumb bugs to a root compromise. Makes a mockery of all your careful attempts to ensure that external facing services are running as non-privileged users.
Bah. I hate reboots. I was at 128 days uptime on my mail server.
I have no truck with fanbois of any persuasion, an OS is simply a tool to allow you to run the apps of your choice and they all have their individual strengths and weaknesses.
That having been said, had this been a Microsoft bug, there would by now have been about 100 comments along the lines of "just install Linux, where a million sets of eyeballs ensure that security holes simply can't happen".
Re-compile kernel - I don't think so..
Surely one has to recompile the kernel ONLY if you have rolled your own - but most will be running a stock kernel, so most distros will issue a new kernel image & it'll arrive like any other kernel update does.
If anyone can get root access remotely you're fucked anyway . Don't think my Debian machines will be part of a botnet yet.
Yeah right. You're a comp-sci guy, right? So if it ticks all the latest buzzword boxes, that's good news. Never mind if it'll actually run your code in less than geological time.
Meat-cleavers are sharp. You can cut yourself, so that's why you have training, experience, and other people checking you're working right. But it's still better to use a cleaver for cutting through a T-bone than trying to use a spoon for the same job.
A typical unavoidable, side-effect of a new technology's wider adoption. Linux has moved from being a predominantly enthusiast/hobbyist OS to a mainstream business product and as such it's now being to do things never previously asked of it, or at least it's being entrusted with organisations' IT infrastructure so the significance of the flaw increases as now there's money and reputation riding on it.
I'm still impressed with the turnaround time for a fix, stable or otherwise - Microsoft take note!
Beer - it's what Fridays were made for
Big Picture Knob Twiddling ...... and a Devilishly Cunning and Heavenly Plan
"Sounds scary .... "leaving the OS open to local privilege escalation that can completely compromise the underlying machine."
Does this not mean you must have physical access??
Can this be done remotely???" .... By James Loughner Posted Friday 14th August 2009 02:27 GMT
Whenever it is done Virtually, are all Defences Rendered Redundant and/or Easily Overwhelmed.
" All complex code has bugs, some worse than others. This one's bad, but the fix is easy, and was delivered promptly, as usual. Thanks, Linus! :-)" .... By jake Posted Friday 14th August 2009 01:30 GMT
What fix, jake? A band aid on a trauma in not going to do anything physical. What Linux/Unix lack is Operating Systems Leadership, but they are not alone in that Barren Rut for None are Truly Worthy ....and thus are they all Vulnerable/Susceptible to Beta ProgramMING and Virtual Instruction Facilitation/Beta Systems Build ........ and that is no more difficult than Sharing Future Information ahead of ITs Time for Present Human Resource ProActivity/Chained Commands.
Crisis, what crisis?!?
Ksplice Uptrack Manager FTW!
Re: How easy to roll out, though @AC
And you're not using cfengine or puppet or another server management platform? More fool you then.
You need to build *one* kernel for each OS and arch combination, then roll that out using puppet or cfengine. You can even plan reboots and make sure it doesn't bring anything crashing down.
Shame on you for managing your server farm poorly!
I ran windows setup cd and it fixed it - look nicer too.
It has this cool browser called IE8 too.
Have a really great day!
"This is exactly why we need an OS in a managed language like Java and C#"
Have you ever stopped to wonder what the buzzphrase "managed language" means? It means the language runtime essentially manages memory (de)allocation for you. Now what is one of the jobs of an OS? Thats right Mr Cluetrain - its managing memory. So essentially you're suggesting writing an OS that doesn't manage its own memory and has something else (magic memory pixies?) do it for it.
Errr, yeah , that'll work. And thats before we get into the discussion about bugs in VMs.
Re: Re: At least the fix is easy.
Worse than that, linux kernels exist on a huge amount of embedded devices that never get updated. Though the attacker will still need a way in first.
@James O'Brian - "And seeing as OSX is a variant of *nix does this affect them as well?"
*nix isn't Linux, and OS X is based on BSD I believe, so in theory no. Unless the same bug is in the BSD kernel of course ;)
for fixing it.
On the other hand : even microsoft doesn't have bugs that old .... makes one wonder...
"OK, now deploy it to all 60/600/6000 machines you have running Linux. Some of which are running mission critical applications. Don't forget, it needs a recompile of a kernel and a reboot to fix"
Actually, some work is being done at the moment (not sure if it made the mainstream) to remove the need to reboot when swapping out the kernel. Not sure why you mention recompiling, because nobody in their right mind does that now, not in a mission critical situation. You use the one supplied by your distro.
And if they're mission critical, you have them firewalled and you don't allow just anyone local access anyway, right?
Privilege escalations are nothing new and are present in many OS's. This will be fixed and forgotten like many others.
A Linux Fetish?
Sure, the prolonged uptimes possible with Linux are signs of a generally good system design.
But why are people starting to complain about having to re-boot, in this case? This sounds more like fetishistic willy-waving than sensible computer administration.
(I've given up on counting Windows re-boots, but I remember a routine update which required six.)
Ksplice to the rescue!
OK, not sure if i would run all patches on our most mission critical machines though :-), but this one is so trivial i would dare.
seems to be a lot of brooha aboot patching kernels
in the vast majority of cases it'll be a simple case of installing the patched kernel through your package manager, with a host list that can be done in 1 line of bash for any number of machines. The only proviso is taking into account mixed distro environments. Even then a couple of lines of bash should be all it takes to iteratively log into to every machine on the network, update the kernel and reboot the system.
Yes this is a big bug and I'm amazed it wasn't caught much sooner but all these whiny bitches going on about how difficult it'll be to rollout the fix seem to be making a mountain out of a molehill IMO.
I don't expect we'll hear very much about this issue from the usual suspects due to the following 2 reasons:
1) the concept of this vulnerability is too complex for the Microsoft fanboys to actually understand. "Null pointer, you say? Kernel-level routine, eh? I'll just go and play some games whilst you geeks get jiggy with your DOS-like commands and fix the problem"; and
b) the Microsoft fanboys who do understand the technicalities involved are too busy deploying the 11 patches MS have released within the past 3 weeks.
Surely part of the problem is that the code gets optimised by the compiler? Which means that what's actually running isn't necessarily what the programmer wrote. So a clever trick employed by a programmer who knew exactly what they were doing might end up on the cutting room floor as a result of the optimiser thinking it knows exactly what it was doing.
If that's what happened here, it is really just a case of Unintended Consequences. It might actually be better if kernel code had to be hand-optimised. We fell into a trap when computers became cheaper than humans .....
If this happened to windows all the Linux Fanboi's would literally be foaming at the mouth decrying windows, Microsoft as per the usual.
Funny how when a bug is found within their own sacred cow , its all hush hush , its doesn't matter , its just a small boo hoo..
Hypocrisy any one? Or emotional underdevelopment?
"If someone ever releases a PC running Linux that Joe Average can use to surf the web..."
But that's never going to happen is it. Who is going to put in the effort to make Linux easy to install and use on any arbitrary system with working device drivers for all peripherals.
Hell Freezing Over icon needed. Penguin, because he looks baffled by the needs of normal people.
In reply to some of the previous comments:
Linux is mainstream in the datacenter. 'Finding' bugs and exploits requires advanced coding skills. The source is open. If you ask me, this makes it more secure. Closed source software might be full of bugs and exploits, but without being able to see the code you'll never know. Security through obscurity.
The popularity of Linux on the desktop will cause it to become less secure, but that's because a desktop OS needs additional bells and whistles. For example, Flash Player (closed source) has been the preferred attack vector at recent hacking tournaments. The kernel usually has its vulnerabilities fixed pretty quickly. Plus, you can compile your own kernel and leave out all of the 'bits' you don't want, making it smaller, faster and more secure. You don't have this option with closed source software.
"And seeing as OSX is a variant of *nix does this affect them as well?"
Being a varient of *nix has nothing to do with the Linux kernel. OSX doesn't use the Linux kernel. Neither does Solaris, HP-UX, AIX, BSD or any other Unix.
"isnt it wierd how no matter how serious the bug is when it is on linux its not a problem..dont worry the community will save us!!!!"
I love the spelling, grammar and multiple use of exclamation marks. You do a service to all MS "fanbois", but you don't seem to have any grasp of 'how serious the bug is' either. Lame.
"Just how many bugs/exploits are going to be found when Linux finally starts getting more mainstream attention as an operating system?"
Well, considering that Linux has all but replaced Unix platforms in corporations (you know, the big places with all the money that the goverment hasn't stolen), that makes them 1) prime targets and therefore 2) mainstream enough for people who are serious about getting into places they shouldn't be.
not much of a showstopper
Since I switched to Fedora on my laptop I don't recompile my kernel anymore, and let the distro do it. However, memory prompted me to check out an old hppa server running 2.6.28 and Gentoo; there's an option in there (Security options) to configure how much "low address space to protect from user allocation":
This is the portion of low virtual memory which should be protected from userspace allocation. Keeping a user from writing to low pages can help reduce the impact of kernel NULL pointer bugs.
Apparently there is even a kernel tunable, so nobody needs to recompile/reboot in the short term - just stick in 4096 or whatever your page size is to /proc/sys/vm/mmap_min_addr and you are gaffer taped until you can afford some scheduled downtime to apply both this default and the real fixes to the offending modules.
No idea when this feature was implemented but I'd say at least a year ago - correct me if I'm wrong. I've had it set since I first saw it as I realised the useful purpose it would serve. Obviously I'm not open to much abuse running a PA-RISC box from the Ark, but the principle applies everywhere.
I would hope that any Linux sysadmin worth their salt would have been using this option for some time. In that dreamworld, the impact of this new 'sensational' bug would be small as no local attacker can place code at address 0 to be executed.
If you activate SELINUX in "enforcing" mode on Fedora 11, this exploit is blocked.
Isn't this a bit like Hot Coffee?
I mean in order to exploit this bug you need to have a kernel module (presumably third party) that doesn't implement a certain function (hope i understood it clearly). So it's less of a kernel bug and more of a third party bug by proxy. Kinda like the whole Hot Coffee mod for GTA-SA.
We need a "i need a better analogy" icon.
@ AJ Stiles
"If Windows had something like this, the first person to spot it would in all likelihood be a blackhat, and there would be several pieces of really nasty malware out there."
What makes you so sure that this particular bug (or, rather, class of bugs) haven't been discovered and exploited by "blackhats" ?
"At least all we have to do now is recompile our kenels. I've lived through 2.2 and 2.4, so I'm not afraid to do that!"
Oh, is that all, well let me unpack that a bit. You will need to obtain configured source that exactly matches your running kernel, patch it, apply any and all patches that you applied to the kernel, from scratch, in the correct order, recompile, install the new kernel, making sure to add boot time options to fall back to the previous kernel when it turns out you screwed something up, reboot, repeat until success.
This is not my idea of an easy update even on a single machine, let alone a server farm. And most admins simply won't have the time (or the skill set) to do it, waiting instead for their vendor. Hell, many of them probably don't have the tools to hand, you don't keep compilers and kernel source on production servers unless you're a complete retard.
My goodness, is that a fuck off big gap between the identification of a bug and the moment that all the boxes are patched against it ? I think it is.
And as for the millions of poorly administered linux boxes on the wider internet which may never be partched ...
Guaranteed priv escalation is an extraordinarily serious problem. As usual the fanbois refuse to see the naked emperor.
C'est la vie, eh ?
Well, must run, I'm off to construct a botnet (out of your machine, while you wait for your kernel to recompile).
@ Jake - A challenge
"All complex code has bugs, some worse than others. This one's bad, but the fix is easy, and was delivered promptly, as usual. Thanks, Linus! :-) Cue miscellaneous anti-Linux fanbois ... you may begin your yapping now".
I'm no anti-Linux fanboi, in fact I have quite a lot of kit which I use, some of it in critical, public internet facing deployments, which is why I'm having a problem, but I'm sure Jake will willingly help me out.
So, Jake ... If "the fix is easy", just how do I patch all that embedded kit which has a flawed Linux kernel ? Routers switches, caches, NAS's etc etc, all running on a variety of architectures and often with their own, non-GPL extensions. I reckon you stand as little chance as I do in fixing what I have.
So, Jake ... time to shut up, or admit you're a Linux fanboi.
@Chris Thomas Alpha
According to the article, it was fairly trivial to exploit. And the real problem may be that this issue exists in many places in the kernel---anywhere that a 'standard' module isn't installed. Not clear on whether this can be exploited remotely, but as so many have mentioned, it's usually trivial to own a machine if it's right in front of you.
It may be it went unnoticed for so long because the problem isn't really in the source code---it's introduced by the compiler trying to think for the programmer. And it took a long time for it to occur to some particularly creative person to try this, or it may have been partially discovered by accident, then it dawned on someone what was happening.
If Linux kernel updates worked as (usually) flawlessly as installing a Windows service pack, this would still be a great annoyance. But in my experience there are many more things that can go wrong. There's usually one or more modules or drivers that get missed or aren't totally compatible with the new kernel the way they're configured, leading to a lot of swearing and banging head against wall. It's rare that an update of this magnitude leaves a Windows box unbootable, but this seems to happen all too frequently with *nix, and takes a much higher skill set to fix.
Kudos to the Linux folks for admitting the problem, taking their lumps, and immediately releasing a fix.
Funny how this idea of Linux being so difficult to install keeps getting trotted out no matter what they do to clean it up. I can recall a time when I needed to get details from a prior Windows install to be able to configure Linux properly, but that was many years ago now.
I can certainly vouch for the mainstream distros in that you can not only run it from a CD to try it out, and load it with very little interaction as much of what is required to get it working is done by the system as it loads. In many ways, loading Linux onto a PC has very little difference to loading on your fave Windows CD and still supports a lot more legacy kit than recent Windows versions, not to mention that it is pretty forgiving these days about the latest stuff.
To be honest, this whole Windows vs. Linux thing amuses me immensely, especially when old tales like this get repeated. What was the last version of Linux you tried loading?
"Have you ever stopped to wonder what the buzzphrase "managed language" means? It means the language runtime essentially manages memory (de)allocation for you. Now what is one of the jobs of an OS? Thats right Mr Cluetrain - its managing memory."
So my operating system provides a garbage collector for *all* my processes' internal memory allocation requirements, does it? Time to (re-)read Tanenbaum and friends, I think.
""If someone ever releases a PC running Linux that Joe Average can use to surf the web..."
But that's never going to happen is it."
If you can't pick up a netbook running linux and get from powered-off to web-browser inside a minute you need to back away from the keyboard right now and NEVER darken the doors of a tech site like this again, that is an absolutely stunning level of incompetence!
I sure as hell hope you don't work with computers.
So this affects any Linux based machine??
Routers, NAS drives, media players etc???