Stable kernel 2.6.38.3
Posted Apr 15, 2011 8:48 UTC (Fri)
by PaXTeam (guest, #24616)
[Link] (21 responses)
Posted Apr 15, 2011 9:12 UTC (Fri)
by tcourbon (guest, #60669)
[Link] (7 responses)
And your attitude isn't very constructive. Except that it reinforce the picture I have of what "PaXTeam security experts" are as persons.
("Lol, let's put some uppercased letter in the middle of our name so everyone will understand we are true l33t.")
Posted Apr 15, 2011 9:55 UTC (Fri)
by PaXTeam (guest, #24616)
[Link]
'memory leak' is rather a consequence of something, for instance here 'forgot to decrement refcount'. you were saying... ? ;)
> And I don't think a commit message is the right place to list all the
it's a strawman. who talked about 'all the potential issues'? i certainly didn't because i would have run out of space then.
> And your attitude isn't very constructive.
why's that? you didn't know it was a privilege escalation bug before, now you do.
PS: LWN doesn't allow whitespace in usernames, and PaX stands for '[Pa]ge e[X]ec' as a (now) historical reference to the original feature implemented by (what had started out at the time as an actual team of) us, it has nothing to do with elitespeak. but hey, apparently i'm the one with the attitude problem, not you, so it's all c001 ;).
Posted Apr 15, 2011 10:12 UTC (Fri)
by ledow (guest, #11753)
[Link] (4 responses)
Kinda daft for a "team" that consists of one person, who remains anonymous - always a way to inspire trust - and who has more of a reputation for being an "opinion bully" than for actually getting code into the kernel.
It's a shame to see someone who's obviously a good coder with well-intentioned ideas throw it all away because they are so confrontational and persistently annoying.
PaXTeam is spam, basically. Filter as you deem appropriate.
Posted Apr 15, 2011 10:31 UTC (Fri)
by PaXTeam (guest, #24616)
[Link] (2 responses)
it seems i struck a nerve or something :). are you a kernel developer? or do you just cover up security bugs in whatever software you work on? for the record, i think dozens of kernel releases passed by since i had last singled out an obvious security bug, i did this one in particular because the exact same kind occured almost 3 years ago (https://lwn.net/Articles/288490).
PS. i find it very funny when an anonymous person rants about another ;)
Posted Apr 15, 2011 12:38 UTC (Fri)
by pyellman (guest, #4997)
[Link]
Posted Apr 15, 2011 17:49 UTC (Fri)
by xorbe (guest, #3165)
[Link]
Posted May 7, 2011 9:21 UTC (Sat)
by nix (subscriber, #2304)
[Link]
Posted Apr 15, 2011 17:47 UTC (Fri)
by chad.netzer (subscriber, #4257)
[Link]
I've previously advocated for interested parties to host a git repo which uses the "git notes" feature to amend commits with the security implications that are found for a commit (for those advocating such things). And perhaps someone has by now; the tools are there, at least in a crude form. If there is truly value in having that data in a repo, it should become popular w/ distros and vendors.
Posted Apr 15, 2011 16:54 UTC (Fri)
by tetromino (guest, #33846)
[Link] (12 responses)
What the developer noticed was a memory leak, and so that's what he put in the commit message. The fact that this particular memory leak could potentially have been used for privilege escalation isn't all that obvious. It didn't occur to me that there might be a security impact until I read your post from 2008 that you linked to above.
Have you considered writing an in-depth howto for avoiding common security flaws in kernel code? I suspect that such a document would be much more effective for improving kernel security than a thousand sarcastic comments on lwn :)
Posted Apr 16, 2011 8:11 UTC (Sat)
by PaXTeam (guest, #24616)
[Link] (11 responses)
uhm, did you just call the kernel devs stupid? i don't think that's true.
> Have you considered writing an in-depth howto for avoiding common security flaws in kernel code?
fortunately, others have done this already: http://cwe.mitre.org and for this particular case (it's part of a larger class): http://cwe.mitre.org/data/definitions/416.html .
Posted Apr 16, 2011 18:06 UTC (Sat)
by tetromino (guest, #33846)
[Link] (10 responses)
What I meant was that the one particular dev who wrote the patch and the commit message was unobservant or not thinking like an attacker.
> http://cwe.mitre.org/data/definitions/416.html
See, everyone knows that use-after-free can lead to exploits. But what is less obvious is that what appears to be a simple memory leak can become use-after-free if the leaked object is reference-counted with a fixed-width refcount, and an attacker can reliably induce the leak to overflow the refcount to zero.
That's what I mean by an in-depth howto: not just "use-after-free is bad", but "these are commonly seen situations in kernel code that can (despite their innocuous appearance) lead to use-after-free".
Posted Apr 18, 2011 15:41 UTC (Mon)
by PaXTeam (guest, #24616)
[Link] (9 responses)
one would assume so but i'm sometimes having second thoughts about it ;).
> But what is less obvious is that what appears to be a simple memory leak
if you read the entire CWE-416 page you'll find references to real bugs of the class, among others the refcount overflow related ones as well (not in their reference list, but http://www.pine.nl/press/pine-cert-20040201.txt is also educational to show that it's not a new problem at all). kernel devs in general have been well aware of the adverse effects of this kind of problem, see the discussions from 2005 (http://lkml.org/lkml/2005/11/9/436) and 2007 (http://lkml.org/lkml/2007/5/19/205), and probably long before that ;). i honestly don't know what kind of 'depth' is needed to explain that a refcount reaching 0 (or whatever the condition is, but 0 is typical) means freeing the object regardless of possible outstanding 'references' to it, it's all basic programming like a malloc/free/use sequence.
Posted Apr 20, 2011 1:35 UTC (Wed)
by vonbrand (subscriber, #4458)
[Link] (8 responses)
Please, not again this useless discussion... Yes, the kernel has bugs. Yes, kernel developers find and fix bugs. Yes, some bugs have security implications. Yes, there are broad categories of bugs that are known to be responsible for security problems. Right, not every buffer overflow/use-after-free/off-by-one/stray pointer/wrong check/... is a security risk. OK so far? Then please consider that very few of the bugs have security implications (you show up here around once a kernel cycle, and if you look at the kernel development statistics, that means thousands of patches, many of them bug fixes. So out of, conservatively, 1,000 bug fixes 2 or 3 are for bugs that are security relevant. You really want the busy kernel developers waste many hours trying to find out if the idiotic mistake they just found and fixed could be exploited (i e., is amoung the at most 1% that could be real problems)? You do realize that the developers probably aren't interested in this kind of work, and aren't qualified to do a good job at this determination either?
Posted Apr 20, 2011 2:12 UTC (Wed)
by jrn (subscriber, #64214)
[Link]
If you focus on 2.6.x.y kernels (which seems like a reasonable thing to do), the ratio is probably higher. Not that it means much, but I am inclined to agree with them that downplaying the security impact of a patch in the log message seems neither effective nor helpful. Probably that didn't happen in this example, but since it does still seem to happen from time to time, why quibble?
A kernel tree with notes (or a simple list, for that matter) describing the security impact of patches would be nice indeed. It's not the obligation of the people writing the patches to do that work --- anyone could step up and set up a way to cooperate on this (analogous the current stable@kernel.org process).
Posted Apr 20, 2011 18:15 UTC (Wed)
by PaXTeam (guest, #24616)
[Link] (6 responses)
where did you get those numbers from? i bet you just made them up ;).
> You really want the busy kernel developers waste many hours trying to
it's a strawman, i never said anything like this (i.e., quote me back or admit you made this up too). what i did say in the past was that obviously exploitable bugs should be documented in the commit as such. as things stand, they're not documented anywhere, a.k.a. silent fixes. does this bug have a CVE already? even if it does or will get one, would it have gotten one if i hadn't raised the issue? what does that say about the exploitable bug statistics everyone's so quick to cite to prove whatever the point du jour is? how do kernel developers measure the progress (or lack thereof) of kernel security (never mind other qualities) if the raw data is incomplete? and of course there's more use to this kind of information than fabricating statistics, but let's not repeat everything again :).
> You do realize that the developers probably aren't interested in this
strawman as above.
> and aren't qualified to do a good job at this determination either?
i realize it so much that i made the exact same statement in the past that, contrary to your insinuations, i can back up with a real quote: https://lwn.net/Articles/373896/ . at least you agree with me on something, that's progress ;).
Posted Apr 21, 2011 16:03 UTC (Thu)
by vonbrand (subscriber, #4458)
[Link] (5 responses)
What are you asking then? You regularly complain that fixes to bugs with security implications aren't marked prominently as such. All I'm saying is that determining if a bug has security implications is work that not everybody is qualified to do (and many just aren't willing to do in the first place). "Obviously exploitable" is certainly in the eye of the beholder. BTW, citing yourself as the authoritative source on some point doesn't advance the discussion one bit.
Posted Apr 22, 2011 7:03 UTC (Fri)
by PaXTeam (guest, #24616)
[Link] (4 responses)
now according to you i "show up here around once a kernel cycle" so i trust you also have the intelligence to actually read and understand what i wrote on those occasions.
> You regularly complain that fixes to bugs with security implications
s/prominently/at all/ . it's per Linus's decree, you can find it on lkml.
> All I'm saying is that determining if a bug has security implications is
which is what i have stated in the past too.
> "Obviously exploitable" is certainly in the eye of the beholder.
it's not, see the CWE link i gave above. there is no excuse for not knowing whether a stack or heap buffer overflow is exploitable or not. especially when someone hit said bug in real life and reported the oops with clear signs of an EIP overwrite on lkml. in short, knowing good coding practices is part of the professional programmer's armoire, everyone else should keep their code to themselves. civil engineering or medicine has reached that state already, programming will as well.
> BTW, citing yourself as the authoritative source on some point doesn't
man, did you even read what i cited? i was confirming that i had said the exact same thing on that topic as you did (and i did it again here above) and now you're complaining that we seemingly agree on something? can you ever be satisfied? ;)
Posted Apr 22, 2011 16:28 UTC (Fri)
by vonbrand (subscriber, #4458)
[Link] (3 responses)
I do believe so. I just don't agree most of the time. Must have misread, sorry.
Posted Apr 23, 2011 18:51 UTC (Sat)
by PaXTeam (guest, #24616)
[Link] (2 responses)
care to explain what you are talking about here?
> Just flagging all CWE-suspicious bugs would include most bugfixes [...]
where did you get this idea from? have you done any research on this? got any numbers perhaps? or did just make it up as usual? ;)
> [...] and I'm sure they won't include all, or even the most serious ones [...]
and this one? made up too? ;)
> [...] and I'm sure way too many false positives would sneak in.
and now we have a third, completely out of the blue, statement. seriously, have you got *any* evidence for *any* of the above statements? i bet you don't. i bet you made all of this up. i note that you didn't back up your previous statement either when i called you out on it, so probably you'll remain silent on these as well which doesn't exactly advance the discussion.
> And don't accuse the kernel programmers of not "knowing good coding
you're wrong. Linus didn't codify anything of the sort. what he did declare in no uncertain words is that he does *not* want to see any greppable keywords in commit messages. even when the committer full well knows the security impact of the bug he's just fixed. *that* is the big problem linux development has (and i pointed out many times already) and earned him a pwnie award not long ago.
in general, it seems that you're arguing about something different (a strawman, as i never stated any of this): that kernel developers figure out whether a commit has a security impact or not. that's clearly neither their job nor competence, so i'm not sure why you keep raising this red herring. what i've been always talking about is that *if* they know that a commit fixes some security issue then they say so in the commit. do you understand the difference?
Posted Apr 25, 2011 0:46 UTC (Mon)
by vonbrand (subscriber, #4458)
[Link] (1 responses)
Yes, I do. And having a few patches flagged as security relevant (and the majority that is security relevant not so flagged) will just lead to all kinds of mud slinging ("They should have known!"); won't make the conspiracy theories go away; will have "smart" people just apply the "minimal, i.e. security relevant" set of patches and much moaning when they get pwned. Better not publicize incomplete, very fragmentary information that can turn out misleading. If you want to have security relevance for patches better do a decent job, or none at all, than a (less than) half-assed one.
Posted Apr 25, 2011 8:54 UTC (Mon)
by PaXTeam (guest, #24616)
[Link]
why would it lead to that (better cite some evidence)? do you see mud slinging for patches that are not marked as fixing e.g., a file system corruption bug? do you realize that security bugs caused by memory corruption can easily result in such damage as a sideeffect? would you not want to know about that?
> (and the majority that is security relevant not so flagged)
do you have any evidence for this or did you just make this up?
> won't make the conspiracy theories go away;
what conspiracy theories? what do they matter anyway? since when do someone's fringe theories control kernel development decisions?
> will have "smart" people just apply the "minimal, i.e. security
do you have evidence for the existence of such people? do you know how much of the linux userbase they represent? do you know if there're people who already do this? what would then change? if you think it's the kernel developers' job to protect 'smart' people from themselves, then they shouldn't make those commits available at all as no matter what they do, someone will always take it the wrong way. do you see where your thoughts would lead? death of open source as we know it.
> Better not publicize incomplete, very fragmentary information that can
knowing that a bug fixes a security issue is neither incomplete nor fragmentary information, nor does it mislead anyone: applying a patch that does not in turn fix a security issue just a normal bug doesn't hurt anyone (this is what already happens today, you see).
> If you want to have security relevance for patches better do a decent
there's nothing 'half-assed' in passing information down to the users that the developers already have. real world example: drugs used in medicine are known to have various sideeffects. these must be (by law, even) communicated to the patient. *but* there's no guarantee that *all* possible sideeffects are known for any given drug (we know in fact that some are discovered later, often much later after real damage has been done), yet that somehow doesn't prevent the *known* sideeffect information from being published. according to you, sideeffects of drugs must not be published because they are "incomplete, very fragmentary information that can turn out misleading".
80b9edca1c11ec8118ab30451af9c1d492770c90
80b9edca1c11ec8118ab30451af9c1d492770c90
80b9edca1c11ec8118ab30451af9c1d492770c90
> potential issues caused by some issue in the code.
80b9edca1c11ec8118ab30451af9c1d492770c90
80b9edca1c11ec8118ab30451af9c1d492770c90
80b9edca1c11ec8118ab30451af9c1d492770c90
80b9...
80b9edca1c11ec8118ab30451af9c1d492770c90
80b9edca1c11ec8118ab30451af9c1d492770c90
80b9edca1c11ec8118ab30451af9c1d492770c90
80b9edca1c11ec8118ab30451af9c1d492770c90
80b9edca1c11ec8118ab30451af9c1d492770c90
80b9edca1c11ec8118ab30451af9c1d492770c90
> can become use-after-free if the leaked object is reference-counted with
> a fixed-width refcount, and an attacker can reliably induce the leak to
> overflow the refcount to zero.
80b9edca1c11ec8118ab30451af9c1d492770c90
Marking security bugs
80b9edca1c11ec8118ab30451af9c1d492770c90
> find out if the idiotic mistake they just found and fixed could be
> exploited (i e., is amoung the at most 1% that could be real problems)?
> kind of work,
80b9edca1c11ec8118ab30451af9c1d492770c90
You really want the busy kernel developers waste many hours trying to
find out if the idiotic mistake they just found and fixed could be
exploited (i e., is amoung the at most 1% that could be real problems)?
it's a strawman, i never said anything like this (i.e., quote me back or admit you made this up too). what i did say in the past was that obviously exploitable bugs should be documented in the commit as such. as things stand, they're not documented anywhere, a.k.a. silent fixes. does this bug have a CVE already? even if it does or will get one, would it have gotten one if i hadn't raised the issue? what does that say about the exploitable bug statistics everyone's so quick to cite to prove whatever the point du jour is? how do kernel developers measure the progress (or lack thereof) of kernel security (never mind other qualities) if the raw data is incomplete? and of course there's more use to this kind of information than fabricating statistics, but let's not repeat everything again :).
80b9edca1c11ec8118ab30451af9c1d492770c90
> aren't marked prominently as such.
> work that not everybody is qualified to do [...]
> advance the discussion one bit.
80b9edca1c11ec8118ab30451af9c1d492770c90
now according to you i "show up here around once a kernel cycle" so i trust you also have the intelligence to actually read and understand what i wrote on those occasions.
> "Obviously exploitable" is certainly in the eye of the beholder.
It might be documented in a CWE or somewhere else that certain types of mistakes may lead to exploitable holes given a truckload of other, totally unrelated circumstances. Just flagging all CWE-suspicious bugs would include most bugfixes, and I'm sure they won't include all, or even the most serious ones (and I'm sure way too many false positives would sneak in). And don't accuse the kernel programmers of not "knowing good coding practices" just because they aren't interested (yes, Linus codified that, but it is more a stating of common practice than a decree) in doing the hard work of finding out if there is a practical way to exploit a bug (and then getting blamed later if they turn out to be mistaken). And that a particular bug report shows up in LKML doesn't mean that the bug fix is the result from that report, it very well can be completely unrelated.
it's not, see the CWE link i gave above. there is no excuse for not knowing whether a stack or heap buffer overflow is exploitable or not. especially when someone hit said bug in real life and reported the oops with clear signs of an EIP overwrite on lkml. in short, knowing good coding practices is part of the professional programmer's armoire, everyone else should keep their code to themselves. civil engineering or medicine has reached that state already, programming will as well.
> BTW, citing yourself as the authoritative source on some point doesn't
> advance the discussion one bit.
man, did you even read what i cited? i was confirming that i had said the exact same thing on that topic as you did (and i did it again here above) and now you're complaining that we seemingly agree on something? can you ever be satisfied? ;)
80b9edca1c11ec8118ab30451af9c1d492770c90
> practices" just because they aren't interested (yes, Linus codified
> that, but it is more a stating of common practice than a decree) [...]
80b9edca1c11ec8118ab30451af9c1d492770c90
in general, it seems that you're arguing about something different (a strawman, as i never stated any of this): that kernel developers figure out whether a commit has a security impact or not. that's clearly neither their job nor competence, so i'm not sure why you keep raising this red herring. what i've been always talking about is that *if* they know that a commit fixes some security issue then they say so in the commit. do you understand the difference?
80b9edca1c11ec8118ab30451af9c1d492770c90
> lead to all kinds of mud slinging ("They should have known!");
> relevant" set of patches and much moaning when they get pwned.
> turn out misleading.
> job, or none at all, than a (less than) half-assed one.