> 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
> >>
> >>
>
