A /proc/PID/mem vulnerability
A /proc/PID/mem vulnerability
Posted Jan 26, 2012 14:11 UTC (Thu) by PaXTeam (guest, #24616)In reply to: A /proc/PID/mem vulnerability by rswarbrick
Parent article: A /proc/PID/mem vulnerability
> (since you pretty much have to reboot).
well, there is ksplice...
> 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.
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
> a "OOH LOOK, THIS IS FOR HAXXORS" message
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 ?
Posted Jan 26, 2012 20:06 UTC (Thu)
by vonbrand (subscriber, #4458)
[Link] (2 responses)
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.
Posted Jan 26, 2012 22:34 UTC (Thu)
by PaXTeam (guest, #24616)
[Link] (1 responses)
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 ;).
Posted Jan 26, 2012 23:01 UTC (Thu)
by PaXTeam (guest, #24616)
[Link]
err, i obviously meant 'who do exactly the opposite' ;).
A /proc/PID/mem vulnerability
A /proc/PID/mem vulnerability
> same as "there is an expoit out there for each and every security bug."
> security impact or just keep it quiet is the better course of action.
A /proc/PID/mem vulnerability