Nonsense. This is trivial stuff. [LWN.net]

Nonsense. This is trivial stuff.

Posted Jul 18, 2009 15:59 UTC (Sat) by pflugstad (subscriber, #224)
In reply to: Nonsense. This is trivial stuff. by mikov
Parent article: Linux 2.6.30 exploit posted

I basically agree - the bug is obvious for anyone doing C coding. I actually would have expected the various static code analysis tools (Stanford Checker, Sparse, etc) to catch this kind of stuff.

But the other side of the discussion is that this bug is unexploitable if GCC had not optimized away the null check.

(Log in to post comments)

Nonsense. This is trivial stuff.

Posted Jul 18, 2009 16:14 UTC (Sat) by mikov (subscriber, #33179) [Link]

But the other side of the discussion is that this bug is unexploitable if GCC had not optimized away the null check.

Yes. I wonder what kind of process lead to finding this bug... Looking at the assembler output? Discovering it is very impressive. Brad really deserves a lot of praise.

But still, this is not different than any exploit which relies on knowledge of how a specific compiler works - e.g. how it places variables in the stack, and so on. It is exactly the same thing if you think about it. But nobody would claim that GCC has a bug because it placed the return address in the stack where it could be overwritten.

Brad keeps claiming that the important thing is that on the surface this bug doesn't present as security related. While that is true, nobody can predict how several bugs will interact. In my book any crashing bug is potentially security related until proven otherwise.

Nonsense. This is trivial stuff.

Posted Jul 19, 2009 3:27 UTC (Sun) by gmaxwell (subscriber, #30048) [Link]

Eh, if I were betting I'd suggest that this was found by running a simple static analysis tool that warns you of the check after the dereference. Many will.

No fancy examination of the assembly was required to find a bug which justified analysis for exploitability. The exact compiler behaviour was only needed for the creation of the exploit, which is pretty usual, not the finding of the bug.