Path: csiph.com!goblin3!goblin.stu.neva.ru!news.misty.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end
From: albert@cherry.spenarnc.xs4all.nl (Albert van der Horst)
Newsgroups: comp.compilers
Subject: Re: Language standards vs. implementation, was Re: A right alternative to IEEE-754's format
Date: Sat, 5 May 2018 20:28:34 +0200 (CEST)
Organization: A poorly-installed InterNetNews site
Lines: 57
Sender: news@iecc.com
Approved: comp.compilers@iecc.com
Message-ID: <18-05-005@comp.compilers>
References: <0d4dc7f8-1819-43e5-8082-6ff7aee5f41b@googlegroups.com> <18-04-018@comp.compilers> <18-04-033@comp.compilers> <18-04-044@comp.compilers>
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="60116"; mail-complaints-to="abuse@iecc.com"
Keywords: design, optimize, errors
Posted-Date: 12 May 2018 13:07:02 EDT
X-submission-address: compilers@iecc.com
X-moderator-address: compilers-request@iecc.com
X-FAQ-and-archives: http://compilers.iecc.com
Xref: csiph.com comp.compilers:2093

In article <18-04-044@comp.compilers>, Martin Ward  <martin@gkc.org.uk> wrote:

[ discussing undefined behavior in C ]

>Gcc may optimize out tests for buffer overflows
>because of integer overflows:
>
>https://lwn.net/Articles/278137/
>
>Quote:
>
>     if (buffer + len >= buffer_end)
>       die_a_gory_death("len is out of range\n");
>
>Here, the programmer is trying to ensure that len (which might come from
>an untrusted source) fits within the range of buffer. There is a
>problem, though, in that if len is very large, the addition could cause
>an overflow, yielding a pointer value which is less than buffer. So a
>more diligent programmer might check for that case by changing the code
>to read:
>
>     if (buffer + len >= buffer_end || buffer + len < buffer)
>       loud_screaming_panic("len is out of range\n");
>

The diligent programmer gets nervous as he sees "buffer[len]" in his
code and realises that that may lead to problems if len is out of
range.
So he adds code of the sort
    &buffer[len] >= buffer_end                 &buffer[len] <buffer
He looks at this code and doesn't get nervous!
It looks more like a complete moron than a diligent programmer.

The reasonable solution is of course
   if ( len < 0 || len > sizeof(buffer) )
       panic("security breach: attempted out of buffer processing");

That makes perfect sense and will not be thrown out by any compiler.

>This code should catch all cases; ensuring that len is within range.
>There is only one little problem: recent versions of GCC will optimize
>out the second test (returning the if statement to the first form shown
>above), making overflows possible again. So any code which relies upon
>this kind of test may, in fact, become vulnerable to a buffer overflow
>attack.

There is an other problem, some one tries to break you program and
you try to execute the code without warning the autorities.

If GCC smokes out code like that, they have my blessing.

<SNIP>

--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst