Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.compilers > #2093
| 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 | 2018-05-05 20:28 +0200 |
| Organization | A poorly-installed InterNetNews site |
| Message-ID | <18-05-005@comp.compilers> (permalink) |
| References | <0d4dc7f8-1819-43e5-8082-6ff7aee5f41b@googlegroups.com> <18-04-018@comp.compilers> <18-04-033@comp.compilers> <18-04-044@comp.compilers> |
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
Back to comp.compilers | Previous | Next — Previous in thread | Find similar
Language standards vs. implementation, was Re: A right alternative to IEEE-754's format "Walter Banks" <walter@bytecraft.com> - 2018-04-10 11:07 -0400
Re: Language standards vs. implementation, was Re: A right alternative to IEEE-754's format Gene Wirchenko <genew@telus.net> - 2018-04-10 11:07 -0700
Re: Language standards vs. implementation, was Re: A right alternative to IEEE-754's format Martin Ward <martin@gkc.org.uk> - 2018-04-12 09:52 +0100
Re: Language standards vs. implementation, was Re: A right alternative to IEEE-754's format albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2018-05-05 20:28 +0200
csiph-web