Root Privileges Through Linux Kernel Bug
Lars T. writes "The H has a story about a Linux kernel bug that allows root level access. 'According to a report written by Rafal Wojtczuk (PDF), a conceptual problem in the memory management area of Linux allows local attackers to execute code at root level. The Linux issue is caused by potential overlaps between the memory areas of the stack and shared memory segments.' SUSE maintainer Andrea Arcangeli provided a fix for the problem in September 2004, but for unknown reasons this fix was not included in the Linux kernel. The bug is not related to the X Server bug found by Brad Spengler."
As the linked article notes: "SUSE itself has the fix and SUSE Linux Enterprise 9, 10 and 11 as well as openSUSE 11.1 through 11.3 do not exhibit this vulnerability."
How can the two bugs be unrelated? both articles have the exact same link to the exact same PDF! (Hint: the pdf's filename is xorg-large-memory-attacks.pdf on both).
Indeed, 5 years old and no exploit. Patched several years ago by the distros. The question is why didn't it get back into the kernel tree.
No, just that this particular bug has been patched in SUSE for six years, while mainline has only just gotten the fix.
cat:
From the RedHat bug report: Eugene Teo (Security Response) 2010-08-12 21:44:06 EDT Linus has committed a fix for this issue: http://git.kernel.org/linus/320b2b8de12698082609ebbc1a17165727f4c893
I wonder how many bugs like this are lurking in closed source products, just waiting to be discovered and exploited?
I Am My Own Worst Enemy
Indeed, 5 years old and no exploit. Patched several years ago by the distros. The question is why didn't it get back into the kernel tree.
Why not ask the kernel developers? Nah, I'm not just joking, don't ask those nutjobs anything, they'll just freak out and start yelling at you.
If I read the git patch correctly, if said root process has a memory-mapped page coincident with a non-root process, and the non-root process can write to said memory mapped region (via having it memory mapped into their own process), then said non-root process can affect the behavior of the root process.
What was broken, and appears to have been corrected, is that an application's *stack* could grow into a memory-mapped page and corrupt the data in the root process while it's at it. (The stack is a piece of memory that hold data about the functions currently executing in a particular thread in your program.)
(enter educated guess section; I spend most of my time coding userland apps on Windows, not Linux.)
The case where this seems most possible to exploit is the loading of shared libraries. I don't know if the same mmap mechanism is used by the kernel, though. While it's entirely probable that writing to that region is protected, so long as the application is doing so under its own memory privilege level, it's possible that there's a syscall into the kernel that expands a thread's stack when the allocated memory for that stack is nearly exhausted. The syscall's operations run with kernel privileges, and it looks like the stack page allocator wasn't sufficiently checking the properties of the userland address it was allocating stack into.
(end educated guess section; I'm probably wrong, anyway.)
tasks(723) drafts(105) languages(484) examples(29106)
Then why wasn't the patch submitted to mainline six years ago? Or if it was, why did it take so long to get accepted?
Today is red jello day - all workers must eat all of their red jello. Failure to comply will result in five demerits.
No, normally access to the machine at user level should not imply access to the machine at root level.
The Tao of math: The numbers you can count are not the real numbers.
Why not ask the kernel developers? Nah, I'm not just joking, don't ask those nutjobs anything, they'll just freak out and start yelling at you.
I've seen many similar statements, so there may be some truth to this, but my experience is that they give you a short-as-possible only-most-relevant question such as "Can you bisect?" or reply like "Patch rejected: missing signoff". It appears their time is very valuable or they have to pay $5 pr. typed letter.
9/11: Never forget it was a false-flag operation
Actually, no, this is a simple Stack Buffer Overflow. Basically, by causing a running privileged process (e.g. X Server) to make a recursive call, the stack will grow into memory space owned by the unprivileged user. Now, all the unprivileged user has to do is put some code somewhere (perhaps by exploiting another buffer overflow) and rewrite the return address, which lives in its memory page.
The fix adds a guard page between the shared memory region and the system stack to protect against the stack growing into memory where it is no longer protected. At any rate, ProPolice would have prevented this mistake from being exploitable.
"Please describe the scientific nature of the 'whammy'" - Agent Scully
I think ssh counts as access...
Wait...they didn't already have a guard page? I kinda assumed that was already there. Ow.
*marks self down as "needs improvement" in patch reading comprehension skills*
tasks(723) drafts(105) languages(484) examples(29106)
If it's a non-story then why did Linus patch it today? Apparently he didn't agree with your flippant way of looking at OS security.
I wonder how many bugs like this are lurking in closed source products, just waiting to be discovered and exploited?
I wonder how many bugs like this are lurking in open source projects, just waiting to be discovered and used against people that assume that the software they use is secure because they read Slashdot comments.
"I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)
What part of "local attackers" do you fail to understand?
Seven puppies were harmed during the making of this post.
At least we don't have to wait for four Tuesdays' time for the fix...
You're holding it wrong.
Sometimes people make mistakes.
Cut the guy a break, he's a Windows fanboy. He probably thinks a local user is just anyone in the same geographic region.
"When information is power, privacy is freedom" - Jah-Wren Ryel
Cut my post too short.
"SUSE maintainer Andrea Arcangeli provided a fix for the problem in September 2004, but for unknown reasons this fix was not included in the Linux kernel"
Amazing that SUSE fixed this in it's distro. In the proprietary world they'd still be waiting for the OS maker to fix it. SUSE just fixed it themselves. Many windows bugs could have been fixed but yet remained waiting for years until MS got around to it.
He's a troll, but that doesn't mean that there isn't a grain of truth to what he implies. Most Windows exploits are also technically local attacks, as are Trojans (by definition). Somebody thinking that they're safe (because the software runs with limited permissions) would be in for a nasty surprise if an attacker exploited this.
There's no place I could be, since I've found Serenity...
Indeed, 5 years old and no exploit.
How do you know?
Give me Classic Slashdot or give me death!
Behold the phenomenal power off Open Source! The time of each and every kernel developer is in fact a highly valuable commodity, yet I get the benefit of the fruits of their labor without shelling out a sixpence! And the best part? This was fixed last week.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
a redundant first post...?
So I read the PDF...
which is the patch.. "Patch "mm: keep a guard page below a grow-down stack segment" has been added to the 2.6.32-stable tree"
and meanwhile my ubuntu update managaer pops up and shows an update for the kernel and gives the following link to the changelog...
http://launchpad.net/ubuntu/+source/linux/2.6.32-24.41/+changelog
Nice to see people are on the ball with security updates, even if it shouldn't have been happened in the first place.
Bugs are apart of software as a whole. Every program open or closed is vulnerable to some kind of bug. The difference being however that with linux bugs I tend to hear about them after I already downloaded the fix.
Look at this graph: http://linuxinsecurity.blogspot.com/
Please do. Notice how the graphs show Windows with 10-12% of the issues unpatched?
That's the problem. Well that and the missing graph showing "time to patch"...
This sig intentionally left blank.
So, only 6 years late then? SuSE just went way up in my book.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
a redundant first post...?
Yes, there was a redundant x in "h4xx0r5".
Compare this to Apple, which still hasn't fixed my Darwin kernel ring 0 exploit, which I reported in June.
It's x86-only, so no, it can't be used for the second step of an iPhone jailbreak. =(
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
If you really want to get a fix in, the correct procedure is to keep pestering the maintainer for that area until they accept your patch. If you can't get them to accept it, you go up the chain.
Yes, in an ideal world all maintainers would be perfectly organized. In the real world things get lost, they get distracted, other issues pop up, and the patch doesn' t make it in.
If you care about it...make some noise.
This won't be a problem for me since I don't run Linux.
Now the shoe's on the other foot!
Yes, something is seriously wrong with this comparison. You compare a clean and unused operatingsystem with a fullfledged Linuxdistribution with a lot of applications.
Of course the Linuxdistribution will have more bugs, but you dont have to install all the software that comes with it. On the other hand, to be able to use the Windows server to something useful, you have to install more Microsoft and/or thirdparty software. It isnt even a webserver without installing more software in Secunias statistics. IIS has its own category.
Dont compare apples and pears, you will only fool yourself.
Suse developers suggested a fix for this vulnerability six years ago http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-09/7904.html however for reasons unknown it wasn't noticed or merged.
Indeed, 5 years old and no exploit.
You can't be sure of that.
Also that full fledged linux distro has a single update mechanism for all of the applications... If you install equivalent apps on a windows system chances are they will need their own separate update mechanisms, or not have an update system at all, which massively increases the chance of unpatched apps being present.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
It's funny to see the windows people taking such satisfaction in Linux bugs and completely disregard the time it takes from disclosure to a fix is available. Usually I've already installed the fixed version before I read about it on slashdot. It's just a matter of subscribing to my distro's security announcement mailinglist and upgrade if I run the affected software.
So in most cases, when i read about bad bugs in Linux it's 'old news'.
(Blatantly ignoring the six years it took to actually get the fix into the kernel this time)
Comment removed based on user account deletion
You're lucky to get a "Can you bisect?"
All I got was a "Does it blend?" and a derisive snort.
WARNING: Smartphones have side effects--most of them undocumented.
I can audit the code myself, or pay someone else to audit it. Also thousands and possibly millions of people are already auditing it, for free! I can fix the bugs myself, or pay someone to fix them.
I Am My Own Worst Enemy
The difference being however that with linux bugs I tend to hear about them after I already downloaded the fix.
That's called a false sense of security.
"I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)
No, it's simply a small piece of evidence that Linux gets fixed faster then windows does.
A vulnerability in a graphics-decoding library used by IE is a local exploit, but it can be used by remote attacks who embed a malicious image in a website or email. That would meet exactly the description you gave, for the way that MS words their patch notes.
Just because a vulnerability is local doesn't mean it can't be triggered remotely. It simply means that something needs to be done on the local machine - such as visiting a web page, reading an email, or running a supposedly safe command - for an exploit to occur. True remote vulnerabilities are also still found on rare occasion, but they've become extremely uncommon; external interfaces are subject to extremely heavy testing these days.
There's no place I could be, since I've found Serenity...
Right. Like I said, a false sense of security. Think about the ramifications of what you're saying.
"I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)
I view this as SuSE seeing the critical nature of the patch and including it irrespective of what Linus or the other kernel team guys think.
That this was not included after submission was a fairly serious error.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
By that reasoning would not all attacks be local attacks? What would be an example of a "true" remote attack?
I judt got a nre Kinesis keybiartf so please excusr ant egregiou typos.