Recent Features
| |||||||||||||
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 19:40 UTC (Wed) by farnz (guest, #17727)In reply to: Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) by PaXTeam Parent article: Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4)
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".
(Log in to post comments)
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 ;).
|
|||||||||||||