Joe Buck wrote: > You appear to mistakenly believe that wrapping around on overflow is a > more secure option. It might be, but it usually is not. There are many > CERT security flaws involving integer overflow; the fact that they are > security bugs has nothing to do with the way gcc generates code, as the > "wrapv" output is insecure.
I am well aware of the fact that most intever overflows reported are a case of the programmer completely ignoring the possibility of an overflow. What I'm afraid of is that there are probably enough programmers out there clever enough to be aware of the fact that overflow exists, but blindly assuming a defined semantics for them. Of course the checks those people write are wrong. But it is a systematic bug that leads to exploitable situations in code. The best way from a security point of view to deal with the risk would be to prevent the whole bug class from happening, by changing the compiler. However, I also know that there is a certain tradeoff to be made, a cost in performance for the case of default(!) optimizer settings. -Wstrict-overflow will help making a call here. > AFAIK, "overflow doesn't occur" assumptions occur in currently shipping > compilers mainly in expression simplification (see previous examples in > this thread) and loop unrolling, and in either case application codes are > almost always written with a blithe assumption that overflow does not > occur. I must say I have a hard time creating an argument against the given examples from a security point of view. But there is no clear cut between innocent and a vulnerability waiting to be discovered, undefined semantics can always lead to subtle bugs. The case is clear when an if branch is folded away, because some comparison is folded that would not have been under twos-complement semantics. This is a pattern that probably doesn't happen all that much in code out there, except in post-facto overflow checking. Regards, Andreas
