Re: Security vulernarability or security feature? VU#162289

[Ralph Loader <suckfish at ihug dot co dot nz>]

> Thanks for your further explanation of this optimization.  Here is
> what I understand.  Please correct me if I am wrong on any of these
> points:

Points 1...5, no quibble.

Now that you appear to admit that the issue is wrap-around and not a
length-check, this raises the question of whether there is any security
problem with the optimisation at all, even for badly written
applications.

Length-checks are directly related to security, because they protect
against buffer-overruns which are often directly exploited by attackers.

It is much harder to see how reliance on wrap-around could contribute to
the security of an application.  Where pointer arithmetic is invalid,
and this is carried out in context where security matters, I would
expect it to not matter whether or not invalid arithmetic used
wrap-around or not.

Of course, for just about any compiler feature, it is probably possible
to contrive badly written code that is exploitably insecure with that
feature, and --- purely by chance --- not exploitable without the
feature.

But it is hard to see what reason you have for picking on this
particular feature of this particular compiler.

> 6.  The Overview of VU#162289 states "Some C compilers optimize away 
> pointer arithmetic overflow tests that depend on undefined behavior 
> without providing a diagnostic (a warning)." 
> 
> The point being is that we are not objecting to the optimization, we
> are objecting to the lack of any diagnostic.

Yes, you have dramatically improved the wording from previous
versions.  However, you still say:

  "avoid using compiler implementations that perform the offending
   optimization"

without any warning that in some cases the "offending" optimization may
be covering-up a security issues, and that avoiding the optimization
without fixing the underlying problems in the application may actually
be harmful.  (In fact, as far as I can, more likely to be harmful than
helpful).

I must admit, given the problems that have been identified with the
advisory (how many versions has it been through?), I would be far
happier if you subjected it to independent third-party expert review,
and withdrew the advisory until that is completed in a satisfactory
manner (rather than repeatedly incrementally tweaks).

Ralph.

> 
> Because both examples could benefit from being rewritten (this is
> what the compiler is doing) I don't see the harm in issuing a
> diagnostic in both cases.
> 
> rCs
> 
> > Robert,
> >
> > You have failed to answer my original question, and I think have
> > failed to understand the point of the example.
> >
> > The example shows that what you are claiming is a vulnerability in
> > 162289 is in fact a security feature.
> >
> >   
> >>   that removes checks pointer arithmetic wrapping.
> >>     
> >
> > Just to be 100% clear, the optimisation I gave you an example of,
> > and which you think is "pretty cool" is precisely the same
> > optimisation you are complaining about in 162289, specifically, a
> > pointer value may be canceled from both sides of a comparison.
> >
> > This is slightly confused by the fact that in the 162289 example,
> > two optimisations take place [gcc gurus please correct if I am
> > wrong]:
> >
> > (a) a pointer value is canceled from both sides of a comparison,
> > changing (buf+len<buf) to (len<0).  This is what changes the
> > observable behaviour of the code, and is what the debate is about.
> >
> > (b) in the example given in 162289, (len<0) can then be evaluated at
> > compile time, removing the test entirely.   This does not change the
> > runtime behaviour of the code an is completely irrelevant.
> >
> > To make it even clearer, we can disable optimisation (b) while
> > leaving optimisation (a), by making 'len' volatile:
> >
> > int foo (char * buf)
> > {
> >     volatile int len = 1<<30;
> >     if (buf+len < buf)
> > 	return 1;
> >     else
> >         return 0;
> > }
> >
> > gcc then generates:
> >
> > foo:
> > 	subl	$16, %esp
> > 	movl	$1073741824, 12(%esp)
> > 	movl	12(%esp), %eax
> > 	addl	$16, %esp
> > 	shrl	$31, %eax
> > 	ret
> >
> > This has not completely removed the test, but when executed, it will
> > still always return 0, giving precisely the same run-time behaviour
> > as without the 'volatile'.
> >
> > To re-iterate:
> >
> > (a) Why does Cert advise against an optimisation that, under
> > the right circumstances, can remove examples of a historically
> > significant class of security holes.
> >
> > (b) The example you claim is a length check in 162289 is not a
> > length check and does not support the conclusions you draw from it.
> >
> > Ralph.
> >
> >
> >   
> >>  The optimization
> >> doesn't actually eliminate the wrapping behavior; this still
> >> occurs. It does, however, eliminate certain kinds of checks (that
> >> depend upon undefined behavior).
> >>
> >> Thanks,
> >> rCs
> >>     
> >>     
>