Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4)
Posted Jan 23, 2012 20:48 UTC (Mon) by PaXTeam (subscriber, #24616)
nice try, but i never said this, a.k.a. 'citation needed'. what was covered up is the security impact of the bug, you can't read about it neither from Linus nor other participants, even when directly asked about it as Kees tried on oss-sec. fortunately now the cat is out of the bag, showing once again how futile such silly efforts of covering up security bugs are.
Posted Jan 23, 2012 23:23 UTC (Mon) by flewellyn (subscriber, #5047)
Eugene Teo says "This is a possible local privilege escalation issue on a system with ASLR disabled, combined with other exploitation techniques."
In other words, the security impact of the bug. Right there.
Posted Jan 23, 2012 23:50 UTC (Mon) by PaXTeam (subscriber, #24616)
not only did i check, but i was the reason for Kees having asked Euegene to begin with as his first message was anything but clear about what the heck was going on. you see, you didn't cite that one yourself either, you're welcome to explain why (rhetorical question ;).
> Eugene Teo says "This is a possible local privilege escalation issue on
> a system with ASLR disabled, combined with other exploitation techniques."
> [...]In other words, the security impact of the bug. Right there.
let me quote back someone you might be familiar with: is this "the part where I'm supposed to take on faith that it's true."? such an irony :). so let's see, if i say something, you will question it without thinking but when you read that above, you took it as gospel. something doesn't compute here dude.
and before you come back with 'but these people have proved themselves already and have such a reputation, blablabla', i'll let you figure out the errors (was more like wishful thinking probably) in the very statement above. you don't even have to work hard, the proof has been presented "in this very thread" (another irony ;).
Posted Jan 24, 2012 2:07 UTC (Tue) by flewellyn (subscriber, #5047)
What I am doubting, and challenging, is your assertion that this represents malicious "coverup" by the Linux kernel developers, because they did not mention the full security impact of the bug. They may well not have been aware of its true scope.
Why do you continue to allege malice on the part of the kernel developers, when it's perfectly reasonable to assume that they just don't have the same kind of security expertise that you do?
Posted Jan 24, 2012 5:46 UTC (Tue) by drag (subscriber, #31333)
"This patch tries to fix a local permission escalation exploit"
Being honest and forthright is not something that is complicated here.
Even though they were wrong about ALSR being useful in this case and said it was in the email it's still better to admit that it's a attempt to close a exploitable hole in Linux right off the bat.
It's much better to be honest and accidentally injecting misinformation then it is to use technical jargon to make it sound better then it is while also injecting misinformation accidentally.
Which helps illustrate PaXTeam's point which is, fundamnetally:
You can not trust the Linux developer's statements if you are trying to determine whether or not a patch fixes some trivial undesirable behavior versus if they are fixing a exploitable hole.
If it was not for the people questioning them on the mailing lists or the blog post or this lwn article it would not be possible for even a fairly technical person to know that this patch attempts to solve a exploitable flaw in the kernel. It appears to be the same as any other kernel commit.
Posted Jan 24, 2012 10:05 UTC (Tue) by dgm (subscriber, #49227)
Posted Jan 24, 2012 10:18 UTC (Tue) by ledow (guest, #11753)
I'm *really* getting tired of conspiracy-theory-bob every time anything security related comes up, where they just assume everyone should be perfect like them, care about exactly the same things they do, that everyone should go to the news stations with "THIS PATCH COULD MAKE YOUR COMPUTER MELT AND HACKERS DESTROY YOUR LOCAL NUCLEAR POWER STATION" every time there's the slightest hint of an off-by-one in a patch (even if the full impact of things patched can take YEARS to realise), and that they are right and everyone else is wrong.
I don't *CARE* if they are right any more, it's got to the point where the personality and the very sight of their username makes me not want to read the whole thread.
PaXTeam - How many followers do you think you get by doing this every other article, compared to how many you turn off with your obnoxious, over-bearing attitude and inability to drop the long-term bias and discuss only the matter at hand? You are a perfect example of how to disguise a perfectly good message behind a social screen, to the point where nobody cares any more.
WE GET IT. We just don't care. Don't change the message, change the delivery.
Posted Jan 24, 2012 11:40 UTC (Tue) by patrick_g (subscriber, #44470)
Posted Jan 24, 2012 13:15 UTC (Tue) by spaetz (subscriber, #32870)
Yes, filter user or somesuch in your account section.
It makes life much better :-)
Posted Jan 24, 2012 17:50 UTC (Tue) by epa (subscriber, #39769)
Posted Jan 26, 2012 19:34 UTC (Thu) by vonbrand (subscriber, #4458)
My beef with this whole "Linux security sucks" brouhaha is that it is obviously very easy in hindsight (given that a bug has a exploit posted, and has been dissected to death) to go back and see that very many people didn't talk about it before. And from there, blissfully disregarding Hanlon's razor it is a short step to world-wide conspiracy theories.
Sorry, not each and every fix will ever get this level of scrutiny, probably just a minor fraction of those with real security impact will. Get over it.
Posted Jan 26, 2012 22:24 UTC (Thu) by PaXTeam (subscriber, #24616)
Posted Jan 26, 2012 22:46 UTC (Thu) by raven667 (subscriber, #5198)
Posted Jan 24, 2012 10:46 UTC (Tue) by PaXTeam (subscriber, #24616)
'discussion' is a bit of an overstatement. what happens is that i ask questions and get no answers. i bet you'll fail there too ;)
> Why make the life of script kiddies any easier?
why does disclosing the security impact of a bug help script kiddies? do you know who they are, what they are capable of, etc? if you did, you wouldn't have asked the question above.
> Just to keep some egos satisfied is not a good reason.
whose egos are satisfied by disclosing the security impact of a bug? what does it matter regarding the security of all users of said piece of code anyway?
> Do you hear any uproar coming from kernel users because those commit messages are ambiguous? No, you don't.
i do. now what?
> What we hear is security people claiming they do not get recognition.
Posted Jan 24, 2012 16:36 UTC (Tue) by drag (subscriber, #31333)
It doesn't make life any easier because by definition script kiddies can't program. This viewpoint is foolish in the extreme.
The people that write the programs that script kiddies end up using are going to be much more professional and are not going to be thwarted by ambiguous commit messages.
Personally I don't give a shit as long as my distribution gets a patch out to fix bugs in a timely manner. That makes me happy.
But you can argue until you are blue in the face and PaXTeam will still be correct:
You cannot trust the Linux kernel developers to disclose security problems.
Posted Jan 25, 2012 21:45 UTC (Wed) by boog (subscriber, #30882)
Posted Jan 24, 2012 9:18 UTC (Tue) by PaXTeam (subscriber, #24616)
Posted Jan 24, 2012 4:24 UTC (Tue) by eteo (guest, #36711)
Posted Jan 24, 2012 12:59 UTC (Tue) by PaXTeam (subscriber, #24616)
1. as i mentioned it here already, why do the mem_* accessors use force=true when accessing the address space? was that a design decision?
2. why's mem_read not mentioned at all? it has the same buggy logic, it's just waiting for a suitable suid to disclose sensitive information...
3. Linus' fix turned this bug into a kind of local DoS (default ulimits on most systems allow one to eat up memory) where the culprit cannot be easily identified (since the zombie mm's memory consumption is not accounted to the process holding the refcount/fd). is a new CVE in order? ;)
Posted Jan 24, 2012 13:31 UTC (Tue) by PaXTeam (subscriber, #24616)
4. i don't know if gdb and similar use /proc/pid/mem but if they do, they'll be broken when they want to trace across an execve without reopening /proc/pid/mem as it is required now. but since Linus has yet to revert/properly fix the heap-stack gap commit as well, i think this one's going to stay too.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds