| |||||||||||||
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4)Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4)Posted Jan 25, 2012 17:35 UTC (Wed) by PaXTeam (subscriber, #24616)In reply to: Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) by farnz Parent article: Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4)
> 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.
(Log in to post comments)
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 ;).
|
|||||||||||||