Exploits Emerge For Linux Privilege Escalation Flaw 176
angry tapir writes "Linux vendors are rushing to patch a privilege escalation vulnerability in the Linux kernel that can be exploited by local attackers to gain root access on the system. The vulnerability, which is identified as CVE-2012-0056, was discovered by Jüri Aedla and is caused by a failure of the Linux kernel to properly restrict access to the '/proc//mem' file."
Broken on Android too (Score:2, Interesting)
Awesome that this will lead to easier root access on Android devices.
On the flip side I'm sure Android vendors won't get around to patching this for a while and our devices will be vulnerable.
Now, off to patch my Linux boxen.
Re: (Score:3)
Re: (Score:2)
Re:Broken on Android too (Score:4, Informative)
Re:Broken on Android too (Score:5, Funny)
Really? This bug was only present in kernel releases 2.6.39 and newer. Do any Android devices use kernel's based on a Linux this current? A quick search says Android 2.3. used 2.6.35 and 3.0 used 2.6.36 so the number of devices this might possibly help you root looks miniscule.
I am replying with my new Asus Transformer Prime, which is running ICS(Android version 4.03), kernel is 2.6.39.4.
I'm thinking this bug is God's way of saying "You are loved. Now go forth and exploit your tablet!"
Re:Broken on Android too (Score:4, Informative)
However, you need Ice Cream Sandwich and you will need access to a disassembler. Also, you cannot use this exploit for "one-click" root access as the only program that is in the Android stack that runs setuid root, is run-as. That command is statically linked so you will still need adb access so that you can disassemble the program to find it's exit call.
So there is still a fair amount of work left to be done to make this an exploit that can be used in the "wild" for Android devices. However, as a fair note. A little crowd sourcing to compile a list of offsets for different devices could greatly speed up the process. I'm actually curious if Google will patch this in there kernel.
Re: (Score:2)
our devices will be vulnerable
only if you're dumb enough to install apps like "HotNakdChyX" from "WeRHaXorZ" that require every permission possible
Re: (Score:3)
If your browser/flash player/some other legit app has a zero day that allows the execution or arbitrary code you are just as screwed as if you install a malicious app.
Re: (Score:2)
Javascript could be a possible vector, but seems like a bit of a long shot.
I think the majority of malware development on Andriod is probably focused on the ignorance of users just installing apps that require ridiculous permissions. If the user wants an app/game enough, they are likely to accept whatever permission it says it needs regardless of whether it actually needs them or not.
Secur
Re: (Score:2)
Re: (Score:2)
You are almost right. Sadly, some of us need flash and java to do our jobs. F*** You Cisco!
Re: (Score:3)
Pinky, are you thinking what I'm thinking?
Re:Broken on Android too (Score:5, Funny)
Wuh, I think so, Brain, but if we didn't have ears, we'd look like weasels
Re: (Score:2)
Re: (Score:2)
Hrrm (Score:5, Insightful)
If someone is in a position to run a local exploit, aren't you pretty much fucked anyways?
Re:Hrrm (Score:4, Insightful)
Re:Hrrm (Score:5, Insightful)
Web servers are vulnerable because they run server side code, often uploaded with vulnerable content management systems, etc.
Re: (Score:2)
Right, because no organization would give their employees user access to a machine but not root.
Re: (Score:2, Insightful)
Of course. The best local exploit is a screwdriver and a spare moment or two.
Some quick contrarian rules:
Rule #1: There is no such thing as 100% secure. Even 100% bug-free cannot be considered 100% secure. It may work according to the design, and the design can be 100% correct today, but today is not tomorrow.
Rule #2: The more complicated layers of security you add, the more security holes you add. For those into car analogies, security always ends up being bolted on, like bondo dent filler, becau
Re:Hrrm (Score:5, Informative)
Re: (Score:1)
It's not "nonsense" for physical security, for hashed passwords, one-time pads, or for biometric security (and biometric is the biggest joke of all). Given enough knowledge and physical access, ALL security can be defeated, either by gaining access or denying the recipient access, or both.
Beware of ALL blanket statements ;-) (Score:5, Insightful)
You either don't know what the word all means, or you don't know what the term security through obscurity means.
Re: (Score:2)
You either don't know what the word all means, or you don't know what the term security through obscurity means.
It could be worse. He might not know about or, either.
Re: (Score:2)
(Barbara is presumably a woman's name)
Re: (Score:2)
You had your retina locked in a box? Holy shit.
Re: (Score:2)
Re: (Score:2)
the hard (impossible?) part is actually being able to hide something in plain view
the best that sysadmins can achieve in their time and budget is probably a mixture of conventional authentication with a bit of "security by obscurity", as the aim of many security specialists isn't to make a system totally secure but to simply make it more secure than it was before so
Re:Hrrm (Score:5, Interesting)
There's also no such thing as 100% bug-free.
While in the strictest sense, this may not be untrue, to phrase it that way is extremely dishonest. An encryption algorithm that relies on the secrecy of the algorithm is totally worthless (security by obscurity), whereas an encryption algorithm that relies on the secrecy of the keys used for encryption is quite useful (not security by obscurity in the normal sense).
In fact, if you want to be pedantic about it, the relevant definition for obscure is...
not readily understood or clearly expressed; also : mysterious [1]
Which is about understanding and not so much about knowledge. I may understand that I need a username and password to log into your system, just because I don't know what the username or password is doesn't make it security by obscurity. In fact, say I wanted to break into your house, I may have seen you use a physical key to open the front door and walk in and I may have even memorized the pattern of teeth on the key, but it does me no good if I don't have a key of my own to open the door with. There is certainly no obscurity in that security.
If you're going to go ahead and say that all security is "security through obscurity", then you may as well make the next logical step of not implementing any of it.
[1] http://www.merriam-webster.com/dictionary/obscure [merriam-webster.com]
Re: (Score:1)
Your "contrary example" actually proves my point.
Once you have the pattern, you no longer need a key of your own - you just go and get one manufactured. Or you take a blank and you file it down.
Proof you are 100% wrong per your request (Score:5, Insightful)
Re:Proof you are 100% wrong per your request (Score:5, Insightful)
Re: (Score:2)
Do you have a problem reading and understanding the English language? While I appreciate your attempts to credit the definition as my own, it has been an accepted term in security circles for a long time, and I am not the one who came up with it. Nobody worth their salt ever said that 100% security can be achieved, and you are not saying anything that isn't obvious to even a security neophyte like yourself. What is known is that security through obscurity is not an effective method of achieving security, even in deference to the fact that nobody will ever achieve 100% security.
It's a very accepted term, but you're not using the accepted definition. You're equating "obscure" with "secret". If I look at a security algorithm and by doing so enables me to break into whatever it's protecting, that's security through obscurity. If I look at one but still something like keys or passwords, that is NOT security through obscurity. Yes the keys or passwords are "obscure" but they _have_ to be, and that's not what people mean when they use that word.
Re: (Score:2)
Re: (Score:2)
Yeah, I misquoted. Sorry about that. And I was telling Barbie that the mistake IS considering secret and obscure to be the same, but they're not.
Re: (Score:2)
Just a point of clarification: you quoted obscure, but it ultimately leaves the impression that you could use the terms interchangeably, and feeds the confusion a bit.
Re: (Score:2)
The industry attempt to re-define "obscurity" is stupid, because it hides a few simple facts For one thing, how many people have secret passwords that are actually secret, in that they are obscure, rather than something personal, like the name of their pet, their birthday, or their kid?
Passwords are a classic example of the failure of "security through obscurity" - look under your co-
Re: (Score:2)
that you don't have the password to access a system doesn't make a password authentication security measure "obscu
Two can play at that game (Score:2)
12: to conceal
Concealing your password (as opposed to sticking it on a post-it or in your signature) is very much "security through obscurity."
That you can't understand that all security ultimately is based on something concealed is sad - it means you'll believe that things like biometrics are secure, when they're not (and they're also very much based on hiding something, both at the design and implementation levels, as well as the user level. If I have the information needed to
Re: (Score:2)
at the end of the day though, the accepted industry definition only relates to the one I put forward, which is quite acceptable (it still fits into a definition, even if its not the one you like best).
That you can't understand that all security ultimately is based on something concealed is sad
but I do understand that security is based on something concealed. what i'm trying to get you to understand (among other people who have apparently also been wasting their breaths) is that "security by obscurity" has an accepted meaning, and tha
Re: (Score:2)
every bit of hiding (obscuring) information helps
"security through obscurity" is sometimes implemented in addition to authentication as part of "defense in depth"
an example of this (which fits the accepted meaning of "security by obscurity") is setting the "ServerTokens" directive in "/etc/apache2/conf.d/security" to "Prod" so as to hide the Apache version number in the default error pages... many webmasters do this, but only in addition to other security measures as required (not as their primary security measure). While not usually that much of an i
Re: (Score:2)
I'm well aware of it - and I think it belongs in the trashbin, along with "best practices" (which is an excuse not to fix things because they're "good enough" - which is why Gates used it so often when people complained about the suckiness of Windows - "we use industry best practices.").
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
I'm a bit lazy, though I have intercepted some bots (using PHP's $_SERVER["HTTP_USER_AGENT"]) and served them up cute messages before.
Re: (Score:2)
Earlier you made the following statement:
Rule #3: All security is ultimately "security through obscurity."
That is what is under debate. Is it true that all security is "security through obscurity"? There is a difference between understanding how an encryption algorithm works (obscuring an algorithm), and knowing a particular key to decrypt ciphertext using that same algorithm (obscuring an input to that algorithm).
For instance, it is possible to understand how the Diffie-Hellman algorithm [wikipedia.org] works works -- meaning it is not obscure -- and yet still be unable to decipher
Re: (Score:2)
Your "contrary example" actually proves my point.
Once you have the pattern, you no longer need a key of your own - you just go and get one manufactured.
You contradict yourself. If you didn't need a key why would you go get one made? Furthermore, what ceases to be obscured through the process of taking your knowledge of the key's teeth and having a replica made? (Hint: nothing)
Re: (Score:2)
Re:Hrrm (Score:4, Interesting)
"The fact is private encryption keys only work when P and Q are not known. You can also decrypt the cyphertext without the key - just search for $5 wrench"
You're mistaking "secret", which is necessary part of every encryption scheme, with "obscurity", which is useful only in very specific circumstances.
Following your analogy, security by obscurity is making key duplication method secret and hiding the lock's inner working. Good security, on the other hand, is when you can't duplicate the key unless you snatch it from the owner and can't pick the lock even if you know how it's built.
Security by obscurity is useful only as preliminary defense line to stall an attacker until he gathers enough information about your systems to begin targeted attack.
Re: (Score:2)
Re: (Score:2)
There's also no such thing as 100% bug-free.
What kind of attitude is that? /bin/true on Solaris looks bug free to me.
Re: (Score:3)
Have you vetted crt1.o for correctness?
Re: (Score:2)
Have you vetted crt1.o for correctness?
Fine.
mov eax, 60
xor ebx, ebx
int 0x80
Turtles all the way down (Score:4, Insightful)
Re: (Score:3)
Here are the missing steps:
Have you vetted the universe for correctness?
Have you vetted your brain for correctness?
Yup (Score:3)
I have a certificate signed by the PRC themselves, though I am struggling a bit with the Mandarin.
Re: (Score:2)
Your program didn't do what it was asked to. Why didn't it return an error code?
Re: (Score:2)
and if you compile it with a buggy compiler?
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
I could see a few ways to do it..
- Linux games are becoming more popular
- A poorly coded script on a webserver that lets you upload and execute a file
Re: (Score:2)
Re: (Score:2)
so i gather we just forget about any access control and everybody is root?
Re: (Score:3)
No. "Multiuser system" indicates users are secure from one another. Linux is not ms-dos. I'm sure vmware would like you to believe otherwise.
Network services use multiuser system access controls to good effect. Bind, ntp, etc., will chroot themselves into a nearly empty dir, and then drop privledges. This means an exploit in, say, bind results in attackers only getting a non-privledged account access on the targe
Don't worry (Score:2)
Re: (Score:2)
In fact you can even fix it yourself while waiting for a patch with systemtap: http://www.outflux.net/blog/archives/2012/01/22/fixing-vulnerabilities-with-systemtap/ [outflux.net]
We all call for it! UAC for Linux! (Score:1)
Start programming, Linus!
Re: (Score:2)
Link to more info (Score:5, Informative)
http://blog.zx2c4.com/749
Gets into the memory specifics of the bug. I found it to be far better than the actual article.
Re: (Score:2)
Thank you! I was browsing through Linus's patch and couldn't make heads or tails of it.
That and I couldn't help noticing that he got rid of a bunch of goto statements while he was at it. At least these gotos were actually used for error handling...
Debian (mostly) not affected (Score:5, Informative)
Since this bug was introduced in Linux 2.6.39 Debian Stable (squeeze, Linux 2.6.32) is not affected. Unstable(sid, Linux 3.1) has already been patched, though Testing (wheezy) is still vulnerable.
More information here [debian.org]
Re: (Score:2)
I've been looking around but haven't found any information on when the fix might migrate into Testing. Any idea?
Simple explanation (Score:5, Informative)
There is /proc/pid/mem, a pseudofile referring to the memory of process pid. It has 0600 permissions so you can't write to the memory of other users' processes. The bug occurs when you exec an suid executable and the kernel does not change open fds for /proc/pid/mem. This way, you can open mem, dup it to stderr, and exec su with a garbage parameter. su will duly print an error, quoting the offending parameter, writing to its process memory. With a properly selected shellcode you can get root.
Holy (Score:2)
What'd "//" be ? (Score:5, Informative)
is the very wrong quotation!
The original source [techworld.com.au] quotes instead:
which is the memory as seen by a certain process whose PID is <pid>.
Moreover, there's no "/proc/mem" file and the "//" whould be interpreted as "/".
But maybe that'd be just the Slashdot editor.
Re: (Score:2)
Why have the node be writeable by anyone but root? (Score:2)
What programs depend on it to be writeable? Just make the file read-only for the PID owner.
Re:Local exploit? (Score:5, Informative)
Re: (Score:2)
Re: (Score:1)
b) Changing run-level requires privileged access, that's why not.
All of the machines I manage are O.K: we haven't installed anything newer than 2.6.38 yet anyway.
Reboot into single-user mode (Score:2)
Re: (Score:2)
I think present_arms's point is that local console access involves access to the big red switch
'Local access' typically means that you have means to start processes as non-root, but does not require that you are near the physical hardware. Physical access means you are near enough to access the 'big red switch'. Privilege escalation vulnerabilities typically allow you to get from 'local access' to 'local privileged access'. Combined with a remote vulnerability (which allows you to get from 'can't start and control processes' to 'can start and control processes') you can craft a remote root exploit.
and the bootloader, which on a PC-type system can be used to gain root by booting into single-user mode [debuntu.org].
As
Re: (Score:2)
so someone has to be sitting in front of the boxen to exploit the exploit, why not just init 1? Serious question :)
"local" in this context usually means having a shell on the target machine - or similar way to upload and execute what you wish( and escalating privileges means that you escalate from "normal user who can't do shit" to something else, in this case root).
Re: (Score:2)
Re:Local exploit? (Score:5, Funny)
so someone has to be sitting in front of the boxen to exploit the exploit, why not just init 1?
Or they could use axen to destroy the boxen. Or set some foxen on them to tear them to pieces. Or they could fill the boxen with melted waxen. Or bury them in faxen. This exploit is usable by people of both sexen, so long as they pay their taxen.
VAXen (Score:2)
Re: (Score:2)
>And I throw up a little in my mouth whenever somebody says or writes "boxen."
Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen! Boxen!
Here's a mopxen!
--
BMO - Atinlay igpay oxenbey!
Re: (Score:2)
Re:iOS now has more marketshare than Android (Score:5, Funny)
Pardon me, but I'm going to go watch Firefly now, as it appears none of you make any sense. Bye.
Re: (Score:2)
Pardon me, but I'm going to go watch Firefly now, as it appears none of you make any sense. Bye.
But.. but... how can you watch Firefly when Nielsen and NPD confirm that people buy cellphones? :O
This NPD? [urbandictionary.com] "NPD is a large polling company that that helps other companies report information about public. occationally they mess up really bad"
Wow. There is one hole hell of a lot of "FAIL" in there.
I need a new wristwatch... one with a stockmarket ticker... so I know with which mp3 player i"ll father my next child..
I believe you just proved my original point.
I think I'll go look for willing clitorises to pleasure now, toodles. [I believe the world would be a much better place were my tounge pleasuring more clitorises (but that's just my opinion).]
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
You're not suggesting those other countries actually matter, are you? What century are you living in? :-)
Not the century one that forgets where the majority of the world's population or where the strongest currency is.
China? Really? The country with the most worthless people (per capita)? Doin' the math, ... One country / 7 billion people ...
Do any individual Chinese citizens amount to anything worth your consideration, or do you just throw them into the meat grinder as usual AS CHINA HAS FOR THE PAST FOUR THOUSAND YEARS? To the PRC, I'm wondering. Sorry, venting, I may have issues.
BTW, I do have Chinese friends. Some of them are fairly special to me.
Damn, I'm looking forward to seeing you asshats in the crosshair
Re: (Score:2)
Re: (Score:2)
Your assumptions amuse me, mistakening me for Chinese.
Yeah, I've got to admit, that looked pretty strange to me too this morning. I'll go find a wall to bang my head on now.
Re: (Score:2)
Re: (Score:3)
Look everyone, yet another OS war on linux exploit news, how original!
Re:Better than Windoze (Score:5, Insightful)
You seem to be in a situation where PEBKAC - it's corrupting the text of your post. Of course what you meant to say is that the Open Source model does not guarantee security but simply allows interested parties to audit for and fix security problems independent of any single company or other rights holding restricting access to the source. Generally we find that the Open Source model has worked well for Linux and has been effective at addressing security concerns. The question is sometimes not whether problems exist, but whether or not they are found and corrected.
Speaking of security on Windows - if that post of yours isn't a case where PEBKAC, you might want to install some anti virus software - looks like someone might have pwnd your machine.
Re: (Score:2)
Re: (Score:3)