This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Signed int overflow behaviour in the security context

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]