| |||||||||||||
Long-lived security holesLong-lived security holesPosted Jun 24, 2004 18:28 UTC (Thu) by pimlott (guest, #1535)In reply to: Long-lived security holes by wichert Parent article: Long-lived security holes It's a rat's nest. The best a distributor is likely to be able to do is say, if you're running a "pristine" instance of our OS, with no local or third-party software, here is your risk from untargeted attacks. And even then it is pretty hard to audit all the ways a piece of code could be used (do you consider every application that uses libpng and how it might be an attack vector?). We've been very wrong before about the security implications of bugs. With local software (or even local configuration) added to the mix, the best you can say is that this code is probably not a risk, unless you're using it in a way we didn't think about. If someone is (or may be) targeting you, a widely-applicable risk assesment is basically useless. You have to figure out how much it would cost to get you, which almost certainly involves local factors (such as people). A lot of users do use mostly-pristine distributions, and are not targeted by attackers willing to spend much on them (of course, who really knows if he's targeted?), so maybe a risk assessment aimed at them (and clearly labeled as aimed at them) could work. But I fear that after the first "low severity" bug gets widely exploited, people won't have much faith in the rating. I would much rather see aggressive (but careful) bug fixing and timely, fully automatic updates for most users, so they don't even have to think about severity. Frankly, the most useful information for sophisticated users would be more specifics about the vulnerability and how it can be exploited. Many advisories are disturbingly vague.
(Log in to post comments)
|
|||||||||||||