On Wed, Oct 30, 2013 at 12:54:12PM +0100, Florian Weimer wrote:
> On 10/26/2013 09:29 PM, Ondřej Bílka wrote:
> >Hi, as I brainstormed how prevent possible overflows in memory allocation I
> >came with heretic idea:
> >
> >For gcc -D_FORTIFY_SOURCE=2 we expand all multiplication with size_t
> >type by one that checks for integer overflow and aborts on it. This
> >would prevent most overflow at cost of breaking some legitimate
> >applications that use multiplication in clever way.
>
> Many of the critical multiplications are of the for n * sizeof(T),
> where n is of type int or unsigned (or derived from input of that
> type), so just switching to a 64 bit architecture papers over many
> issues. Obviously, there are some remaining issues (computation in
> int/unsigned and implicit cast to size_t at the end), but those
> won't be caught by trapping size_t arithmetic, either. Aborting on
> a negative-value-to-size_t cast doesn't help because those are
> precisely the cases that are not exploitable (beyond DoS).
>
Problem here is that gcc does not warn around truncation. One can do
calculations correctly but then pass it to
int foo (char *x, int size)
This is difficult to track as foo header was written in time of 32-bit.
> But do we actually care about integer overflows? Java suggests that
> it's possible to have memory safety without integer overflows, and I
> think improved memory safety is ultimately the goal.
>
> It would still be nice to have a way to write code like
>
> if (a + b < c) {
When there is just unsigned addition and multiplication you could just
saturate, see sibling thread.
A problem is that these changes need user cooperation.
> and get an infinite-precision result (GNAT already has a mode for
> that). But only very low-level code should have to use that, and
> supporting shifts without memory allocation might be difficult.
> Aborting on overflow will not help the programmer with writing such
> checks.
>
> --
> Florian Weimer / Red Hat Product Security Team
