Local Privilege Escalation On All Linux Kernels 595
QuesarVII writes "Tavis Ormandy and Julien Tinnes have discovered a severe security flaw in all 2.4 and 2.6 kernels since 2001 on all architectures. 'Since it leads to the kernel executing code at NULL, the vulnerability is as trivial as it can get to exploit: an attacker can just put code in the first page that will get executed with kernel privileges.'"
Ahh... (Score:5, Funny)
So that's what the NULL pointers were for.
It's from April? Really? (Score:5, Informative)
Then why did Linus check in a patch today to fix it?
http://archives.neohapsis.com/archives/fulldisclosure/2009-08/0174.html [neohapsis.com]
Re: (Score:3, Insightful)
April or not, I want to know why it's taken eight years to find this flaw.
Re:It's from April? Really? (Score:5, Funny)
local... remote... (Score:3, Insightful)
As was stated before: if someone has a local account on your Windows machine, they already own you. You DO know the difference between local and remote exploits, right? I mean, NOBODY on Slashdot would go spouting off on topics they know nothing about just to score some points for their favorite OS.
Yeah, this is a serious bug. But honestly, how many people are running real multi-user systems with multiple honest to God local users? Okay, I am, but I figure I'm probably in the minority nowadays.
Re:local... remote... (Score:4, Insightful)
nobody (the apache account) is a local user.
Re:local... remote... (Score:4, Insightful)
Local exploit in kernel + arbitary code execution exploit in network service = remote exploit.
You know, like running WordPress.
It would be quite an accomplishment to introduce a remote exploit directly in the kernel.
Re: (Score:3, Interesting)
The problem is, if this were an eight year old really bad exploit in Windows, the article would be explaining how the authors pointed this out to Microsoft 7 years and six months ago, were threatened with legal hell if they said anything to anyone, the exploit has been in the wild though three versions of windows for six years, they finally managed to get a gag order revoked now, and we're just now finding out about it.
Instead we are finding out about an old, but only just uncovered (by white hat) exploit,
I'm safe! (Score:5, Funny)
I use Windows!
Re:I'm safe! (Score:5, Funny)
Once again, my 2.0 Linux kernel is safe!
Re: (Score:3, Funny)
Excellent. My old 2.2-based Slack 8 boxes should be fine, too.
Can't trust that new-fangled 2.4 stuff. USB support? Who needs it!
Security through Obscurity? (Score:3, Insightful)
Does this mean that Linux was never more secure than Windows--only more obscure?
Re:Security through Obscurity? (Score:4, Interesting)
Re:Security through Obscurity? (Score:4, Interesting)
Actually, it is possible to map at NULL in Windows, which is just as plagued by NULL pointer dereferences as Linux is.
Try this:
BaseAddress = (PVOID) 0x00000001; // (1 & ~PAGE_SIZE) == NULL
RegionSize = 0x1000;
NtAllocateVirtualMemory(GetCurrentProcess(), &BaseAddress, 0, &RegionSize, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
Re: (Score:3, Interesting)
Re:Security through Obscurity? (Score:5, Interesting)
CONFIG_DEFAULT_MMAP_MIN_ADDR: 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.
Unless I am misunderstanding, or the bug is in this code, the Linux kernel is already protected if properly configured. The kernel already prevents this attack.
Hide teh Lunix (Score:3)
Seriously, how hard is it for the OS to just blow up whatever program is running if it tries to access the memory location NULL, period?
That depends on whether you're running this OS on a PC or a C64. Programs on a C64 are expected to access memory-mapped I/O registers at $0000 and $0001.
Re:Security through Obscurity? (Score:5, Informative)
Yes, it's called hardware level paging ... The problem is from how the exceptional condition (null pointer access) is handled by the kernel, and not the fact that NULL was called.
No, it's not. The problem is that the kernel also has access to the process's memory, so if the process mapped page 0 as r-x then the kernel also has that page. So when the kernel jumps to NULL through a function pointer, it runs whatever code the process put there.
This mapping is done for efficiency because otherwise any system call would flush TLB at least *twice* and it would be slow as hell.
Hardware memory protection is as old as dirt, but it's also a brutish fossil, symbolic of a decayed era, gratefully forgotten.
Re: (Score:3, Insightful)
Does this mean that Linux was never more secure than Windows--only more obscure?
It's hardly obscure since they could look and find it, evidenced by the fact they found it.
Go try that with the Windows kernels!
In addition, there is already a patch out for this, which by end of the week will be pushed down from the distro managers. We don't have to wait years after finding it for the fix to be released, as Microsoft historically does.
In fact, why just assume this similar bug is NOT in the windows kernel? Did you check? Did any reputable security company check?
I'm not saying it is there
Re:Security through Obscurity? (Score:5, Insightful)
Does this mean that Linux was never more secure than Windows--only more obscure?
It's hardly obscure since they could look and find it, evidenced by the fact they found it.
Go try that with the Windows kernels!
In addition, there is already a patch out for this, which by end of the week will be pushed down from the distro managers. We don't have to wait years after finding it for the fix to be released, as Microsoft historically does.
In fact, why just assume this similar bug is NOT in the windows kernel? Did you check? Did any reputable security company check?
I'm not saying it is there, only that you can't easily prove otherwise.
*that* is the security being spoken of.
As far as I know, only one OS claims no exploits, and that is OpenBSD.
The transparent thing works both ways... it's easier for black hats to find holes too, by your own logic. And they can keep it secret and exploit it as long as they can. A similar bug existing in Windows doesn't prove anything and is irrelevant here. After all 'M$ can't code shit'. Linux and FOSS is commonly claimed to be more secure because of it's development model and bug free here in these parts. Any data that runs counter to this is routinely downplayed by commenters and moderators... just like your post got modded up.
Re:Security through Obscurity? (Score:5, Funny)
Your post got modded up, too.
Re:Security through Obscurity? (Score:5, Insightful)
Also, did you bother reading what this exploit does? It is very bad because it allows user programs to gain administrator privileges. This is insecure because it puts Linux in a category that's as insecure as all pre-vista windows computers and also the UAC-enabled-because-else-it-is-useless vista and 7 computers. That's the problem here, it moves Linux to a windows state...
Finally, it is easier to find flaws in Linux, this increases the chances blackhats found bugs, but it also increases the chances someone else will find it in paralel, preventing your hypothetical situation...
Ironically, it is because of some artificial obscurity that this bug was present and took so long to find. Most vulnerabilities aren't caused by obscure optimization issues, and are findable in source code, those were a non-issue thanks to the lack of obscurity. So this actually proves obscurity != security.
Re: (Score:3, Insightful)
You clearly don't understand what is meant by quick. Quick is the time it takes to patch the bug from the point it's determined that it exists.
How do you know when Microsoft plugs a bug in the Windows platform? Do you keep track of their internal repository? What matters is when the patch gets to the users of the system, not some bleeding edge repository. It's still not in the hands of Linux users. If it gets there in less of the time than Microsoft can push a patch out for their platform, then it's faster. It being in the bleeding edge repository is meaningless.
Re:Security through Obscurity? (Score:5, Informative)
Generally people don't care about local privilege escalation on Windows. Like this vulnerability [microsoft.com].
Re: (Score:3, Insightful)
Linux runs on a lot of shell servers, gameservers, webhosts etc. where normal user accounts are sold to customers. This happens much less with Windows servers which tend to be more owned and used by a single entity with full admin rights.
Re: (Score:3, Interesting)
Important, not "Critical". And there are a bunch like that on every Patch Tuesday,
-molo
Re:Security through Obscurity? (Score:4, Insightful)
Sure, it was patched, but it wasn't exactly all over the news. Neither is this one for Linux, but it managed to get mentioned on Slashdot.
Local privilege escalation is hard to guard against with current mainstream operating systems. The attack surface is very large and it is hard to completely verify interfaces. That said, Linux team seems to be doing fairly well overall. We're certainly a long way from the "good" old days when crashme would crash pretty much any Unix system. OpenBSD is doing even better, masturbating monkeys or not.
Re:Security through Obscurity? (Score:5, Insightful)
uh huh..and the 8 years it took to discover don't matter, eh?
Re: (Score:3, Insightful)
Yeah, I can't buy this, and neither should you.
Really, just because they're not common knowledge doesn't mean that no one has found them.
Re:Security through Obscurity? (Score:5, Interesting)
Yes, but generally exploits get discovered by others if they are used.
At some point, someone curious will get hacked, and wonder how the hell that happened, and track down the exploit.
And that's not even including discovery on the cracker's side. (People he works with, etc.)
The only way to keep an exploit a secret is to (almost) never use it. It's going to be made public within a few months of even low usage.
Re: (Score:3, Interesting)
Is this like some kind of (biological) virus that might just be out there, wreaking havoc and killing people, even though there's absolutely no evidence of such a virus? That makes no sense at all.
If this exploit were already known by people with malintent, they would have used it already, and it would be known more widely. Note that this works for both open-source and closed-source code. The main advantage with open-source code is that anyone can look through the code for problems; this doesn't mean tha
Re:Security through Obscurity? (Score:5, Interesting)
No. If nobody knew it wasn't a security issue. I'm sure there are bugs on every OS with more than 8 years old yet to discover.
You veered completely off track right about here: "If nobody knew"
Seriously? Really, that's the best you could come up with? That's your apologia? How do you know nobody knew? You think the real blackhats are going publicizing their 'sploits? Blackhats these days aren't script kiddies and honest hackers, they are hard core Russian mafia doing it for cash. Your Linux systems could have been owned twelve ways from Sunday for EIGHT YEARS without you ever knowing it, and you are claiming 'it wasn't a security issue?' WTF? When did Linux get infested with idiot fanboys? Shouldn't you be slobbing all over an Apple or something? I was using Linux before you even knew what Unix was, I despise Microsoft and love open source, but a bug is a bug.
Try this one: 'No. Because it's a freaking LOCAL EXPLOIT and nearly no-one uses Linux for multi-user systems now that everyone can afford their OWN FREAKING COMPUTER.' Good lord, kids these days, gotta teach them everything.
Re: (Score:3, Insightful)
The fact that Travis and Julien found it after eight years pretty much means that the flaw existed in obscurity.
Except for the fact that it was out in the open (being open source and all), which pretty much means it was not in "obscurity".
Just because something isn't known doesn't mean someone is trying to hide it.
Re:Security through Obscurity? (Score:5, Insightful)
Security through obscurity does mean the thought that that as long as no one knows about it, it's not an issue. Being open source doesn't make you immune to this. What would make you immune to this would be formal testing and security audits of every component, like is done on things like the space shuttle. This is generally prohibitively expensive for situations where actual life and limb danger isn't a factor, which is why no commonly used operating system implements this strict security level. Sure, having a lot of eyes looking at the Linux kernel helps (and it eventually worked in this case) but just being open source doesn't mean it's secure.
Re:Security through Obscurity? (Score:5, Informative)
Little faster than that:
-
Solution
-
Linus committed a patch correcting this issue on 13th August 2009.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e694958388c50148389b0e9b9e9e8945cf0f1b98 [kernel.org]
-
Credit
-
This bug was discovered by Tavis Ormandy and Julien Tinnes of the Google
Security Team.
But it was there the whole time (Score:3, Insightful)
I think that's his point. You have, in fact, been able to escalate without privilege for a long time. It wasn't known you could, but that doesn't mean the bug wasn't there. It was "obscure". The reason Linux was secure from this kind of arbitrary escalation was because people didn't know the trick to doing it, not because the security was such it couldn't be done.
I'm not saying I agree with the GP 100% or anything, but he raises an interesting point. One of the oft lauded advantages of open source is the "m
Local vs. remote (Score:3, Insightful)
Which part of "local" are you not understanding?
"Local" doesn't necessarily imply physical access. It simply means that you have gained permission to run arbitrary code as a user on the given system. For example, if you have logged into an SSH account that is local to a given machine, you are local. So first you use a remote exploit to gain local privilege, then you use a local exploit to elevate from there.
I don't get it... (Score:5, Interesting)
Why the bloody hell isn't page 0 hard-wired to panic the kernel / SIGSEGV the userland when accessed?
Re:I don't get it... (Score:4, Insightful)
It's somewhat ironic that this is only exploitable if you have selinux running.. (afaics)
AFAIK it's not SELinux, it's poorly-designed SELinux policies which allow any process to map pages at address zero even if they're not root or not otherwise allowed to do so.
Summary's Useless link (Score:4, Informative)
Here's the real one- linked from (mostly) useless article.
http://archives.neohapsis.com/archives/fulldisclosure/2009-08/0174.html [neohapsis.com]
I can hear the OpenBSD users laughing already... (Score:5, Funny)
Re:I can hear the OpenBSD users laughing already.. (Score:5, Funny)
Sure there are. And they are both laughing.
Re:I can hear the OpenBSD users laughing already.. (Score:4, Insightful)
There's a theme of comments that occur every time another Windows vulnerability happens. It goes something like this:
Windows FanboiIt doesn't matter. Marketshare marketshare marketshare blah blah business drivel Linux has no marketshare!
It's ironic to now see the Linux 31337 in this meme; trying to redirect from security vulnerability to lack of marketshare by a competing OS.
But I guess maybe it goes along with the whole tired 'BSD is dying' theme.
(from the blog) (Score:5, Informative)
In the Linux kernel, each socket has an associated struct of operations
called proto_ops which contain pointers to functions implementing various
features, such as accept, bind, shutdown, and so on.
If an operation on a particular socket is unimplemented, they are expected
to point the associated function pointer to predefined stubs, for example if
the "accept" operation is undefined it would point to sock_no_accept(). However,
we have found that this is not always the case and some of these pointers are
left uninitialized.
This is not always a security issue, as the kernel validates the pointers at
the call site, such as this example from sock_splice_read:
[snip]
But we have found an example where this is not the case; the sock_sendpage()
routine does not validate the function pointer is valid before dereferencing
it, and therefore relies on the correct initialization of the proto_ops
structure.
We have identified several examples where the initialization is incomplete:
[snip]
Local Privilege Escalation On All Linux Kernels (Score:5, Insightful)
sudo
Please, this is a _local_ privilege escalation. It's not like code red infecting your box remotely. A sledgehammer is also a local privilege escalation.
Re:Local Privilege Escalation On All Linux Kernels (Score:5, Insightful)
My guess is that rootkits are being updated as we speak, so get your kernels patched people.
Re: (Score:3, Insightful)
This is easily used as a remote exploit from the looks of it. Someone correct me if I am wrong here. Some of the new linux users are likly getting the impression you need to be physically sitting at the machine.
Say you have virtual server somewhere as is common to most low end VPS hosting companies with linux running on it with a reseller account. What is there a few million of these or more around the World likly?
You have given clients ssh access to use sftp. So, they have limited local user rights, if the
Re:Local Privilege Escalation On All Linux Kernels (Score:4, Insightful)
But if you have any programs that access the Internet that have a bug that allow running arbitrary code, couldn't a remote cracker could exploit the vulnerability in that program to invoke this bug, and through that gain root access to the machine? It sounds like the program being exploited could even be running as a regular user.
Re:Local Privilege Escalation On All Linux Kernels (Score:4, Funny)
SELinux? (Score:3, Interesting)
Re:SELinux? (Score:5, Informative)
SELinux makes the problem worse. Without SELinux, there's a variable that specifies the lowest page in memory that a process can map. If you can't put anything at address 0, jumping through a NULL function pointer isn't as big a deal.
With SELinux on, that variable is ignored, and you can map at address 0 to your heart's content.
Re:SELinux? (Score:4, Informative)
Re: (Score:3, Informative)
From http://archives.neohapsis.com/archives/fulldisclosure/2009-08/0174.html [neohapsis.com]:
-------------------
Mitigation
-----------------------
Recent kernels with mmap_min_addr support may prevent exploitation if
the sysctl vm.mmap_min_addr is set above zero. However, administrators
should be aware that LSM based mandatory access control systems, such
as SELinux, may alter this functionality.
It should also be noted that all kernels up to 2.6.30.2 are vulnerable to
published attacks against mmap_min_addr.
Guys? (Score:4, Interesting)
Some distros less vulnerable by default (Score:5, Informative)
From http://archives.neohapsis.com/archives/fulldisclosure/2009-08/0174.html [neohapsis.com]:
-------------------
Mitigation
-----------------------
Recent kernels with mmap_min_addr support may prevent exploitation if
the sysctl vm.mmap_min_addr is set above zero. However, administrators
should be aware that LSM based mandatory access control systems, such
as SELinux, may alter this functionality.
It should also be noted that all kernels up to 2.6.30.2 are vulnerable to
published attacks against mmap_min_addr.
I have checked my default Ubuntu and CentOS/RHEL boxes, and both of them are set well above 0:
root@Ubuntu:/proc/sys/vm# cat mmap_min_addr
65536
[root@CentOS /proc/sys/vm] cat mmap_min_addr
65536
[root@RHEL /proc/sys/vm] cat mmap_min_addr
65536
Re: (Score:3, Interesting)
on my Debian 5 (Lenny ) it's zero
Re:Some distros less vulnerable by default (Score:5, Informative)
Looks like the only reason to set this to 0 would have been to run wine. For support of 16bit windows apps.
Correct me if I'm wrong.
http://www.linuxplanet.org/blogs/?cat=408 [linuxplanet.org]
http://lkml.indiana.edu/hypermail/linux/kernel/0907.2/01466.html [indiana.edu]
http://lkml.indiana.edu/hypermail/linux/kernel/0907.2/00715.html [indiana.edu]
http://linux.derkeiler.com/Mailing-Lists/Kernel/2009-07/msg08106.html [derkeiler.com]
Re:Some distros less vulnerable by default (Score:4, Informative)
dosemu also needs it to be set 0.
This reminds me of why I use linux... (Score:4, Insightful)
Because we fix it instead of hushing it up until it becomes fairly well known and then waiting a month to fix it.
That said, it's nice to see the occasional vuln in Linux. Helps shut up the fanbois and keep everybody sharp. Because while under many eyes, all bugs are shallow, that only works if the eyes are actually looking.
Eyes Wide Shut (Score:3, Insightful)
Because while under many eyes, all bugs are shallow, that only works if the eyes are actually looking.
For eight long years no one was looking. Tell me again how the geek spins this story in a way that inspires confidence in Linux and FOSS?
RHEL is safe? (Score:4, Informative)
It looks like RHEL's mmap_min_addr (cat /proc/sys/vm/mmap_min_addr) is set to 65536 by default. According to the vulnerability posting:
Recent kernels with mmap_min_addr support may prevent exploitation if
the sysctl vm.mmap_min_addr is set above zero. However, administrators
should be aware that LSM based mandatory access control systems, such
as SELinux, may alter this functionality.
So, if you're running stock RHEL 5.3 without SELinux, you should be safe?
Re: (Score:3, Informative)
You are probably running a kernel that does not have support for vm.mmap_min_addr.
I'm not sure when it was added, but I have kernel 2.6.23 on my desktop and don't have it.
Adding it to /proc would do nothing if the kernel doesn't support it.
"Many eyes", but all of them nearsighted? (Score:5, Funny)
Vulnerable by design (Score:5, Interesting)
In normal configs, Linux is vulnerable to this kind of problem by design because it runs unsafe programs and then for efficiency the kernel also has direct access to it's memory plus the memory for a process doing a syscall. And it's not just a NULL pointer, and preventing maps for page zero doesn't solve the problem... it just means you need to find a bug where you can corrupt a function pointer to point to mappable space.
What this demonstrates is that the cost of isolating programs from each other by using separate memory spaces has a much higher cost than commonly understood. It either has a ~10%-20% overhead and is insecure by design (kernel map includes calling process memory space) -or- it is far slower than even that, but safe (kernel memory is completely separate from process). Computers are already faster than many users need... maybe it's finally time for an OS with a single memory space, like JavaOS or jxos, or even Singularity.
Re:Vulnerable by design (Score:4, Insightful)
In normal configs, Linux is vulnerable
The problem you're describing is not an issue just for Linux but most current 'conventional' OSes. On any OS with a shared memory space as you described, if you can a) 'hack' a pointer, and b) move or map your own code to where that 'hacked' pointer is now pointing to, and c) combine this with some other exploit/bug to get elevated privileges in the code you inserted earlier and take immediate advantage of this, then you can theoretically pwn the system whatever its OS (as always, it depends on the specific circumstances).
As you say, this is fundamentally a weakness of the hardware-assisted approach to process isolation, because in a paradigm that allows modifiable pointers in userland code, neither the hardware nor the OS can ever *really* know what the pointers are actually pointing to.
It either has a ~10%-20% overhead and is insecure by design (kernel map includes calling process memory space)
Not sure I'd go as far as 'by design', at the very least its not an easy exploit to accomplish (not withstanding this latest problem), since it depends on finding at least one bug/flaw in the OS to let you do the first step of 'hacking' a pointer (and usually at least one more bug/flaw to be able to do something really dastardly), but yes, there is an overhead, and its certainly not a perfect model (what is?).
maybe it's finally time for an OS with a single memory space, like JavaOS or jxos, or even Singularity.
If they can get it right, absolutely.
In fairness however, these OSes accomplish their goal by restricting you to a type-safe language(s), in effect, they (try to) avoid the problem of pointers being 'hacked' by eliminating the presence of writable/modifiable pointers that *can* be 'hacked' within running code. They use the strictness of the language as the protection mechanism, rather than hardware assistance. This however is not trivially easy to accomplish either (see jxos and their 'Isolates' mechanism they're having to shim into their system), which is why these OSes remain work-in-progress research projects. Then, once they do get it right, we won't be able to just 'port' all our current software over and take off, nope, all the software we use now will have to be rewritten in a type-safe language that that OS supports (or thrown out!), so the switching over process won't happen anytime soon. :(
It is a 'cool' idea though, if for no other reason than it avoids the overhead of the hardware assisted model, and eliminating modifiable pointers (at the source code level) in code will allow smarter static/jit compilers to safely do *far* more aggressive optimizations than they can do now, as modifiable pointers (especially if they can also be aliased) are the single biggest headache for any optimizing compiler.
If Windows is your metric (Score:3, Funny)
Linux is ready for the desktop!
Re:pwned (Score:5, Insightful)
Re:pwned (Score:4, Insightful)
Expect a source fix with no regression testing in a week or less. Wait months for the big distribution makers (RedHat, Novell) to release it to the masses.
Expect people manually rebuilding their kernel in panic, having machines rendered unbootable because they decided the 250$ bucks for the iLO Advanced license wasn't worth it since Linux never crashes, etc. pp.
Face it: IT sucks. The OS matters little.
Re:pwned (Score:4, Informative)
I'd rather expect a patch within 4 hours (cutting functionality) and a real fix within 24-48 hours and then I would expect most big distributions to have fixed packages out in less than 5 days (linux kernel takes a while to compile). More rapid distros might even have two fixes - a fast fix within 24 hours and a real fix in less than a week after that.
Re:pwned (Score:5, Informative)
And if any of us would have read the article before posting we would know that a typical one-line fix is right there in the article and has been commited into the kernel mainline yesterday.
Re: (Score:3, Informative)
Committed to the mainline kernel != Available as an update to [CentOS|RedHat|Debian]
Re:pwned (Score:5, Funny)
See? All that testing is worth it after all!
Re:pwned (Score:4, Insightful)
Re: (Score:3, Insightful)
The flaw has been around since 2001.
There goes your theory. ;)
Re:pwned (Score:5, Informative)
In a week or less?
Linus already patched it.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e694958388c50148389b0e9b9e9e8945cf0f1b98 [kernel.org]
He wrote it at 8:28AM and committed it at 10:57AM this morning. Expect to see it in your repositories tomorrow, if not sooner.
Re:pwned (Score:5, Interesting)
Of course, if you add a local privilege escalation to a some app remote vulnerability that enables to run code, even if is with low privileges, there you have a potential remote root exploit. Is something to care about, but odds are low that a lot of systems will be affected.
Re:pwned (Score:5, Insightful)
How much local privilege escalation vulnerabilities normal windows users worry about?
They probably don't worry about it at all because the vast majority of Windows users log in and run with an administrative level account in the first place.
Re: (Score:3, Insightful)
Of course we'd never hear the end of it, because we paid a shitload of money for a system that would be vulnerable for months until MS would decide to release a patch that wouldn't conflict with the rest of the bloat. That wasn't always the case, but it's what happened most of the time when Windows (as an operating system) got pwned with an exploit like this. There are still tons of unpatched Windows computers infected with Blaster... as long as you still hear about Blaster, you'll still hear about the vuln
Re:pwned (Score:5, Informative)
Replying to myself, with additional information for the OP: And how long have we heard about this [microsoft.com]? We're already so used to Windows exploits that we don't even care much about them...
Re: (Score:3, Funny)
Well - I'm searching for Linux botnets that have been created by this exploit. Searching . . . searching . . . searching . . .
Dang, I'm not finding any.
How about Windows botnets? WOW, will you just look at all of them? http://www.secureworks.com/research/threats/topbotnets/ [secureworks.com]
I sure wish Linux would get off their dead arses and patch this problem. Sure would be nice if they can get it done in less than a month or six, like Windows!! Oh - wait - what? Linus committed a patch correcting this issue on 13th
Re:pwned (Score:5, Funny)
Well by that logic 99% of windows users haven't used a real windows machine either.
Re: (Score:3, Funny)
Yeah, I know, I nearly cancelled the post after I wrote it.
Desktop Windows /is/ Windows, but Windows Servers are far more inherently secure than Windows Desktops, simply by the way that they're operated. It was a bad comment.
Re:pwned (Score:5, Funny)
Aw, cheer up little guy. I thought it was a very nice comment.
Re:pwned (Score:5, Funny)
Windows Servers are far more inherently secure than Windows Desktops, simply by the way that they're operated.
Wait, what?
Re:pwned (Score:4, Funny)
But it wasn't a real "no true scotsman" fallacy. After all, it didn't involve a scotsman. :-)
Re:pwned (Score:4, Insightful)
Yes, hardened windows is reasonably secure. After you spend an hour or two installing all the third party software and configuration settings you need to prevent being owned in under five minutes. Or you can just install Ubuntu.
Yes, Ubuntu. Which apparently you don't need to configure at all to get owned.
Seriously, in a story about how trivial it is to get code to execute as root you post a comment about how much more secure Ubuntu is than hardened Windows?
Re: (Score:3, Informative)
Um...are you referring to a physical attack? No unencrypted machine is even remotely resistant to that.
This particular vulnerability probably affects ubuntu (depending on the mmap status; certain default settings can actually prevent this), but I'm speaking generally.
Re:pwned (Score:5, Informative)
That's right. It's a trivial local exploit. Those aren't mutually exclusive.
Re: (Score:3, Insightful)
Buzz off, little worker bee, its simply not the case: this happens once every, say, couple to four years in Linux. Microsoft has one of this bugs every couple of sundays.
Citation needed.
Re:pwned (Score:4, Informative)
Possibly, for sufficiently loose definitions of "much more".
Linux kernel 2.0-2.6: 279 Secunia advisories, 473 vulnerabilities
Windows 2000 Server + Windows Server 2003 Standard + Windows Server 2008: 472 Secunia advisories, 580 vulnerabilities
It's also worth noting that kernel 2.6 alone contains 186 advisories for 352 vulnerabilities with 6% unpatched. Windows Server 2008 contains 40 advisories for 82 vulnerabilities with 0% unpatched.
So there's the math. Keep in mind that's comparing an entire server OS with just the Linux kernel.
We are now that picky...
This is Slashdot. We've always been that picky.
Re:pwned (Score:4, Funny)
Thats what I get for sending you to do the math. Im still too lazy to go check it out and look at methods, years and the rest.
||sarcasm|| I take your analysis as true and hereby declare that windows has been exploited lesser than linux, has less malware against and is inherently less prone to attack than linux or turning into a braindead spamzombie than linux. ||end sarcasm||
Happy?
Your new math is very flawed. (Score:5, Informative)
It's also worth noting that kernel 2.6 alone contains 186 advisories for 352 vulnerabilities with 6% unpatched. Windows Server 2008 contains 40 advisories for 82 vulnerabilities with 0% unpatched.
Your comparison is very flawed and meaningless. Linux kernel 2.6.0test was released in 2003--IT HAS BEEN AROUND 5 YEARS LONGER THAN SERVER 2008! If you want your math to actually make a real point try integrating the vulnerability rate of each OS over the same time domain. Simply put, you have to look at the combined vulnerabilities reported by Windwos Server 2003 AND 2008 when comparing against Linux 2.6.x kernel based OSes.
More proper numbers for Windows would be 242 advisories for 341 vulnerabilites. Slightly lower vulnerability count but quite a few more advisories. 6% of these vulnerabilities also remain unresolved. These numbers do not show Microsoft having any meaningful advantage in quality over the Linux kernel
And, to be more fair still, you should compare OS to OS as you said, rather than OS to kernal. For RHEL5 OS the stats are 272 advisories for 828 vulnerabilities and zero unresolved (suggests that one advisory and pne patch probably solves many separately counted vulnerabilities--perhaps because Linux-based OSes leverage shared libraries far more than Windows?) Keep in mind, however, that Comparing SLES or RHEL strictly speaking wouldn't be a complete comparison either, because in Linux OS distributions many applications are included where the equivalent in Windows would be separate (possibly extra-cost) add-ons.
Furthermore only counts are considered above, with no factor for intensity. Windows server 2008 has more than double the rate of "highly critical" vulnerabilities (35%) than does RHEL5 (16%) and it is well known that Linux exploits are far less likely to be directly remotely exploitable than is the case for Windows exploits.
Yes, MSFT has made great strides in closing the quality and security gaps in ther server OSes (quality is still sorely lacking in their desktop offerings), but even if Windows was perfect I'd still prefer a Linux OS or OpenBSD:
* can't afford Ballmer'$ ga$
* Windows is closed--I don't trust what nobody but the vendoar/author can see. Secunia et al can only report what they can observe from behaviour. As in this reported Linux exploit, third-parties can perform extremely detailed analysis with source code at hand, often releasing the patch to plug the exploit right along with the exploit itself.
* licensing and actrivation take a lot of time and resources that serve no practical purpose than to enforce an increasingly questionable business model--Activation is pure bulls**t. I've wasted FAR too much time on clients issues where the root cause of functional deficiencies was improperly activated/licensed closed software (be it Windows or others). I've HAD it with closed crippleware.
* I like to tinker. I like to build. The playing field is for more flat in Free software land than in Windows land. I can reconfigure kernel modules, choose which web server, DNS server, email server I want to use and evaluate them truly on their merits. In Windows, if you think IIS or Exchange or MS DNS Stinks, you can try the alternatives but they always seem hobbled by comparison. MSFT never lets third parties play by the same rules, especially when server apps are considered "windows componenets" like with IIS and DNS. They get to leap MSFT's long-professed "chinese wall" to get total access to OS internals info others do not have. ANYONE who wants to write server apps on a Free platform has the same access to info.
Re:pwned (Score:4, Informative)
XP Home Edition, Unpatched 12% (27 of 229 Secunia advisories), Most Critical Unpatched: Moderately critical.
Ubuntu 9.04, Unpatched 0% (0 of 50 Secunia advisories).
Keep in mind that Ubuntu is also affected by standard apps like OpenOffice.org, Firefox etc. If you're going to pick server versions to prove a point...
Re: (Score:3, Insightful)
So wait, the "exploit" is to run untrusted code as admin? That is not a privilege escalation attack. How is this different than running any malicious code?
Re: (Score:3, Informative)
Modern windows has many levels of "admin".
But let us say that the admin accounts are are now by design almost the same as regular user accounts. By default they should not be able to harm the system. If you deliberately elevate an application to full rights (equivalent to using sudo to run the program) then it can do anything.
The problem here is that an unelevated application can just inject code directly into the memory space of certain other unelevated applications which can elevate themselves at will wit
Re: (Score:3, Insightful)
Re:The REAL impact here (Score:4, Informative)
Within a few days, patches will be released to all the OSS vendors. Admins will be inconvenienced by a reboot.
Even that last bit is avoidable, if you have Ksplice [ksplice.com] installed :D
Re:The REAL impact here (Score:5, Insightful)
How can you trust that a user hasn't used a privilege escalation to install a rootkit already? You can't trust apt-get, or yum, or anything.
Fresh install time, surely? Back to the bare metal.
Re: (Score:3, Funny)
Probably don't need to install the patch then. Or keep the machine powered on, for that matter...
Re: (Score:3, Informative)
You could measure it with a stop watch.
Indeed. Patch was committed 16 minutes after that blog post and 3 hours, 57 minutes before this story hit the front page.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e694958388c50148389b0e9b9e9e8945cf0f1b98 [kernel.org]