Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4)
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4)
Posted Jan 24, 2012 9:34 UTC (Tue) by PaXTeam (guest, #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)
> 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.
Posted Jan 24, 2012 11:10 UTC (Tue)
by jrn (subscriber, #64214)
[Link] (2 responses)
git rev-list --grep=stable@ v3.2..v3.3-rc1
Alas, people often forget to cc stable@.
Posted Jan 24, 2012 11:17 UTC (Tue)
by PaXTeam (guest, #24616)
[Link] (1 responses)
Posted Jan 24, 2012 19:14 UTC (Tue)
by jrn (subscriber, #64214)
[Link]
Why? How would that kind of conversation be useful in the least?
Posted Jan 24, 2012 11:27 UTC (Tue)
by farnz (subscriber, #17727)
[Link] (14 responses)
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.
Posted Jan 24, 2012 12:13 UTC (Tue)
by PaXTeam (guest, #24616)
[Link] (13 responses)
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?
Posted Jan 24, 2012 13:38 UTC (Tue)
by farnz (subscriber, #17727)
[Link] (12 responses)
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. ;)
Posted Jan 24, 2012 15:03 UTC (Tue)
by PaXTeam (guest, #24616)
[Link] (11 responses)
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?
Posted Jan 24, 2012 18:34 UTC (Tue)
by farnz (subscriber, #17727)
[Link] (10 responses)
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.
Posted Jan 24, 2012 19:01 UTC (Tue)
by PaXTeam (guest, #24616)
[Link] (9 responses)
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.
Posted Jan 24, 2012 21:54 UTC (Tue)
by farnz (subscriber, #17727)
[Link] (8 responses)
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.
Posted Jan 24, 2012 23:31 UTC (Tue)
by jrn (subscriber, #64214)
[Link]
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.
Posted Jan 24, 2012 23:42 UTC (Tue)
by PaXTeam (guest, #24616)
[Link] (6 responses)
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).
Posted Jan 25, 2012 9:49 UTC (Wed)
by farnz (subscriber, #17727)
[Link] (5 responses)
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.
Posted Jan 25, 2012 17:35 UTC (Wed)
by PaXTeam (guest, #24616)
[Link] (4 responses)
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.
Posted Jan 25, 2012 19:40 UTC (Wed)
by farnz (subscriber, #17727)
[Link] (3 responses)
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".
Posted Jan 25, 2012 20:07 UTC (Wed)
by raven667 (subscriber, #5198)
[Link] (1 responses)
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.
Posted Jan 26, 2012 15:45 UTC (Thu)
by patrick_g (subscriber, #44470)
[Link]
Posted Jan 25, 2012 21:01 UTC (Wed)
by PaXTeam (guest, #24616)
[Link]
> 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 ;).
Posted Jan 26, 2012 3:04 UTC (Thu)
by dlang (guest, #313)
[Link]
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)
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4)
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4)
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4)
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4)
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4)
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4)
> security implications, they're engaged in a conspiracy.
> fix" aren't being honest when they say it fixes a security problem?
> serious security implications to the fix?
> up your mind about what you're talking about. ;)
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4)
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4)
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4)
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4)
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4)
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4)
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4)
> on /proc/pid/mem are faulty[...]
> faulty" is a sign of a potential system security flaw[...]
> individual "security" patches without thinking about the complete
> systems context[...]
> apply patches without considering each in terms of the system security.
> 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)
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4)
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".
>> 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.Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4)
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)
> 3.2 and 3.3 could identify all bugfixes; you have refused to engage with this.
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4)