US-CERT Vulnerability Note VU#162289

[Robert C. Seacord]

Gerald,

Comments below.
>>  My
>> understanding is that it shouldn't, because the real issue here is
>> pointer arithmetic and the resulting type should always be a pointer.
>>     
>
> I'm not sure what you mean by that last statement.
>   
my understanding of the C99 standard is that adding an integer and a 
pointer always results in a pointer.  i'm not a compiler expert, but i 
would think that the rules that apply to adding a pointer and an integer 
of any signedness would be the same, and are different from the rules 
that would apply to adding signed or unsigned integers. 

VU#162289 only applies to pointer arithmetic.  I need to go back and 
check, but I don't believe the signedness of the integer involved is a 
factor.
> I think we've already established that those tests that would
> print "BUG" aren't actually finding bugs in the compiler.
Sorry about the string literal "Bug".  This was just an artifact from 
the original program.  I should have changed it to "optimization detected".
>  It
> is not correct to assume that adding a value to a char pointer
> will wrap around in the same way as if you added a value to an
> unsigned number. 
i think this depends on what you mean by "value".
> You also cannot assume that adding a value to
> a signed number will cause it to wrap. (GCC had optimized away
> checks for the latter already. There are now reports that many
> other compilers may optimize away both tests.)
>   
ditto.
> Are we in agreement on this? The fact that your example prints
> "BUG!" seems to imply that it is invalid to optimize away these
> tests, which it isn't.
>   
i agree that the optimization is allowed by C99.  i think this is a 
quality of implementation issue,  and that it would be preferable for 
gcc to emphasize security over performance, as might be expected.
> I was under the impression that the only issue here is that
> there is a change in behavior. That's a very fine line to walk
> when many other compilers do this. In fact, you can run into
> the same change of behavior when switching from unoptimized
> debug versions to optimized release versions. Recommending not
> using a recent GCC as a possible remedy is dangerous (some
> would probably say irresponsible).
this was only one of several solutions listed, and not the first one 
listed.  You will see that the Compliant Solution provided in the 
referenced secure coding rule:
ARR38-C. Do not add or subtract an integer to a pointer if the resulting 
value does not refer to an element within the array 
<https://www.securecoding.cert.org/confluence/display/seccode/ARR38-C.+Do+not+add+or+subtract+an+integer+to+a+pointer+if+the+resulting+value+does+not+refer+to+an+element+within+the+array>
recommends modifying the code.
>  What you really mean is,
> "Use an older GCC or some other compiler that is known not to
> take advantage of this optimization."
>   
i think we mean what we say, which is "*Avoid newer versions of gcc" and 
*"avoiding the use of gcc versions 4.2 and later."  i don't see any 
verbiage that says "use a different compiler".
> P.S. Has anyone checked how far back in the line of Microsoft
> compilers you have to go to before they don't do this same
> optimization 
our tests shows that the 2005 version of the compiler does not perform 
this optimization.  i have not yet tested a newer version of the compiler.

rCs