Weekly Edition
Return to the Security page
| |||||||||||||
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4)
The "zx2c4" weblog has a detailed
writeup of a local root vulnerability in /proc introduced in
2.6.39 and just fixed on January 17. "In 2.6.39, the
protections against unauthorized access to /proc/pid/mem were deemed
sufficient, and so the prior #ifdef that prevented write support for
writing to arbitrary process memory was removed. Anyone with the correct
permissions could write to process memory. It turns out, of course, that
the permissions checking was done poorly. This means that all Linux kernels
>=2.6.39 are vulnerable, up until the fix commit for it a couple days
ago. Let’s take the old kernel code step by step and learn what’s the
matter with it." As of this writing, distributors do not yet appear
to have begun shipping updates for this vulnerability.
(Log in to post comments)
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 23, 2012 15:04 UTC (Mon) by brunowolff (guest, #71160) [Link]
This looked a bit familiar so I checked and Fedora had fixed builds for this on January 18th. So rawhide would have the build on the 19th. Looking at bodhi, I see the updates for F16 and F15 were not pushed even to updates-testing. I expect that was an oops.
Fedora Posted Jan 23, 2012 15:10 UTC (Mon) by corbet (editor, #1) [Link] As it happens, Fedora's su is dynamically linked, so it's probably not vulnerable to this particular exploit anyway (though the kernel vulnerability remains and may be exploitable via some other path).
Fedora Posted Jan 23, 2012 15:49 UTC (Mon) by PaXTeam (subscriber, #24616) [Link]
the exploit can take the target address as argument, it's a trivial one-liner to brute force it...
Works in Fedora Posted Jan 23, 2012 18:38 UTC (Mon) by zx2c4 (subscriber, #82519) [Link] This version works with Fedora 16:http://git.zx2c4.com/CVE-2012-0056/tree/mempodipper.c?h=fedora
Works in Fedora Posted Jan 24, 2012 4:10 UTC (Tue) by eteo (guest, #36711) [Link]
Here's the updated kernel for Fedora 16, https://admin.fedoraproject.org/updates/kernel-3.2.1-3.fc16.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 23, 2012 15:33 UTC (Mon) by SEJeff (subscriber, #51588) [Link]
Did Fedora's SELinux default config block this?
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 23, 2012 16:22 UTC (Mon) by dpquigl (subscriber, #52852) [Link]
It blocked it on my box.
uname -a
[dpquigl@<name redacted> Downloads]$ ./mempodipper
[+] Opening socketpair.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 23, 2012 16:25 UTC (Mon) by dpquigl (subscriber, #52852) [Link]
This is as the default unconfined user on Fedora. I doubt the more confined user_u or staff_u users would allow more than the unconfined user. Unfortunately I can't set up a user_u or staff_u user at the moment so I can try again later with those users.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 23, 2012 16:26 UTC (Mon) by SEJeff (subscriber, #51588) [Link]
Any chance you could show the specific avc denial from /var/log/audit/avc.log or whatever it is? Thats very interesting and another great example for SELinux. I do wonder if AppArmor in Ubuntu blocks this, but somehow doubt it.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 23, 2012 17:46 UTC (Mon) by dpquigl (subscriber, #52852) [Link]
Not seeing any AVC denials for this.
Ran
Then did
ausearch -ts recent
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 23, 2012 17:52 UTC (Mon) by SEJeff (subscriber, #51588) [Link]
So SELinux isn't blocking it, must be the build chain denying this invocation of the exploid. I noticed that RHEL6 is vulnerable so it might just be a bit harder but still possible.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 24, 2012 17:09 UTC (Tue) by lkundrak (subscriber, #43452) [Link] Really! <= 2.6.39 was reported to be vulnerable and RHEL 6 runs patched 2.6.32. Thus I only checked changelog for the stock 6.1 kernel that I was running and thought it was safe, but apparently this broke with 6.2 kernel (I run Scientific Linux 6.1 and I got that new kernel in an update): * Mon Oct 10 2011 Aristeu Rozanski <arozansk@redhat.com> [2.6.32-207.el6] - [fs] proc: enable writing to /proc/pid/mem (Johannes Weiner) [692039]
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 23, 2012 16:33 UTC (Mon) by dpquigl (subscriber, #52852) [Link]
Just to be compete I tried the exploit with SELinux in permissive mode and it didn't work either. I'd imagine something in my kernel either had the permission check fixed or was too restrictive to allow it to work.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 23, 2012 16:43 UTC (Mon) by cesarb (subscriber, #6266) [Link]
Is su on Fedora compiled with PIE?
I would guess it is, since 0x1524 would be a strange place for the code (too low). Check the example in the blog post, there it is at 0x402178.
With PIE and ASLR, the address changes every time, making this kind of exploit much harder.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 23, 2012 16:50 UTC (Mon) by cesarb (subscriber, #6266) [Link]
And it is also possible that Fedora uses -z relro -z now, which makes the place the exploit attempts to overwrite read-only (again making writing a working exploit even harder). See http://people.redhat.com/drepper/nonselsec.pdf for details.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 23, 2012 17:20 UTC (Mon) by PaXTeam (subscriber, #24616) [Link]
i understand you're excited but please stick to the facts... ASLR won't make exploitation 'much harder' given the few bits one has to brutefoce, call it a blink of an eye. if you have something like grsecurity's brute force detection and prevention feature then you can at least bound the probability of success (but still not make it 0, and also let's not forget about potential memory leaks one could make use of to avoid brute forcing in the first place although for this particular vulnerability it's very hard to imagine a situation where such leaks could be used by the exploit given how the lseek has to happen before the suid address space even exists).
second, mem_write makes use of the same accessor underneath as ptrace and can therefore write to memory mapped as read-only (whether that capability was intended or not is another question and perhaps a bug itself yet to be fixed). so RELRO/etc won't do anything to prevent this vulnerability from getting exploited. case in point, this exploit modifies the .plt section itself that is mapped as read-only already. i will note again that under grsecurity the technique used in this exploit won't work because PaX prevents said accessor from modifying executable (and hence read-only) mappings, one would need a ret2libc style exploit and most likely brute force (which is then limited by the previously mentioned feature).
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 24, 2012 10:12 UTC (Tue) by atomik (guest, #69705) [Link]
So what about some features of pax/grsecurity in the mainline kernel if it can prevent some security issue ?
The same story as with Android Posted Jan 24, 2012 10:38 UTC (Tue) by khim (subscriber, #9252) [Link] Security people hit the same wall Android developers did: tradeoffs "obvious" to them are not all that obvious to mainline kernel developers. Since absolute security is impossible and we already have one kernel 100% focused to security (OpenBSD) it means mainline kernel developers should be convinced in merits of each and every change separately. But this will improve security by itself is not enough if it'll complicate other things, affect speed or reliability, etc.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 23, 2012 18:39 UTC (Mon) by zx2c4 (subscriber, #82519) [Link] Use the right version for Fedora:http://git.zx2c4.com/CVE-2012-0056/tree/mempodipper.c?h=fedora
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 23, 2012 18:56 UTC (Mon) by dpquigl (subscriber, #52852) [Link]
I'm not sure why but the SELinux policy has this rule in it that allows the exploit to work.
allow groupadd_t groupadd_t : file { ioctl read write getattr lock append open } ;
The file /proc/<pid>/mem is labeled with the label of the process. The new version that uses groupadd instead of su that was just posted works because of this rule. If there wasn't a file write permission for groupadd_t to groupadd_t then it wouldn't be able to write to the proc node necessary for the exploit. I'd like to know why it needs write permission to those files or if it was an oversight of making things not fine grained enough.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 23, 2012 16:08 UTC (Mon) by PaXTeam (subscriber, #24616) [Link]
and now let the usual flamefest^Wdiscussion start all over again: why does one have to learn about such a critical bug from an unrelated 3rd party's blog? great coverup attempt and associated screw up guys, as usual.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 23, 2012 18:57 UTC (Mon) by clump (subscriber, #27801) [Link]
I'm very thankful there are people that will go through the trouble to examine and report security issues. I'm specifically thinking of people like you.
One possibility about why there's not a more in-depth security disclosure policy is that nobody so skilled has come forward to assume a leadership role. If I had the requisite knowledge and dedication, I might volunteer myself.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 23, 2012 19:52 UTC (Mon) by PaXTeam (subscriber, #24616) [Link]
i think you're misunderstanding me, i didn't find nor report this bug (if i had, things would have happened very differently ;). what i did 'find' (as if it wasn't blatantly obvious) was the commit that fixed the problem, but without making clear what it was really fixing ('not very robust' and 'you cannot actually usefully access the fd across a VM change' seriously?).
as for disclosure policy and whatnot, this particular bug was reported in private as a security bug, there was no question about its impact whatsoever, yet the usual coverup ensued. i'm looking forward to see what this week's LWN Weekly Edition has to say about this whole situation ;).
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 23, 2012 20:18 UTC (Mon) by flewellyn (subscriber, #5047) [Link]
>as for disclosure policy and whatnot, this particular bug was reported in private as a security bug, there was no question about its impact whatsoever, yet the usual coverup ensued.
Can you provide a citation for this? A link to the discussion where it was noted this was a security bug? Transcripts?
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 23, 2012 20:30 UTC (Mon) by PaXTeam (subscriber, #24616) [Link]
which part of 'in private' wasn't clear? ;) for the public discussion: http://seclists.org/oss-sec/2012/q1/178 .
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 23, 2012 20:33 UTC (Mon) by flewellyn (subscriber, #5047) [Link]
> which part of 'in private' wasn't clear? ;)
The part where I'm supposed to take on faith that it's true.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 23, 2012 20:44 UTC (Mon) by PaXTeam (subscriber, #24616) [Link]
who said you were supposed to take anything on faith? citation needed! and you're also welcome to do your own research of the subject matter ;).
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 23, 2012 20:35 UTC (Mon) by flewellyn (subscriber, #5047) [Link]
And while we're at it, calling the public discussion a "coverup", when the subject line requests a CVE, is just plain dishonest.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 23, 2012 20:48 UTC (Mon) by PaXTeam (subscriber, #24616) [Link]
> calling the public discussion a "coverup"
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.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 23, 2012 23:23 UTC (Mon) by flewellyn (subscriber, #5047) [Link]
Did you not check further down in that very thread? This message: http://seclists.org/oss-sec/2012/q1/194
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.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 23, 2012 23:50 UTC (Mon) by PaXTeam (subscriber, #24616) [Link]
> Did you not check further down in that very thread?
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
> [...]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 ;).
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 24, 2012 2:07 UTC (Tue) by flewellyn (subscriber, #5047) [Link]
I'm aware that the bug is more serious than Teo thought, and that ASLR does not protect. I saw what you posted about it. I have no reason to doubt your expertise as a security researcher.
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?
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 24, 2012 5:46 UTC (Tue) by drag (subscriber, #31333) [Link]
All they had to do was state something like:
"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.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 24, 2012 10:05 UTC (Tue) by dgm (subscriber, #49227) [Link]
This has been discussed to death. Why make the life of script kiddies any easier? Just to keep some egos satisfied is not a good reason. Do you hear any uproar coming from kernel users because those commit messages are ambiguous? No, you don't. What we hear is security people claiming they do not get recognition. Please.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 24, 2012 10:18 UTC (Tue) by ledow (guest, #11753) [Link]
Is there a way to block comments from a certain user on this forum?
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.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 24, 2012 11:40 UTC (Tue) by patrick_g (subscriber, #44470) [Link]
You can enable comment filtering in your "My account" page (it's only available for the "professional hackers" subscription level).
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 24, 2012 13:15 UTC (Tue) by spaetz (subscriber, #32870) [Link]
> Is there a way to block comments from a certain user on this forum?
Yes, filter user or somesuch in your account section.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 24, 2012 17:50 UTC (Tue) by epa (subscriber, #39769) [Link]
I find PaXTeam's comments useful because they give an "outsider" perspective on kernel security. They are by someone who knows what he or she is talking about but who isn't part of the inner circle of kernel developers. That helps to avoid smug groupthink and to point out deficiencies in the development process - though it's a shame that a flamewar erupts every time PaXTeam or someone else points out that the kernel changelog messages are a bit obfuscatory.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 26, 2012 19:34 UTC (Thu) by vonbrand (subscriber, #4458) [Link] 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.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 26, 2012 22:24 UTC (Thu) by PaXTeam (subscriber, #24616) [Link]
sometimes it's worth reading the whole story before you comment. this particular bug was reported in private to the kernel security list as a security bug with a working exploit, there was no question whatsoever about its seriousness. despite that, we know what Linus chose to tell the world about it. and we also know how well that worked out for him ;).
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 26, 2012 22:46 UTC (Thu) by raven667 (subscriber, #5198) [Link]
I think a lot of people just don't want to believe that Linus wouldn't be forthright about security so they rationalize that by assuming there must have been an error somewhere, that Linus didn't really know or whatever. That's why we keep getting the same debunked explanations for the observed behavior rather than being able to move on with a discussion of the merits of what actually is happening.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 24, 2012 10:46 UTC (Tue) by PaXTeam (subscriber, #24616) [Link]
> This has been discussed to death
'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.
'citation needed'.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 24, 2012 16:36 UTC (Tue) by drag (subscriber, #31333) [Link]
> Why make the life of script kiddies any easier?
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.
Period.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 25, 2012 21:45 UTC (Wed) by boog (subscriber, #30882) [Link]
People seem to have overlooked how beneficial it is to have security researchers who are motivated and hungry. We can't pay the same as the bad guys, but I'm sure an annoying lack of respect is stimulating in its own way. I could almost believe that Linus is doing it deliberately. In any case, every exploit found is one fewer in the kernel - keep up the good work.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 24, 2012 9:18 UTC (Tue) by PaXTeam (subscriber, #24616) [Link]
for all the doubting Thomases this just in:
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 24, 2012 4:24 UTC (Tue) by eteo (guest, #36711) [Link]
Obviously this is work-in-progress. Don't expect that I know everything. If you have something to contribute, do so. Thanks.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 24, 2012 12:59 UTC (Tue) by PaXTeam (subscriber, #24616) [Link]
a few things come to mind:
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? ;)
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 24, 2012 13:31 UTC (Tue) by PaXTeam (subscriber, #24616) [Link]
one more thing:
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.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 23, 2012 20:32 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
this is exactly the disconnect.
you assume that the person fixing the bug understood the security implications of it, from the comments (and from dealing with many developers over many years), I believe that they usually don't understand the security implications of bugs that they deal with.
This is a perfect example of why many people think that explicitly calling out security bugs doesn't help. There are many bugs like this that are not known to be security bugs until long after they are fixed, so they would not be called out and people who only apply 'important' fixes would miss it.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 23, 2012 20:59 UTC (Mon) by PaXTeam (subscriber, #24616) [Link]
> you assume that the person fixing the bug understood the security implications of it,[...]
i don't assume, i know. Linus knew full well the security impact of the bug. go ask him if you don't believe me ;).
> This is a perfect example of why many people think that explicitly calling out security bugs doesn't help.
no, this is a perfect example of why many people think that explicitly calling out security bugs does help.
> There are many bugs like this that are not known to be security bugs until long after they are fixed[...]
this whole premise is false, this bug was very well known to be a security bug.
> [...]so they would not be called out and people who only apply 'important' fixes would miss it.
did you just say (not the first time, if memory serves, mind you ;) that by not telling people to apply known security fixes their security will somehow be better? ;)
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 24, 2012 5:00 UTC (Tue) by raven667 (subscriber, #5198) [Link] > [...]so they would not be called out and people who only apply 'important' fixes would miss it.did you just say (not the first time, if memory serves, mind you ;) that by not telling people to apply known security fixes their security will somehow be better? ;) There is no need to address your other points, you have done a fine job on your own but on this point I can only believe you are pretending to not understand what was meant because you are attacking a straw man. The point that this statement refers to is that, hypothetically, if you have 8 bug fixes, 2 of which have known security implications and 4 of which have security implications that are unknown then telling people to only apply the two bugfixes leaves them more vulnerable then telling them to apply all 8. 6 is more than 2. We can have opinions on whether this approach makes sense, not announcing the 2 bugs you know about and just pushing for all 8 so as to get the 4 you don't know about, but we can't pretend not to understand what the two positions are that we are discussing.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 24, 2012 11:01 UTC (Tue) by PaXTeam (subscriber, #24616) [Link]
i know full well what dlang's talking about and i've explained numerous times where he's right and where he's wrong. to go with your example, here's another situation:
imagine, hypothetically, if you have 8 bug fixes, 2 of which have known security implications (they fix them) and 4 of which have security implications (they introduce them) that are unknown then telling people to only apply the two bugfixes leaves them less vulnerable then telling them to apply all 8. -2 is less than 2.
so what did you try to say again? that we can fabricate arbitrary situations with arbitrary numbers that only prove that the world's not black&white but a shades of grey?
let me tell you (again) where your thinking is wrong: you're saying that people are *not* getting more secure by applying (known) security fixes *because* they could get (even) *more* secure by applying 'all fixes' (whose definition is yet to be determined btw). i hope you'll see one day how ridiculous this is, you *cannot* be worse off by fixing a known security bug. lest you now want to claim that *anyone* who didn't update to 3.3-rc1 (which no doubt contains more fixes than this security bug) is in error.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 24, 2012 11:37 UTC (Tue) by tialaramex (subscriber, #21167) [Link]
"you *cannot* be worse off by fixing a known security bug"
Trivially false by your own logic. You can supposedly fix the known security bug and introduce a far worse one. This happens. You can also _think_ you've fixed the bug when you haven't, creating a false sense of security.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 24, 2012 11:45 UTC (Tue) by PaXTeam (subscriber, #24616) [Link]
when we said 'fix bug' above we obviously meant 'fix bug for real and without introducing another one'. pay attention to the context next time, please ;).
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 24, 2012 14:18 UTC (Tue) by tialaramex (subscriber, #21167) [Link]
I look forward to seeing these new type of patches which always fix the entire problem however subtle and never introduce (or indeed re-introduce) other bugs. Until then, I hope you will agree that your hypothetical is bit too... hypothetical ?
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 24, 2012 15:11 UTC (Tue) by PaXTeam (subscriber, #24616) [Link]
you know, i'm beginning to really appreciate khim's post the other day where he mentioned the twitterbrain generation. are you seriously this challenged or just trolling around? do you understand that it wasn't *my* hypothetical situation that assumed perfect fixes but raven667's (as only that way can he/she arrive at his/her numbers). do you understand that i *intentionally* annotated my hypothetical situation with bracketed expressions exactly because i wanted to highlight that other real life situations may very well end up producing opposite numbers? IOW, your argument is not with me but i guess your brittle ego is still suffering from past losses and you thought it'd be a good time to take revenge. maybe next time? :)
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 25, 2012 11:48 UTC (Wed) by ekj (guest, #1524) [Link]
Yeah okay. If you apply a patch that "fixes the bug for real, and does not introduce any new bugs", then you cannot be worse off than you where initially, agreed.
How do you know if the patch you have in front of you is one of those ideal patches ?
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 25, 2012 13:24 UTC (Wed) by PaXTeam (subscriber, #24616) [Link]
> How do you know if the patch you have in front of you is one of those ideal patches ?
did you mean a general you or me personally? as for myself, if (i believe that) i know enough to determine this i will do so (e.g., i voiced my concerns regarding this particular case already), otherwise i do as anyone else would have to do: trust someone else. for kernel code i'm familiar with or for simple fixes (say, bounds checking a parameter) it's usually the former case, otherwise it's the latter. from my experience most attempts at fixing a problem turn out to be correct, very few introduce further problems or fix them inadequately (e.g., you can compare the number of CVEs fixing previous CVEs to the total number of CVEs to get an idea).
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 24, 2012 19:25 UTC (Tue) by raven667 (subscriber, #5198) [Link] you're saying that people are *not* getting more secure by applying (known) security fixes That's NOT what I'm saying at all and I don't think that's what the OP is saying either they could get (even) *more* secure by applying 'all fixes' That is what I understood the OP to mean and to be the position of the Linux dev team. All I'm trying to do here is get you to at least acknowledge you understand what your opponent is saying. so what did you try to say again? that we can fabricate arbitrary situations with arbitrary numbers that only prove that the world's not black&white but a shades of grey? WTF. My example was included merely to illustrate what was being said, not to take any position on the rightness or wrongness of it. You are way off the mark trying to criticize my example instead of the point it was trying to illustrate. you now want to claim that *anyone* who didn't update to 3.3-rc1 (which no doubt contains more fixes than this security bug) is in error I do get the impression that a lot of kernel developers wish that everyone would just run the current version and wouldn't muck around with "stable" versions and backported fixes although there is obviously enough interest to make a few stable versions.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 24, 2012 9:10 UTC (Tue) by farnz (guest, #17727) [Link] He's right to say that applying all known bugfixes, not just those flagged as "security fixes" is likely to lead to more secure software for two very good reasons:
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 24, 2012 9:34 UTC (Tue) by PaXTeam (subscriber, #24616) [Link]
> He's right to say that applying all known bugfixes, not just those
> flagged as "security fixes" is likely to lead to more secure software [...]
it's a strawman, obviously the more bugs you fix, the better your system is (security-wise or not), noone said otherwise. what i did say and dlang (or now you) has yet to disprove is that applying *any* security fix (regardless of other possible fixes) *does not* decrease one's security, quite the opposite in fact (witness this very bug here). the consequence of which is then that it is a good idea to let people know about them.
btw, what's 'known bugfixes' mean? can you give me a list of 'known bugfixes' that went into, say, 3.3-rc1 so that i can have a 'more secure' 3.2? i bet you cannot. i bet noone can.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 24, 2012 11:10 UTC (Tue) by jrn (subscriber, #64214) [Link]
> can you give me a list of 'known bugfixes' that went into, say, 3.3-rc1 so that i can have a 'more secure' 3.2?
git rev-list --grep=stable@ v3.2..v3.3-rc1
Alas, people often forget to cc stable@.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 24, 2012 11:17 UTC (Tue) by PaXTeam (subscriber, #24616) [Link]
so it's a partial list and we've just been told here that applying a partial list of fixes was bad, so try again ;).
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 24, 2012 19:14 UTC (Tue) by jrn (subscriber, #64214) [Link]
> try again ;).
Why? How would that kind of conversation be useful in the least?
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 24, 2012 11:27 UTC (Tue) by farnz (guest, #17727) [Link] Actually, it's quite easy to produce a full list of bugfixes in 3.3-rc1 - look through the changelog between 3.2 and 3.3, and remove any patches that add new features. It's boring grunt work, but it's doable - and if you really care about this, you're paying someone to do that grunt work anyway. If you're prepared to front $1,000,000, I'll do it for you - but I'm sure you can find someone cheaper. And yes, just adding "security fixes" blindly, without the context around them can decrease overall security. Story from a workplace, someone applied a fix to a proprietary system that stopped it storing passwords in plain text (it stored hashes instead), which as a side effect changed the HTTP server from using Digest authentication to using Basic authentication. The vendor didn't realise this was unsafe - if you'd been applying the feature fixes as well, you'd have acquired a HTTPS server about 3 years before the security patch was released, and lost the HTTP server about 6 months before the security patch was released. We hadn't been keeping up to date with the feature patches, only the security patches; the vendor had simply not considered the impact if you weren't running the feature patches, and had assumed that you would be using HTTPS, and thus no-one could sniff the HTTP datastream without prior access to the server. Now, you can argue that this is an oversight by the vendor, and the move to HTTPS should have been a security patch as well - but now you're saying that the vendor must not make mistakes, and if they were capable of that, they wouldn't need to issue fixes in the first place.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 24, 2012 12:13 UTC (Tue) by PaXTeam (subscriber, #24616) [Link]
> Actually, it's quite easy to produce a full list of bugfixes in 3.3-rc1 [...]
so just as i thought, you can't produce it, you might as well have just stated it ;).
> [...]remove any patches that add new features.
how do you know that all commits not adding new features fix bugs? which actually depends on this: what is the definition of a new feature? also, you might want to consult with jrn above as i somehow doubt his method gives the same results as yours, you guys have to make up your minds ;).
> Story from a workplace [...]
nice story except... it doesn't prove what you'd like it to prove. your misunderstanding is based off the assumption that there was one bug in the system to be fixed whereas by your admission, there was more than one with a non-trivial dependency between them. due to that very dependency you *cannot* fix just that 'one' bug, you have to fix them at once (put another way, identifying the plaintext password 'bug' as a standalone instance was an error in judgement to begin with). this is a common situation with complex systems and yes, i maintain that you're better off by fixing security bugs than not fixing them. whether that implies touching a single file/subsystem/feature/whatever depends on the bug, if you have dependencies then you'll have to take them into account obviously.
now applying your idea to this kernel bug we're discussing here, tell me why it's a bad idea to apply it on its own (seemingly every distro out there has done it, so you're up against some serious wind). because if you can't justify it then you're also agreeing that the commit fixing this bug should not have covered up its security impact. so which is it?
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 24, 2012 13:38 UTC (Tue) by farnz (guest, #17727) [Link] We applied fixes for all the security bugs in the system. As a result of doing so, it became possible to sniff passwords in plain text on the network, when this was not previously possible. The reason? We didn't apply a feature enhancement that would have ensured that there was no plain text on the network. What part of this story is unclear to you? You are playing a semantics game that makes it impossible to discuss things reasonably with you - a bug is a "security bug" if a perfect person would have identified it as such, and if anyone fails to identify a bug as a security bug when it has security implications, they're engaged in a conspiracy. In the case of the bug I described, it was a mistake on the vendor's part - they had not considered the effects of the security fix, absent the feature enhancements, and as a result, applying the security fix reduced system security, by getting rid of an unlikely route for obtaining passwords, in favour of opening up a simple route for obtaining them. You are deliberately and dishonestly omitting a third option; that this is a sensible bugfix to apply in isolation, that fixes a genuine security problem, but the person fixing the bug did not (at the moment they committed the fix) realise that the bug was a security bug, and their time machine is faulty so they can't go back in time now that they've realised their mistake and correct their commit message. Or are you saying that the distros shipping the patch as a "security fix" aren't being honest when they say it fixes a security problem? Which is it - is there a conspiracy to never call this a security fix, and the distros are lying when they say it is, or did the fix commit simply occur before the fixer realised there were serious security implications to the fix? And can you and nye stop disagreeing about what's going on, please? Make up your mind about what you're talking about. ;)
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 24, 2012 15:03 UTC (Tue) by PaXTeam (subscriber, #24616) [Link]
> We applied fixes for all the security bugs in the system.
no, you did not, you said so yourself. what you did apply was fixes for a subset of problems in the system but most definitely not all, that's all i was trying to highlight. once more: when there're dependencies in a complex system you can't just arbitrarily ignore them when evaluating bugs and fixes (or any kind of change actually).
> a bug is a "security bug" if a perfect person would have identified it as such,
is that supposed to quote me or is it your opinion? because it's most definitely not true. not only because there's no such 'thing' as a 'perfect person' but also because what's one person's security bug may very well be another's feature. just read fandingo's post below.
> and if anyone fails to identify a bug as a security bug when it has
same question, are you trying to misattribute something to me or just voicing your own opinion? because it's wrong again, failing to identify the securiy impact of a bug is not a problem per se (or rather, it's a different problem, something i am *not* discussing here at all). what *is* a problem is when the person committing the fix knows the security impact but fails to disclose it. for the circumstances of this bug see http://seclists.org/fulldisclosure/2012/Jan/400 in case you missed it when i posted it the first time. Linus (and everyone on the kernel security list) was provided not only with the description of the bug and its security implications but also a working exploit *yet* nothing remotely related to the security consequences was mentioned in the commit. *that* is a coverup, no matter how you'd like to dance around it.
> [...]that this is a sensible bugfix to apply in isolation[...]
you didn't understand a word of what i said i guess, because the above is *wrong*. when you talk about the security of the *system* (as you were), you *must* consider the *system* when evaluating any change to it (be that a security fix or something else), not some parts of it you happen to like because you think it serves your argument. btw, it doesn't help when you use the same words (fix, bugfix, etc) for referring to different things in the same paragraph.
> Or are you saying that the distros shipping the patch as a "security
huh, where the heck did you get this from? citation needed. i think you're seriously getting lost in your arguments, you're mixing up arguing for different things and the end result is quite a mess... can you perhaps write your ideas down in simple 'isolated' sentences so that i know what's what?
> did the fix commit simply occur before the fixer realised there were
Linus knew full well the implications, read above. now what? ;)
> And can you and nye stop disagreeing about what's going on, please? Make
huh, we didn't disagree on anything, did we?
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 24, 2012 18:34 UTC (Tue) by farnz (guest, #17727) [Link] So, what does your statement "[you] has yet to disprove is that applying *any* security fix (regardless of other possible fixes) *does not* decrease one's security" mean, if not that I can apply a security fix (like the "no plaintext passwords" fix I mentioned in my story) in isolation, ignoring the other security fix because it was mistakenly classified as an enhancement? Applying a security fix decreased security - any employee could traffic sniff on that network, but only a limited number could get local access to the server.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 24, 2012 19:01 UTC (Tue) by PaXTeam (subscriber, #24616) [Link]
you're just playing with words now. a fix that breaks the system is not a fix, period. what you thought was a security fix for a particular problem wasn't a 'fix', at best it was something that changed the behaviour of the *system* with some parts improved, some parts degraded. if you actually had had a security fix then both your problems would have been fixed, the fact that they didn't means that your vendor did a sloppy job, not exactly unheard of in the real world you know.
what we (dlang, me, etc) were talking about is the situation where you have a well identified flaw with a fix (yes, 'fix' considering the *entire system* it may affect) and the question is whether it's a good or bad thing to let the world know about it. *you* have yet to get back to that topic and voice your opinion. you can start by addressing the timeline of this /proc/pid/mem bug and tell us why you think Linus was right/wrong when he covered up the security impact in the commit message.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 24, 2012 21:54 UTC (Tue) by farnz (guest, #17727) [Link] So, to confirm, you consider storing plain text passwords on a networked system with potential remote holes to not be a security risk? Or are you claiming that a fix that stopped storing those passwords in plain text becomes "not a security fix" if it opens up another hole by mistake? Which is it? You said that I could apply any security fix and improve net security, yet I've given you a counterexample, and you're simply accusing me of bad faith for doing so. And I would like a citation on the "Linus covered up the security impact when he wrote the commit message"; I cannot find any evidence that Linus attempted to say that there were no security implications to this flaw, or that the fix did not fix any security bugs. Note that if you're going to claim that an omission is evidence of a coverup, you're simply playing with words and trying to claim that one particular categorisation of flaws is important, while others aren't. I want you to point to somewhere where Linus explicitly addresses the security issue in question, and in the process attempts to cover up that this commit had a security impact.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 24, 2012 23:31 UTC (Tue) by jrn (subscriber, #64214) [Link]
> Which is it?
Is this discussion productive, at all? Is there any sort of enlightenment you are seeking from the people you are talking to? If not, would it be terrible for me to ask you to continue this elsewhere?
Thanks.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 24, 2012 23:42 UTC (Tue) by PaXTeam (subscriber, #24616) [Link]
> [...] Which is it? [...]
a false dichotomy ;).
> And I would like a citation on the "Linus covered up the security impact when he wrote the commit message";
you were given reading material, do your homework. if you don't understand something in there, feel free to ask ;).
> Note that if you're going to claim that an omission is evidence of a coverup.
farnz meet dictionary, dictionary meet farnz: http://dictionary.reference.com/browse/cover-up (note 'concealment', if in doubt: http://dictionary.reference.com/browse/conceal).
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 25, 2012 9:49 UTC (Wed) by farnz (guest, #17727) [Link] And yet a dichotomy that you gave me earlier in the same context; you missed out other options, and now, when faced with the same type of question, you refuse to respond for fear of disclosing your hypocrisy. It is clear that you do not intend productive discussion. Again, show me where Linus concealed the security impact - I see Linus in the fix commit telling us that the permission checks on /proc/pid/mem are faulty, and don't behave like other permissions checks; if you are not clueful enough to recognise that "permission checks are faulty" is a sign of a potential system security flaw, you are the sort of person who is likely to blindly take individual "security" patches without thinking about the complete systems context, and think that as a result of taking anything marked "security", while ignoring those patches not marked as security. I've already given you an example of a case where that behaviour pattern, encouraged by the upstream vendor, resulted in a net loss of system security; I do not understand why you wish Linus to encourage people to blindly apply patches without considering each in terms of the system security. Note, too, that security is rarely the most important thing people seek in a system - if it were, we would no longer be using C for more than hand-verified cores of security-correct languages, and our newer languages would have computer-verifiable proofs of correctness baked in (and checked by the users). We would accept a loss of functionality and an increase in system costs in return for that security; because we don't, it's clear that security is merely one type of important bug that we fix in our systems, and it does not follow that security bugs should be called out over any other type of bug.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 25, 2012 17:35 UTC (Wed) by PaXTeam (subscriber, #24616) [Link]
> And yet a dichotomy that you gave me earlier in the same context[...]
what dichotomy?
> [...]you refuse to respond for fear of disclosing your hypocrisy.
the problem is that i explained to you more than once already that what you so desperately tried to describe as a standalone 'security fix' wasn't that (if you want to argue about *this* then present your arguments). therefore i won't deal with the conclusion until you fix this false premise. little hint: repeating the same thing doesn't make it true, try a better route.
> It is clear that you do not intend productive discussion.
right, because your not answering the following questions previously was a clear attempt at a productive discussion:
1. you didn't show what 'all bugfixes' are. i asked you for a specific example and you evaded it with some hyperbole. that's not a productive discussion dude. you either answer with a list of git commits or you admit that you cannot produce it. which is it? (rhetorical question, i'm sure we both knew from the beginning that it is not possible but you have yet to come to terms with that since it means that your entire premise was false).
2. you didn't show how commits not adding new features cannot introduce bugs (else your algorithm for producing 'all bugfixes' is wrong). once again, i'm sure we both know that non-feature commits do at times introduce bugs so your algorithm is actually wrong (and as a side question, you didn't tell me how to decide what is a feature commit and what isn't). you have yet to admit that and you have yet to fix your algorithm (or admit that you cannot produce it).
3. you pretend to not understand that when you 'applied fixes for all the security bugs in the system' you actually didn't apply all. you yourself explained why that wasn't the case so forgive me if i stopped watching you argue with yourself ;). i'd also add that your case of applying fixes at your company is not at all like the case we've been discussing here (closed vs. open source systems, applying vendor blobs vs. backporting patches, you get the idea). i didn't point that out so far because i hoped you'd understand that even your own case has no standing, but seemingly i have to make this step now and ask you to explain what relevance your situation has to the one we've been discussing at all.
4. you have yet to explain why it is a bad idea to apply this particular fix (you know, the whole topic is still centered around the /proc/pid/mem problem) on its own (vs. applying any and all *other* fixes as well that went into 3.3-rc1). why did you evade that question? because it's what a productive discussion makes? or because you'd have then to explain why all the fixes that went in *after* 3.3-rc1 (where some of the problems were *introduced* by 3.3-rc1) should have been avoided in the first place (remember the 'all fixes' you were supposed to produce and that in hindsight should not have contained these fixes that needed later fixes)? let me guess, the productive discussion of this will result in your *not* responding to this in any meaningful way.
i could go on and on where you simply passed on the inconvenient admissions, but i think everyone's getting tired of this (myself included). if you think you have actual arguments to present to the above questions, go ahead. otherwise, yours will be the last word, i promise ;).
now let's see the real meat, the Linus commit and associated coverup.
> Again, show me where Linus concealed the security impact[...]
easy, you just said the word that doesn't even occur in the commit message, there's nothing even remotely related to the local root hole in fact.
> I see Linus in the fix commit telling us that the permission checks
you do see that. grep doesn't see the word 'faulty' in there (but that relates to /proc/pid/mem handling, not the 'permission checks'). i do see 'not very robust' only. let me not bring up the dictionary again to explain why the two words/expressions don't mean the same thing. not to mention that neither has *any* connotation with 'this is a security bug'. and they most definitely don't mean 'easily exploitable local root here'.
> [...]and don't behave like other permissions checks.
sadly for you, this doesn't imply 'local root hole here' either.
> if you are not clueful enough to recognise that "permission checks are
sadly for you, the commit message doesn't say that. what it does say is that said checks were *different* from checks done elsewhere. whether that's a bad or good thing is left for one's imagination, you most definitely do not learn it from Linus.
but the bigger problem with your statement above is that it implies that commit users (as i said already, that's mostly distros, companies, etc) are supposed to somehow divine the *actual* meaning of the commit from *clues* vs. learning of them directly with no coverup. are you *nuts*?
> [...]you are the sort of person who is likely to blindly take
i think you want to rethink this logic here. if one's not clueful enough to recognise the clues in this commit message then why would one blindly backport this commit? and if one's clueful enough to recognize the clues then why would one *not* blindly backport this commit? do you know of some issues that noone else does or talked about so far?
> I've already given you an example of a case where that behaviour pattern[...]
no, you didn't. read my contests of that claim and *respond* to them (yes, it bleeds from many wounds). pretty please?
> I do not understand why you wish Linus to encourage people to blindly
1. according to you Linus did reveal the security nature of the commit for the clueful (and i certainly hope you'd count distro maintainers, etc there), therefore he already committed (no pun intended) the sin of "encourag[ing] people to blindly apply patches without considering each in terms of the system security". where do i come in here then?
2. you didn't show which kernel commit users "blindly apply patches without considering each in terms of the system security". name them and shame them, the world, especially their users, deserves to know.
3. you haven't shown why properly describing the nature of fixes "encourage[s] people to blindly apply patches without considering each in terms of the system security". before you bring up your company example again, consider that we're talking about linux kernel commit users here, not (seemingly) clueless company employees and proprietary(?) vendors.
> that security is rarely the most important thing people seek in a system
this is a completely irrelevant statement, what argument is it supposed to support? you don't fix bugs, security or otherwise, because something is the 'most important thing', you fix them because they cause problems for you. if they don't, then you don't care, regardless of what 'the most important thing' in your life is.
> [long <something> that's not worth yet another long subthread now ;] it does not
i'm totally with you on this one! i do not want any *special* treatment for security bugs, i want them to be treated like any normal bug! you know, where the commit message describes what the bug is. say, when you have a filesystem corruption bug, the commit fixing it does say so instead of 'clues' that you could divine from the true nature of the fix if you are clueful enough. see, you were agreeing with me all the time, you want security fixes to say 'security fix' as much as you want filesytem corruption fixes to say 'filesystem corruption fix'. as things stand now, the latter happens and the former doesn't, that's what i'd like to change! and please don't make me sad by saying that filesystem corruption fixes should not be called out as such because that would "encourage people to blindly apply patches without considering each in terms of the" filesystem reliability.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 25, 2012 19:40 UTC (Wed) by farnz (guest, #17727) [Link] I've already given you a reference - if you can't find where you said "which is it?" in this thread, you are clearly simply trolling. I gave you extra detail about the fix, to avoid an incomplete disclosure of information, as I felt that would be unfair on you - I did not wish to trap you in a position where you said something clearly stupid as a result of my failure to provide full information. You have chosen to play with words, and say that the fix "isn't a security fix", despite the fact that it was clearly intended to fix a security problem, and indeed fixed the described security problem. The fact that it opened up a fresh security problem is a bug in the fix, not evidence that it's not a fix. I stated that a human being, paid to go over the list of commits between 3.2 and 3.3 could identify all bugfixes; you have refused to engage with this. You are choosing to engage in personal attacks ("are you nuts") rather than engage with the meat of my statement, which is that if you are analyzing all bugs for security impact anyway, this commit does not try to discourage you from doing so - instead, by indicating that there were permission check problems, it invites you to analyze this commit in more detail, to determine whether it affects security. In short, I believe that you are deliberately playing with words to avoid admitting that you are asking for the unreasonable. All bugs have security relevance in the right context (as anything that reduces availability of a system, such as a filesystem corruption bug, is a potential denial of service vector), ergo all bugs should, by your statement, be labelled as "security bugs".
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 25, 2012 20:07 UTC (Wed) by raven667 (subscriber, #5198) [Link] In short, I believe that you are deliberately playing with words to avoid admitting that you are asking for the unreasonable. All bugs have security relevance in the right context (as anything that reduces availability of a system, such as a filesystem corruption bug, is a potential denial of service vector), ergo all bugs should, by your statement, be labelled as "security bugs". This is a complete mischaracterization of the opinion of the person you are talking to, setting up a straw man to knock down rather than to engage in a debate. It has been repeatedly stated, every time this debate flames up, that the issue is not that the security impact of all bugs is unknown, it's that security bugs, reported as security bugs to security at kernel.org that are discussed in the context of how the bug breaks security do not have that information disclosed in the changelog or release notes by policy of the kernel team. So far I have seen precious few people actually discussing the substance of the disagreement, the pros and cons of disclosure, the consistency or inconsistency of how known security bugs are handled compared to known filesystem corruption or performance regression bugs. If we can't honestly acknowledge and understand the different positions on this issue then there is no point in continuing to discuss it.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 26, 2012 15:45 UTC (Thu) by patrick_g (subscriber, #44470) [Link] >> So far I have seen precious few people actually discussing the substance of the disagreement, the pros and cons of disclosure, the consistency or inconsistency of how known security bugs are handled compared to known filesystem corruption or performance regression bugs.About this point I found this citation from Linus Torvalds very interesting: « So my personal opinion is that the only sane approach is to just realize that it's not a solvable issue, and just treat bugs as bugs. We try to avoid having them in the first place, but when they do happen, we fix them. And we fix them without shouting from the rooftops about the details about how to exploit the issue, and without even trying to make it easy for the people who might want to try to exploit things to find them. And yes, that can very much involve not saying everything we know about how to exploit the bug in the changelog, or even necessarily pointing out that there is an advisory about it. Do security people always agree with me? Hell no. But they don't agree amongst themselves either, so what does that prove?»
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 25, 2012 21:01 UTC (Wed) by PaXTeam (subscriber, #24616) [Link]
as promised, not continuing the silly example as you ran out of steam (that dichotomy was yours, not mine btw ;), instead let's see the actually relevant matter, this coverup.
> I stated that a human being, paid to go over the list of commits between
you stated many things so far, but ex cathedra statements are not proof. on a sidenote i'd like to make the observation that you're expecting the impossible: on one hand you want to cover up security fixes as much as possible but on the other hand you expect people to still figure out them. you can't have it both ways ;).
> You are choosing to engage in personal attacks ("are you nuts") [...]
so i thought we were adults here and i didn't take it personally when you called me dishonest out of the blue but i see personal attacks can only go one way here. good riddance!
> [...]which is that if you are analyzing all bugs for security impact anyway
bad premise! noone wants to spend time on analyzing a commit for security impact when that very piece of information is *already* known by none other than the committer himself, all he has to do is disclose it!
> [...]by indicating that there were permission check problems[...]
show me where 'permission check problems' occurs in the message. what does occur is a note that said checking doesn't match what's done elsewhere. no mention of that itself being a problem of any sort! (and in fact it isn't, the problem was with the underlying object, not the permission checks, the latter changed *because* the underlying object was changed)
> it invites you to analyze this commit in more detail, to determine whether it affects security.
one last time: why on earth would anyone want to spend time to determine that when that has already been done?!
> that you are asking for the unreasonable.
i will *never* admit that asking for information that is known to the committer is unreasonable. it is in fact the *only* reasonable action.
> All bugs have security relevance in the right context [...]
another ex cathedra statement so prove it! (and no, redefining 'bug' as 'something that has security relevance in the right context' would not be proof)
you can also demonstrate it with this commit: 3493c85366ba09c9d0972c919e7123367a39982a and see if you can get a CVE for it.
> ergo all bugs should, by your statement, be labelled as "security bugs".
as ironic as it is, we'd be better off than we are today, at least -stable people and other interested parties would know what to backport, even by your own measure ;).
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 26, 2012 3:04 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
My opinion?
any patch is a bugfix unless you can prove that you do not ever run that code (which realistically means that this only eliminates things that you can compile out of the kernel)
note that is is very possible for bugfixes to contain bugs themselves.
you may try to argue that some patches implement new things, but since (unless you can configure your system to not use the new code) this changes how the existing code works, it has the potential to fix bugs (if by no other means than by accidentally eliminating a potential race condition)
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 24, 2012 13:06 UTC (Tue) by nye (guest, #51576) [Link]
>this is exactly the disconnect.
> you assume that the person fixing the bug understood the security implications of it, from the comments (and from dealing with many developers over many years), I believe that they usually don't understand the security implications of bugs that they deal with.
You may not agree with PaXTeam, but bringing up this tired strawman is shamefully dishonest.
You know *very well*, as it's repeated *every time this comes up*, that nobody is asking for all security fixes to be flagged as such, but rather for known fixes to known security problems to *not have that information actively removed*.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 24, 2012 19:40 UTC (Tue) by raven667 (subscriber, #5198) [Link]
This is probably something that will have to be repeated every time, along with a lot of other points, because every time it comes up there are people who don't understand and haven't been party to the previous discussions. Rather than getting angry with people it might be better to just work on an "elevator pitch" summary of the important arguments that you can cut-n-paste into any discussion for the n00bs 8-).
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 24, 2012 20:08 UTC (Tue) by PaXTeam (subscriber, #24616) [Link]
dlang's not 'n00bs', check https://lwn.net/Articles/461552/ for some history (should ring you a bell too while we're at it ;).
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 24, 2012 20:19 UTC (Tue) by raven667 (subscriber, #5198) [Link]
That's probably just my twitterbrain in action, responding to comments without checking the full history of the thread. You are right, dlang is just trolling in this instance, pretending not to understand. There has to be a better way to move the discussion forward though than escalated mutual trolling.
I hope you are doing well 8-)
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 26, 2012 3:23 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
I did not pretend to not understand PaxTeam's position, my initial post was pointing out that as far as I could tell from the information provided, this was an example of a fix being generated that was not recognized as a security fix at the time it was committed, and as such was not called out to be a security fix.
It sounds as if the security implications were recognized later while the patch was being discussed, but I don't know if it had been merged into the linus tree by that point (if not, then it could have been tagged as a security fix, if it had already been merged than it was too late)
the only reason to worry about if a patch was tagged as a security fix or not is the idea that someone will only apply security fixes, not all fixes. Is that isn't going to be the case, why does it matter if the fix is tagged as security related or not?
as was demonstrated in posts elsewhere, just applying fixes tagged as being security related can end up with a less secure system that not applying any patches. The best thing to do is to upgrade and get all fixes, because you don't know if they are really security related or not.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 26, 2012 9:05 UTC (Thu) by fuhchee (subscriber, #40059) [Link]
"The best thing to do is to upgrade and get all fixes"
Questionable: I don't want to reboot everything daily (?) just for random fixes and unproven features.
"because you don't know if they are really security related or not."
True: the commit-message non-disclosure policy does its part in ensuring such ignorance.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 26, 2012 9:21 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
kernel releases don't happen daily, but if you are running a system critical enough, you will be rebooting it frequently, and you won't be waiting for your distro to package the update either, you will have some person (or team) dedicated to finding problems, generating fixes (either by backporting patches or developing new ones), testing them and deploying them.
if you just take patches from the vendor and deploy them to production when the vendor gives them to you, you will not have a stable, secure production system (and it will be worse in many ways if you only apply the 'important' patches out of those that are provided)
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 26, 2012 9:50 UTC (Thu) by fuhchee (subscriber, #40059) [Link]
"... you will have some person (or team) dedicated to finding problems, generating fixes (either by backporting patches or developing new ones), testing them and deploying them"
So this alternative envisions having in-house kernel qa/dev talent.
"if you just take patches from the vendor and deploy them to production ..."
This alternative outsources the qa/dev talent to the vendor.
Neither alternative is simply running upstream kernels. Does anyone except for kernel developers do that?
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 26, 2012 10:22 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
blindly running the latest kernel.org kernel is just outsourcing this to the kernel developers. It doesn't solve things either.
the reality is that you need to do testing of new versions before you run them on your critical systems, no matter where it comes from (internal developers, kernel.org developers, RedHat, Debian, or any other distro)
now the only remaining question is which source to use. All of them try to only introduce good things and fix bugs, but they all miss bugs, and they all introduce new bugs in the process.
I think it's undisputed that the kernel.org developers fix the most bugs.
But it's also undisputed that the kernel.org developers introduce the most new bugs.
It's really going to be up to your organization to decide if they think that running kernel.org kernels that you have tested is best, or if running distro kernels that you have tested is best, or something else.
I've been running kernel.org kernels in production, at a large company (10K+ employees now) for 15 years. There are people who do so with great reliability. I have done more kernel updates with fewer problems than other teams in the company that have been running RedHat kernels (and they have historically been buying servers from 'better' vendors as well)
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 26, 2012 10:41 UTC (Thu) by fuhchee (subscriber, #40059) [Link]
I find I have trouble seeing what all that has to do with the need to know whether particular fixes represent security problems.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 26, 2012 19:50 UTC (Thu) by raven667 (subscriber, #5198) [Link]
the point is that you don't need to know if you just follow kernel.org, you always get all fixes (and all new bugs)
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 31, 2012 9:16 UTC (Tue) by Klavs (subscriber, #10563) [Link]
If the machine is so important it "can't" be booted - it should be setup in a cluster, as no machines hardware is stable enough to ensure never rebooting.
And as dlang says new kernels releases is not happening every day - and if you like, you can rather easily (if you're a Linux sysadmin) follow mainline kernel instead of your distro's kernel - it's what a lot of us did in the 2.0 and 2.2 (and 2.4 even) days.
Back then - Linux did mark Security fixes as such - but always stated the one should always update anyhow - and clearly many people only up updated the kernel when they saw an actual security flaw mentioned.
I believe this issue would be solved, if only the release notes for the kernel, always stated (at the top) that many of the bugfixes, may well have a security impact as well - and we do not try "in any way" to try to identify if this is the case - so you should always stay updated.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 31, 2012 16:34 UTC (Tue) by raven667 (subscriber, #5198) [Link]
> I believe this issue would be solved, if only the release notes for the kernel, always stated (at the
> top) that many of the bugfixes, may well have a security impact as well - and we do not try "in any > way" to try to identify if this is the case - so you should always stay updated
I thought that's what they did which as a policy is still causing a kerfluffle. Maybe the solution would be to become much more diligent about marking bugfix and feature updates separately and correctly and fully describing the bugfixes including known security impacts in the change log so that a "stable" kernel won't miss important backports. This is already done to an extent so strengthening that process might fix a lot of the complaints.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 26, 2012 19:47 UTC (Thu) by raven667 (subscriber, #5198) [Link] It sounds as if the security implications were recognized later while the patch was being discussed, but I don't know if it had been merged into the linus tree by that point (if not, then it could have been tagged as a security fix, if it had already been merged than it was too late) I don't believe this to be true, the initial report was submitted to the security at kernel.org mail address as a local root exploit. The security implications were known from moment one.
Ubuntu update Posted Jan 23, 2012 16:34 UTC (Mon) by mdeslaur (subscriber, #55004) [Link]
We've published ours:
RHEL Posted Jan 23, 2012 16:46 UTC (Mon) by corbet (editor, #1) [Link] For people running RHEL (and derived) systems, Red Hat has put up a SystemTap-based workaround to close the vulnerability until a proper update is available and can be installed. It also appears (from the bugzilla entry) that only RHEL6 is vulnerable; older releases do not have a recent-enough kernel to be affected.
RHEL Posted Jan 24, 2012 4:17 UTC (Tue) by eteo (guest, #36711) [Link]
Red Hat has released an update for Red Hat Enterprise Linux 6, https://rhn.redhat.com/errata/RHSA-2012-0052.html.
RHEL Posted Jan 24, 2012 4:33 UTC (Tue) by eteo (guest, #36711) [Link]
We wrote a knowledgebase article at https://access.redhat.com/kb/docs/DOC-69129.
is 3.2.1 also vulnerable? Posted Jan 23, 2012 19:47 UTC (Mon) by pheldens (guest, #19366) [Link]
why is there no patched release out yet?
is 3.2.1 also vulnerable? Posted Jan 23, 2012 21:44 UTC (Mon) by skx (subscriber, #14652) [Link] 3.2.1 is vulnerable, as is 3.2[.0]. I was expecting an update to be released, but thus far I've had to patch my box manually.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 24, 2012 14:27 UTC (Tue) by fandingo (subscriber, #67019) [Link]
Okay, this is just too funny for words.
I'm introducing Linux to some people at work and as part of it I've setup VMs for them to use. I don't want to provide access on the internet to the VMs. The users will log into rbash and have access to ssh and virsh console only.
To do that, I symlinked ssh, virsh, and sudo (virsh needs to be run as sudo) into ~/bin/ and set $PATH to that directory only.
I was trying to lock down permissions even more, and that's when it happened: the chown -R that included ~/bin.
I try to sudo yum update today. "sudo: must be setuid root."
Shiiiitt... And, my root pw isn't with me so...
I'm trying to figure out how I can fix this remotely, and I'm running out of ideas.
Talk about lucky.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 25, 2012 1:29 UTC (Wed) by i3839 (guest, #31386) [Link]
What I don't get is how they can write to a read-only mapped memory area.
Or can you write to any address, no matter how it is mapped by the process?
Anyway, doesn't work for me on 2.6.39-rc5.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 25, 2012 12:03 UTC (Wed) by PaXTeam (subscriber, #24616) [Link]
it's because mem_write calls a function that behaves as ptrace which can break copy-on-write and modify otherwise read-only mappings. i already raised that issue here in that i'm not sure if it's a design decision or just an oversight. i'd think that this capability is usually used by a debugger to place breakpoints on code (which is usually a read-only mapping) but then normal ptrace calls are enough for that, /proc/pid/mem was meant more for bulk transfer i think.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 27, 2012 1:04 UTC (Fri) by i3839 (guest, #31386) [Link]
But now there is process_vm_readv/process_vm_writev there is no need for /proc/pid/mem for any transfers anymore. Legacy applications can still use it of course, but there was absolutely no reason to relax write permissions on mem. It all seems like a huge silly mistake.
Speculation about the commit message Posted Jan 25, 2012 11:46 UTC (Wed) by cesarb (subscriber, #6266) [Link]
At the risk of fanning the flames again...
I have been thinking about the commit which fixed this bug (http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-...). It looks like a strange commit to fix a security bug; it talks about making things more robust, and about having to be reverted if programs depended on the old behavior. It also does not Cc: stable@vger.kernel.org
Compare that to how it was fixed on AOSP's kernel tree: by simply ifdefing out the code again (reverting the patch which removed the #ifdef).
I think I now understand. The actual fix for the security bug is to ifdef out the code again. After that, you have that commit from Linus, which changes the way it works to make it more robust. And, after that, you remove the ifdef again, since now it should be secure.
Squash these three commits together, and you have just the patch from Linus, which is what he committed. This explains the commit message: the change really is to make the code more robust. The security fix becomes invisible and irrelevant by being squashed with its opposite.
It is possible that the fix for the stable trees end up being simply disabling the mem_write function again (the stable trees do not seem to have a fix for this yet). Since Linus is committing to a -rc1 kernel, he can try a more risky fix, since it has time to be tested and enhanced before 3.3 is released (someone else in this thread mentioned it could allow one to eat up memory invisibly or something like that, for instance).
Speculation about the commit message Posted Jan 25, 2012 12:09 UTC (Wed) by PaXTeam (subscriber, #24616) [Link]
> The actual fix for the security bug is to ifdef out the code again.
no, ifdef'ing it out does not fix it, or rather it only fixes mem_write but does nothing for mem_read which seemingly has the same buggy logic in it. whether this latter is actually exploitable in practice depends on whether a culprit suid exists out there but the potential for such a disaster is there regardless.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 26, 2012 15:49 UTC (Thu) by BenHutchings (subscriber, #37955) [Link]
Fixed in Debian's package version 3.2.1-2; also in stable version 3.2.2.
|
|||||||||||||