8-year-old, trivially exploitable, critical Linux vulnerability discovered

Update your kernels, folks. If you can't, at least put up a firewall.

 

Why? Linux doesn't have the userbase to discover exploits fast, or for people to actively look for them. That's probably one of the only good reasons for having a large userbase, can't really think of any more.

 

Oh my, I'll get right on it!

 

These kind of bugs are in all systems.

Its a bit misleading to summarize it as trivially expoitable.

Its trivally expolitable now.

It took 8 years for it to be publicity discovered though.

That's 10 bugs in a persons lifetime. Not a bad record.

 

Only thing is you need to of gainned access to the system in the first place to actually run the exploit.

 

Way over my head, but apparently on Red Hat systems is only exploitable
when SELinux is enabled and in permissive mode, and then only when access
is gained as mentioned by Nick Rhodes.
Hope there will be a kernel update to all affected distros real soon. Less
knowledgeable users like me are really worried.

 

If I read correctly, it's local, so nothing to worry about.
Mrk

 

Doesn't local privilege elevation - since this is a kernel vulnerability - mean that various forms of MAC may be bypassed, putting users' data at risk if an application gets compromised?

 

Sure it does, but if you have a "rogue" local user, they can do far more than that. They can boot into single mode or from live CD, change the root password and then do anything they want ...

Local vulnerabilities are only a worry for companies, usually not home users.

Cheers,
Mrk

 

The problem with "local" privilege escalation is that it's not necessarily that local in all cases. Let's imagine a scenario where there are occasional vulnerabilities in popular software like browsers that allow remote execution of code with the privileges of the user running the browser (of course not root, I should hope!) and let's also imagine that if we don't have any such vulnerabilities available for "use" there's always the chance that we might be able to fool some users to execute our code in an unprivileged user account - this is pretty much how it is in the real world. Let's imagine that someone exploits one of those vulnerabilities remotely, for example by luring us to some exploit site or hacking our favourite forum to serve the exploit, or gets us to run their malicious file as an unprivileged user. Now they can run code on the system with all the access of an unprivileged user. And guess what. If the code that they are able to run is code to exploit one of these "local" privilege escalation vulnerabilities, then they get root, and own me. So...

Yes, that's a lot more complicated an attack than just being able to happily get root from remote by exploiting one single vulnerability (instead of the two required in the previous scenario) but it's still hardly impossible, and I would call that an issue. Nothing to lose sleep over, but nothing to scoff at, either.

Well... that might be the case if this one actually was the only vulnerability discovered in the kernel during the last 8 years. Which it of course isn't...

To summarize? It's a vulnerability. They happen. They'll be fixed. Life goes on.

 

Did no one notice that this "vulnerability" only applies to an obscure application that very few people use?

This from Linus himself:

Make sock_sendpage() use kernel_sendpage()
author Linus Torvalds <torvalds@linux-foundation.org>
Thu, 13 Aug 2009 15:28:36 +0000 (08:28 -0700)
committer Linus Torvalds <torvalds@linux-foundation.org>
Thu, 13 Aug 2009 17:57:26 +0000 (10:57 -0700)
commit e694958388c50148389b0e9b9e9e8945cf0f1b98
tree 492a61009732cd0c468d4c0faa41321414ea43a7 tree | snapshot
parent a3620f7545344f932873bf98fbdf416b49409c8e commit | diff
Make sock_sendpage() use kernel_sendpage()

kernel_sendpage() does the proper default case handling for when the
socket doesn't have a native sendpage implementation.

Now, arguably this might be something that we could instead solve by
just specifying that all protocols should do it themselves at the
protocol level, but we really only care about the common protocols.
Does anybody really care about sendpage on something like Appletalk? Not
likely.

Acked-by: David S. Miller <davem@davemloft.net>
Acked-by: Julien TINNES <julien@cr0.org>
Acked-by: Tavis Ormandy <taviso@sdf.lonestar.org>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>


And, once again, this so called vulnerability has already been patched without ever having been exploited. Much ado about nothing, as The Bard once said,

 

One can be at a physically remote location and still gain "local access." Local just means an existing user account, and one can login as an existing user remotely. Of course, if one only has one user account on the machine, then the attacker would have to crack the user account before he could run this exploit.

Basically, this exploit is really nothing to worry about for home users (since most home users don't run listening services). However, if you run Linux servers where there are multiple users, then you might want to take notice.

 

If you read the quote from my previous post you will note the patch;

Code:

Make sock_sendpage() use kernel_sendpage()

that cures the problem for the rare user that uses appletalk or other phone app that doesn't handle the paging feature correctly. This is a total none issue.

 

Patch now in repos. http://www.ubuntu.com/usn/usn-819-1