| |||||||||||||
A /proc/PID/mem vulnerabilityA /proc/PID/mem vulnerabilityPosted Jan 26, 2012 10:28 UTC (Thu) by rswarbrick (subscriber, #47560)Parent article: A /proc/PID/mem vulnerability
... Torvalds is treating security bugs differently. They are no longer "just bugs" because some of the details of the bug are being purposely omitted. That may make it difficult for "black hats"—though it would be somewhat surprising if it did—but it definitely makes it more difficult for those who are trying to keep Linux users secure. Well, kernels are more painful to upgrade than most other software (since you pretty much have to reboot). As such, there's always going to be a bigger window between patches going out and machines being patched. If someone is malicious and knows about what's going on in advance, you're stuffed whatever Linus chooses to write in the commit message. However, if someone malicious is grepping through kernel commits for "suid", "privilege escalation" or the like, it doesn't make much sense to point out bugs for them. There are a *lot* of patches going into the kernel each day: without a "OOH LOOK, THIS IS FOR HAXXORS" message, I find it hard to believe that staring at kernel commits is a good way to find vulnerabilities.
(Log in to post comments)
A /proc/PID/mem vulnerability Posted Jan 26, 2012 14:11 UTC (Thu) by PaXTeam (subscriber, #24616) [Link]
> Well, kernels are more painful to upgrade than most other software
> (since you pretty much have to reboot).
well, there is ksplice...
> If someone is malicious and knows about what's going on in advance,
blackhats don't work based off the fix, they work based on the original commit that *introduces* the bug, weeks/months/years before the fix happens (if it happens at all, there's always 0-day out there). and for the people who do work based off the fix, this very bug and its fix is proof that no amount of coverup helps: there're already at least 4 public and 2 private exploits out there for it that i know of. what was the point of the coverup then? it most definitely failed to achieve the goal of "try not to help black hats".
> There are a *lot* of patches going into the kernel each day: without
at this point *any* commit from Linus directly referencing a non-public message is an immediate red flag. he has achieved the exact opposite he wished for.
> [...]I find it hard to believe that staring at kernel commits is a good way to find vulnerabilities.
(un)fortunately, blackhats don't share your belief. remember http://seclists.org/fulldisclosure/2010/Sep/268 ?
A /proc/PID/mem vulnerability Posted Jan 26, 2012 20:06 UTC (Thu) by vonbrand (subscriber, #4458) [Link] Oh, come on. "There is a exploit out for a widely-discussed security bug" is not the same as "there is an expoit out there for each and every security bug." As long as you can't reasonably know if to publish any hint of possible security impact or just keep it quiet is the better course of action.
A /proc/PID/mem vulnerability Posted Jan 26, 2012 22:34 UTC (Thu) by PaXTeam (subscriber, #24616) [Link]
> "There is a exploit out for a widely-discussed security bug" is not the
> same as "there is an expoit out there for each and every security bug."
strawman and also an irrelevant tautology.
> As long as you can't reasonably know if to publish any hint of possible
real life says that you can reasonably know that there's an entire industry, both visible and invisible, out there that is watching and writing exploits as soon as they can get their hands on a bug, be that at bug commit time or later (the sooner the better as the value of 0-day beats anything else).
on the other hand the best course of action for users of said buggy code to save themselves is to fix the bugs (yes, i'm stating this myself despite being deeply involved in intrusion prevention technologies). for that they need to know about them, simple as that. covering up security fixes is diametrically opposite to that goal as it makes it much harder for users to reverse engineer the information from the commits whereas said industry has the brainpower to see through these silly attempts (as i said above, commits from Linus and certain other individuals draw immediate attention these days, witness what happened to this /proc/pid/mem bug).
btw, if you think keeping quiet about security impact information is the right course of action, what do you think about companies (linux vendors included) who do exactly that?
PS: i'm glad you stopped doubting that there *is* a coverup. you've come a long a way ;).
A /proc/PID/mem vulnerability Posted Jan 26, 2012 23:01 UTC (Thu) by PaXTeam (subscriber, #24616) [Link]
> [...]who do exactly that?
err, i obviously meant 'who do exactly the opposite' ;).
|
|||||||||||||