US-CERT Vulnerability Note VU#162289

[Mark Mitchell]

Robert C. Seacord wrote:

> Just because a program contains undefined behavior, does not mean that 
> it erroneous. It simply gives the compiler latitude with how to handle 
> the undefined behavior, while still conforming.

Actually, erroneous and undefined are approximately synonymous.

There are various categories of behavior not mandated by the standard. 
The standard identifies:

* implementation-defined behavior

unspecified behavior where each implementation documents how the choice 
is made

* unspecified behavior

behavior where this International Standard provides two or more 
possibilities and imposes no further requirements on which is chosen in 
any instance

* undefined behavior

behavior, upon use of a nonportable or erroneous program construct or of 
erroneous data, for which this International Standard imposes no 
requirements

And:

> Addition or subtraction of a pointer into, or just beyond, an array object and an integer type produces a result that does not point into, or just beyond, the same array object (6.5.6).

is undefined behavior.

This is the same class as using the value of an uninitialized variable, 
dividing by zero, or any other erroneous construct that cannot be 
diagnosed at compile-time.  From the point of view of the standard, your 
example of a "secure" program is no more portable than one that reads 
random uninitialized memory and depends on the result.

That said, the GCC developers have already implemented a warning option 
to warn about the case where optimizations are made on this basis.  I do 
not know if it is in -Wall or not.  I doubt it, because it would 
probably create far too many false positives.

Declaring that a compiler is "vulnerable" because it performs a valid 
optimization performed by most of the leading compilers is somewhat odd. 
  Declaring it vulnerable while not declaring those others to be 
vulnerable is unfair.  However, I do appreciate that issues in GCC is 
probably more important than issues in other compilers, given GCC's 
overwhelming popularity and the increasing degree to which vitally 
important software is built with GCC.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713