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.
Linux developers have issued a critical update for the open-source OS after researchers uncovered a vulnerability in its kernel that puts most versions built in the past eight years at risk of complete takeover. The bug involves the way kernel-level routines such as sock_sendpage react when they are left unimplemented. Instead …
"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.
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
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
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.
"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.
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.
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.
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.
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.
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".
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
"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.
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!
"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.
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 ;)
"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.
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.)
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.
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.
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.
"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).
"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.
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.
> @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 ;)
Oh dear. Anyone could do a bit of homework and get this right before posting this dreck.
The OS X kernel is derived from the CMU Mach monolithic kernel. The rest of the OS X userland, not counting Apple's proprietary stuff, appears to be a mix of all the BSDs, according to someone who surveyed the version strings.
Are the BSDs and OS X vulnerable? Hard for me to say, although I suspect not -- but I'd wager there are people checking. And you'd think that the people who found this in Linux would have tried the BSDs too, and would be crowing about it if it were.
"Have you ever ... has ... (magic memory pixies?) "
Errr, yeah , that'll work. "
Err, yeah, it will. Singularity, COSMOS, JavaOS, SharpOS, Midori. Ring any bells ? Nope, didn't think so.
"And thats before we get into the discussion about bugs in VMs."
Certainly, before that happens you need go and wipe the drool off your 'IT for dummies' book.
Do try and keep up.
This post has been deleted by its author
"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."
Theres a difference between writing your apps in a managed language where the runtime embedded in the .exe or VM does the garbage collection , and writing the whole OS in a managed language you clueless numpty. But since you ask - the OS does garbage collect along with closing file decriptors, sockets etc when a process exits.
Many are often claim the Linux is the best and free but this shows that it fails to be the case.
Windows has many security update but never do we find a bug left in place for 8 years! In fact Windows always will update more often with a new versions to ensure it is more secure than the last one (we see NT ant 200 and 2003 and the newer ones and XP and Vistas for our examples).
When we see the Linux men not bother to change the softwares for 8 years we must worry. This is why I choose not to have it on my computers where I am working.
"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."
See other article right next to this one on main page..... the one about the TWO YEAR OLD exploit M$ finally got around to patching recently. I believe most Linux vendors ALREADY have a patch available for this exploit, and as someone already wrote (FREE advice mind you) there are multiple ways to protect and remove this exploit before needing ANY kind of patch.
This is not even a case the pot calling the kettle black, this is a little more like you pointing at the moon and asserting that its the sun. The facts just don't agree with your statements.
Paris icon - get a clue
I was just waiting for your comment Bob, in your fake Russian style of writing (hint, leave that to the meerkats, who are much better at you and much funnier).
So it's 8 years "old" but no-one has found it until now, and the patches are on their way ,and as has been pointed out you can, on many system fix it without a new kernel and a reboot.
Microsoft (are they your employer in some way?) have just taken 2 years to work on a patch. This isn't a security hole that has been round for 2 years and has only just been found, this is a security hole they have known about for 2 years but chose to ignore.
But apparently MS is the dogs danglies and Linux is complete shite in your mind... God help your end users.
"The facts just don't agree with your statements."
No, they do, they just disagree with _your_delusion_ of what my statements are.
And as for MS, what have they to do with it ? There is no pot calling the kettle anything. That connection, also, is entirely manufactured from whole cloth inside your head.
Seek help, before your comprehension skills are entirely consumed by the linux jihad meme. I've seen it happen often, and it is never pretty.
"Windows has many security update but never do we find a bug left in place for 8 years! In fact Windows always will update more often with a new versions to ensure it is more secure than the last one (we see NT ant 200 and 2003 and the newer ones and XP and Vistas for our examples)."
Windows 98 First Edition right up to XP.
Mines the heavy one rated Class III with pockets for ceramic plates.
"So this affects any Linux based machine?? Routers, NAS drives, media players etc??? Oh dear..."
No, because bottom memory (the only bit you can modify through this exploit) on routers and similar devices is ROM. Has to be that, see, 'cause the program counter is initialised to all zeros at power on, so the first instruction to be executed has to be at that address. Which means it has to be ROM for obvious reasons.
Well, golly... If it is trivial to exploit, it was probably trivial to find... so you know it has been used to root boxes on a regular basis for the last 8 years.
Something this powerful in your arsenal, you don't spread word of it around any more than you need to.
"leave that to the meerkats, who are much better at you and much funnier"
I do not see why you say this. But then you hide as Anonymous so I know you have not the courage to stand by it.
You tell story about Microsoft patch which waits two years but of course you are offering no backup story to explain what you say as true evidence.
I am happy with what I know to be based on properly looking at news and the technology papers. I am using Microsoft most times but still there must be times when I can recommend the alternatives when I have made proper research to prove it is the wisest of choices.
It seems many on the forums are not do their research as well like me and just shoot their hips when they see chance to beat brow Microsoft.
"Something this powerful in your arsenal, you don't spread word of it around any more than you need to."
And of course you wouldn't notice that your system was running a root kit for eight years? And what sort of argument is "easy to exploit trivial to find"? It's patently not trivial to find. I think you'll find it takes some people about eight sodding years. Maybe somebody did find it sooner, in which case I direct you to my previous point.
Funny how whenever there's a flaw exposed in the kernel everyone's a linux expert. Has anyone here mentioned that not all distributions are affected by this exploit?
So for the next couple of weeks anyone who updates their rootkit has a somewhat higher chance of hijacking a system in a particularly narrow set of circumstances. Bad news: in two weeks Windows will still suck. Do you even have UAC switched on? How do you even tie your laces?
"Oh dear. Anyone could do a bit of homework and get this right before posting this dreck."
The OS X kernel is derived from the CMU Mach monolithic kernel. The rest of the OS X userland, not counting Apple's proprietary stuff, appears to be a mix of all the BSDs, according to someone who surveyed the version strings."
Good grief, nitpicking or what. I said "based" on BSD. I didn't want to complicate things mentioning Mach. Sure I'm no expert on it, but Mach from what I can tell is partially based on BSD's kernel (or at least was a replacement for it and developed by BSD developers).
Hardly dreck. The point was simply to emphasise that OS X is *not* Linux and does not use a Linux kernel, not to get into the details of this and that kernel. That's all.
Maybe the next codename for Ubuntu could be "Laidback Linux" - seems apt according to the comments.
To: AC @ 14:48
Think you'll find MS found the hole, and spent two years patching it until it was known about in the wild. If it was never known about MS were going to patch it in a future release of Windows. Why patch it if nobody knows it's there and it's going to break things...?
So it was known about and MS released a patch.
The point Bob Gateaux was trying to make is that should be running your system on a non-disy kernel your propper fucked. It's going to take a while just to start on rebuilding the box let alone actually recompiling the kernel to find out you've done it wrong.
And regarding updates, I think MS win with Windows Server Update Services...
Would that be the WMF exploit that only affected NT derived systems, was announced in Dec 2005 and fixed in Jan 2006? I can't find any other refrences to a WMF exploit on the 'net and I've had a fairly good look because I was interested in how something could be a problem for both NT and 9x series of windows which have no common codebase.
No, you don't get off easy, first writing "it's BSD I believe" and then whin(g)ing when told that "no, in fact it's _not_ a BSD kernel." (OS X's kernel that is.)
If you think that's nitpicking, well, to each his own. There's enough people as it is -- foolishly, naively, ignorantly -- claiming that OS X is BSD. When do we start getting this right?
I'm sure if I cavalierly said that Linux (i.e. the kernel) was Unix or BSD, I'd get called on it and I wouldn't get off easy either by trying to claim that those doing the correcting were nitpicking..
I knew this "Linux" nonsense was a non-starter from the get-go.
When will people learn that if you insist on doing all your stuff on toy computers you must expect toy results?
If it doesn't have any Germanium in it, isn't at least water-cooled and doesn't take up an entire room it isn't a real computer. It doesn't matter what piece of tat you use to make it "work".
Never should've moved off the pentode valve standard.
"OK, now deploy it to all 60/600/6000 machines you have running Linux. Some of which are running mission critical applications"
and every single embedded linux system like routers, print servers, access points, mp3 players...
oh, and getting user-level access? Are you in your linux distro's security update mailing list? See how often updates come through for user-level access exploits in things like file archive reading, image reading etc. You could exploit a linux mailserver just by sending it an email, if it was doing virus checking.
The fanbois on here are idiots, it is a bug and bugs exist in EVERY operating system out there. Sometimes bad and sometimes less worrying. But there are many ways in how an attacker can gain root/admin access. Sometimes it needs privilege escalation using yet another component installed on the system, but there are frameworks for doing this.
There's not a single holy platform without bugs. Not OS X, Windows, BSD or Linux is sacred.
They all have their bugs and need to get patched, get over it.
I know genetic UNIX well. I do not know Linux kernel as well, but I do know this.
Userland processes run in a virtual address space controlled by the kernel that does not match physical memory addresses.
The memory mapping registers that control a processes virtual address space can only be manipulated with the processor supervisor bit set (this should only be set when running kernel code after a system call, or in a kernel thread), so a process cannot map new bits of physical memory into it's address space without the kernels involvement. This is a FUNDAMENTAL security requirement that is well understood by kernel writers (and incidentally, a reason why the first versions of Windows on Intel processors prior to 80286+80287 or 80386 were fundamentally insecure)
Page zero of a userland process does not necessarily map to physical page zero. It's dependent on the hardware architecture of the system and the way that the process virtual address space is set up by the kernel and whether you have a separate set of supervisor mode memory mapping registers.
In all UNIX variants I have used that do map page zero to virtual page zero in a userland process ALWAYS write-protect this page, and most hide them so they can't even be read. It is normal to only map page zero if the system call interface does not provide a mechanism to change the memory mapping registers during the transition to system mode (IBM's original RS/6000 processors could not do this. The result was that the first piece of kernel code actually has to execute in the non-privileged processes address space before it has the chance to change the memory mapping registers, so some kernel code had to appear in the processes address space).
So. My question is how do you write to physical page zero to exploit this problem without already having escalated privileges? Maybe someone with some real Linux kernel experience can explain.
I'm off to /usr/src on my laptop to have a dig. If I find anything relevant, I'll post again.
It so happens that the regular patch review cycles for the current LTS kernel and the current 'release' kernel are presently under way; the relevant messages on LKML imply that the releases will be done sometime after 1900GMT on Saturday. Distributions may or may not already have patched kernels; but if they don't, it won't be long before they do.
Always good to see the fanboys and trolls are still around.
Someone mentioned how hard it was to compile a kernel... I've been compiling them from scratch for years now, and I've never had that much trouble, even on system with multiple sketchy patches for hardware, which insist on working with only one -rc kernel version.
Any it turns out you don't need to wait on your vendor at all. If you aren't running a hand-compiled kernel, it isn't too difficult to patch the proper version of your running kernel, compile the module, and make a package from it. If you're running sufficiently large numbers of servers, you're probably running your own repository, so installing is as simple as one command on each server, which can be easily executed with a properly setup pssh.
I don't much like the package management options out there, or kernels that someone else made, so I've written my own little patch and package distribution system, just for my handful of systems. In the time it took me to read these comments I got this patch onto every one of my systems which is powered on and connected to the internet, each with different kernel configs, versions, and patches.
/Everyone/ is right about the reboot, which is mostly bad because many many people haven't got a proper failover / high availabilty backup system. A reboot must be done when nobody is on a system, or after a backup has been provisioned and swapped in. Neither of those are a great solution for many people.
Anyone that mentioned Ksplice forgot to notice that it only works with the latest version of Ubuntu, which is exactly unlike any distro you'd want to run mission critical services on. I'm pretty sure anyone can wait for the spinning cube / jiggly windows for a second while they reboot.
Some of you fellow commentards are confusing this one with another recent NULL-dereferencing bug.
That one was the dereference-before-check one; it would blindly read from zero page. (x->y: x could be NULL.)
This one doesn't have the check at all, and will blindly call code at address 0 (x->y(): y could be NULL). The patch adds the check by replacing the direct dereference-and-call with a call to a pre-existing function which dereferences, checks whether the result is NULL then calls either a default function (if the result is NULL) or the code at the dereferenced address.
Actually, y could also be random junk but for the fact that in-kernel data structures and jump tables are always zero-initialised. This makes things more predictable in case of bugs, which means that you're more likely to get useful data when things go wrong; conversely, it also makes things more predictable in case of bugs, which means that it's that little bit more easily exploitable.
(Incidentally, 2.6.31-rc6 has this patch.)
There's no such thing as 100% security and serious bugs are still going to turn up. Still, it's the most secure OS of them all.
Still perhaps it's time to look at what can be done to minimise the damage of potential exploits similar to this one, if possible.
And I agree with Anonymous Coward, a higher level programming language managed OS might avoid some of these obvious but unseen bugs. That said, as Linus Torvalds seemed to suggest, the advantage of using C is that everyone can understand it, otherwise you get people making rubbish.
Typically the zeroth page in a PC hasn't got anything in it -- the zero page descriptor isn't used. NULL pointers are much more of a problem with a system with a flat space where low memory is interrupt and exception vectors.
I think this is the same bug that was touted a few weeks ago, one that was a combination of bad programming practice and compiler optimization.
(Now where's the "Headless Chicken" icon?)
"Just how many bugs/exploits are going to be found when Linux finally starts getting more mainstream attention as an operating system?"
How many exploits you can find reading/examining the source code? It has been open to everybody since day 1.
How about "all"? Relatively fast, too. No 3 year waits like in MS-systems from discovery to patch.
Quite obvious is that corporate world doesn't give a f**k to security or reliability, it's all about money. Windows is the best evidence for that.
"Mainstream" is a weasel word if anything: Microsoft is the only mainstream as long as "mainstream" is defined by licences _sold_ (like most corporate drones do), because most Linux-installations are not bought, but downloaded.
(I've downloaded two DVDs and I've 10 server machines and 16 laptops running from those, by corporate accounting "units sold" is zero, ie. no machines. Obvious lie to anybody who has brains and some knowledge.)
"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."
Plain bullshit. It needs just one instruction: "yum update kernel". And I'm running auto-updates to my own repository so every machine gets updated automatically, _no instructions_ needed. Obviously you don't have a slighest clue about how things are done with Linux.
Reboot is needed but that's a planned reboot and a part of maintenance routine anyway.
Tell me how do *know* your machines will boot if you don't reboot them once in while, like yearly or so?
(Windows-machines are booted every month anyway, doesn't apply to them.)
One can't help noticing the level of detail in the explanation of the problem.
As someone who hosts for other companies and provides consultancy to some of the biggest names in the software world it's interesting how much detail is available just in these comments.
I have to say if this were a Windows exploit I would still be a bit worried.
I now know it won't affect me.
My web servers don't have public root access so no-one can insmod a driver with the correct payload.
Out of interest, which function is the problem? would it be init() or one of the others?
It's interesting how the trolls jump on any bug in Linux that comes along.
it makes you wonder how things would look if Microsoft's development process were as transparent. This is a BUG. This is not a working piece of malware that has managed to cripple the Internet.
It should be fixed. It shouldn't have happened to begin with. But it's not nearly in the same league as the hordes of malware that infest s WinDOS consumer PC's the world over.
Linux is far from the "Most Secure" operating system available, although it is generally more secure than the MS "operating systems" and many of the Unix variants, all of them suffering from the same classes of shortcomings, rooted in their origins as personal, "toy", research single-user systems in protected, limited, or academic environments. This was made worse by the ensuing feature creep needed to support (poorly) new applications and environments -- an epic tragedy where the energy of youth led by those who "know about" rather than "know from experience" ignored and rejected the warnings of the past from their elders whose wisdom had come at great cost, thus able to create magnificent works designed to sail unharmed through the greatest of storms while oblivious to flaws so great to preclude a single voyage.
My personal choice for normal use is OpenVMS, initially from DEC and drawing upon much of what we learned from Honeywell Multics, Burroughs, IBM, Univac, DEC, and others in the mainframe, timesharing, and minicomputer worlds. We also have learned a lot from operating systems writen in PL/I, Algol, and other high=level languages. Unfortuantely most of "modern" software is implemented with an error-prone language using a dangerous interface and inadequate controls, validation, design, and testing. Your security is limited by your most vulnerable point; all else is delusional.
For this particular example, the Unix/C-style calls to system services, the zero-terminated strings, the lack of argument validation, and the tendency towards efficent versus correct, robust, and secure are the beginning for many problems. The C programming language, its definition, and implementations are inherently error prone, poorly defined, and subject to the vagaries of compiler options, optimization, and misleading assumptions.
The gcc or other C complier should should at least warn and probably reject the use of possibly NULL pointers. The excuse about optimizations is wrong; if the compiler is not absolutely sure that execution will never reach a test or NULL or something else, it must remain. In the first kernel flaw, the use of an untested pointer should have generated a error/warning and inhibited later removal of the test.
The third failure for this example falls squarely on those coding and testing the kernel. Sorry Linus.
The final failure is by all of us who continue to build or tolerate the use of increasingly dangerous and complex technologies where we might not survive a single mistake -- little different from my youth in the 1950's.
Duck and Cover.
and kiss your ass goodbye
To the Wintards claiming that Microsoft would NEVAR EVAR have an eight year-old bug in their crapware probably think that because they never read the security bulletins for the patches they install (this is especially directed at you, Bob Gateaux).
Well take a look at this:
Oh my! A bug that also allows privilege escalation from windows 2000 and up. Well, I'll be damned!
Or maybe you might like this one even better:
Yeehaaaa!! it never fucking ends, remote code execution for windows 2000 and up!
Maybe you Wintards should read your own security advisories before trumpeting your fanboy bullshit.
It Linux perfect? Absolutely not. Just kicks the shit out of windows.
people yapping about how windows or Linux get blamed differently... lets put this into a bit of perspective.
this problem has existed for 6 *years* - the source code has been viewable and downloadable by anyone during this whole time. nly now has someone gone through looking for such an obvious issue - and I'm suprised that Coverity didnt catch it!!
of course, now all the glory hunters are going to be trwaling through the source code again....but this is a good thing...other issues will be found (you can almost guarantee that) but they'll be sorted out. the end result of this issue will be an OS kernel that will be even tighter and more secure than it is now...which is good timing for the oncoming windows server v's Linux debate.
i think *BSDs need a new breed of eyes looking over their code too
Whilst consequences may be unintended, they certainly shouldn't be unforeseeable! The programming language should make it very clear what the programmer can and can't rely on (with regards optimisation). Either the programmer would be at fault for not understanding the language, or the compiler for not implementing it properly.
Funny how everything always turns into OS vs OS and fanboi's post as anon with all of their garbage (from both sides).
I will agree that the more recent distros are getting better, easier to deploy and use etc. With personally over 10 years playing with linux distros, I recently installed the latest Ubuntu on my new Atom mini system and it was easy. Not as easy as Win7, but still ok.
However, the bottom line is that most people want an easier to use OS and until Linux and their fanboi community realizes that from both the casual user to the IT user, Linux is more of a hassle overall. "Just Works" is only true if all you are doing is installing the distro from CD, anything else is usually a major pain compared to Win/Mac. It's fine if your requirements are only a desktop surfing system or a mail/web server, but there is little else you can do with it, short of specific vertical market or specialized use (educational, scientific, etc.).
Comments like "my linux-box is behind a firewall/nat" so this bug won't affect my os-of-steel is utter bunk. I can put a windoze-box behind as well and it will be just as secure.
Biting the hand that feeds IT © 1998–2021