| |||||||||||||
A Tale of Two Pwnies (Part 1)A Tale of Two Pwnies (Part 1)Posted May 23, 2012 6:44 UTC (Wed) by JoeBuck (subscriber, #2330)In reply to: A Tale of Two Pwnies (Part 1) by bradfitz Parent article: A Tale of Two Pwnies (Part 1) Yes, it goes to show that even the most minor security bugs can't be ignored (as in: we can ignore the hole in sandbox A, because it only gets you into sandbox B so you're still contained). Many exploits have at least two steps: first trick a user into running a command as that user, then escalate using some local root exploit. But six steps is very impressive, and helps to show the limits of multi-layer security: you only have to break in one level at a time.
(Log in to post comments)
A Tale of Two Pwnies (Part 1) Posted May 23, 2012 8:04 UTC (Wed) by job (guest, #670) [Link]
Also, you get a glimpse of just how complicated a web browser is these days. Seriously, downloading insecure machine code and just executing it? Downloading shaders into the GPU?
Piling complex stuff on top of each other and trying to get it secure sounds like building a fail safe space shuttle. No matter how hard you try there's always going to be some combination of valves that gets you an unexpected outcome.
Mindblowing exploit though. Seriously humbling. There is nothing to make me doubt my own competence more than reading about what is likely some insanely hard work by a complete genius.
A Tale of Two Pwnies (Part 1) Posted May 23, 2012 9:40 UTC (Wed) by epa (subscriber, #39769) [Link] Yes, it goes to show that even the most minor security bugs can't be ignoredAmen to that. And let's hope everyone remembers this example next time we get more nonsense arguments about how security bugs aren't special, and can be treated the same way as any other bug, etc etc.
A Tale of Two Pwnies (Part 1) Posted May 23, 2012 10:19 UTC (Wed) by ms (subscriber, #41272) [Link]
Is not the point of this that every bug, no matter how innocuous it might appear has the potential to be used as part of a wider sequence of bugs to build security exploits? In which case every bug is potentially a security bug. Maybe we're just strenuously agreeing here...?
A Tale of Two Pwnies (Part 1) Posted May 23, 2012 10:40 UTC (Wed) by mpr22 (subscriber, #60784) [Link] All bugs in programs exposed to untrustworthy input are security bugs unless provable otherwise.
Trustworthy input? Posted May 23, 2012 12:00 UTC (Wed) by man_ls (subscriber, #15091) [Link] Your statement is harder than it looks: all input is untrustworthy unless proved otherwise.
Trustworthy input? Posted May 23, 2012 12:16 UTC (Wed) by mpr22 (subscriber, #60784) [Link] Your statement regarding the trustworthiness of input is a true and useful counterpart to my statement about bugs; thank you.
Trustworthy input? Posted May 25, 2012 10:26 UTC (Fri) by bricef (guest, #80336) [Link]
Conclusion: All bugs are security bugs unless your program takes no input.
Trustworthy input? Posted May 25, 2012 10:42 UTC (Fri) by man_ls (subscriber, #15091) [Link] A heuristic refinement of your statement would be: confine processing of user input to a specific module inside your program, and treat bugs in that module as security bugs. The remaining bugs should have lower priority (but they might also be security bugs if the input module doesn't do a good job).
A Tale of Two Pwnies (Part 1) Posted May 23, 2012 11:21 UTC (Wed) by ovitters (subscriber, #27950) [Link]
You don't always know if something is a security bug. Something which might just fix a compiler warning (unsigned comparison) might actually result in an exploit.
As long as you cannot easily tell that something is a security bug, you should focus on all bugs. Because in all those normal bugs might lie various security bugs as well.
|
|||||||||||||