Security vulernarability or security feature? VU#162289

[Robert C. Seacord]

Ralph,

Comments below.
> 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.  
The original impetus for this came from a check in a sprint() function 
from Plan 9.  Because of the API, there was no way to test if the len 
was out of bounds, but the developers wanted to make sure they weren't 
wrapping the stack on some architectures that have their stacks in high 
memory.

It seems like a reasonable test to make, the code used to work, and they 
got burned on the silent change in behavior.
> But it is hard to see what reason you have for picking on this
> particular feature of this particular compiler.
>   
This may not have been the poster child issue to go after, but we were 
responding to the report.

What features of which compilers do you think we should be reporting on?
> Yes, you have dramatically improved the wording from previous
> versions.  However, you still say:
>
>   "avoid using compiler implementations that perform the offending
>    optimization"
>   
I agree this is worded badly, we'll correct this.
> I must admit, given the problems that have been identified with the
> advisory (how many versions has it been through?), 
we've only revised it once so far, but we'll change it as many times as 
we need to.
> I would be far
> happier if you subjected it to independent third-party expert review,
>   
we are an independent third party.  who else would we ask? 
> and withdrew the advisory until that is completed in a satisfactory
> manner (rather than repeatedly incrementally tweaks).
>   
withdrawing vulnerability notes (this is not an advisory that is emailed 
out) is not as good a solution as you might think, as this usually draws 
more attention to the vulnerability note than just about anything else 
you can do.

rCs