C99 Features

[Nathaniel McCallum]

On Wed, 2015-06-17 at 14:46 -0400, Greg Hudson wrote:
> On 06/17/2015 02:32 PM, Nathaniel McCallum wrote:
> > You can't check for allocation failure on most operating systems' 
> > heap
> > allocation these days.
> 
> MIT krb5 does not assume that it is operating in such an environment, 
> or
> we could simplify an awful lot of code.  I've gently brought this up
> once or twice and the consensus has been that we should continue 
> trying
> to rigorously handle malloc failures, even if not all environments 
> make
> such checks useful.

FTR, I was not suggesting we should ignore failures. We shouldn't. I
only meant that on many platforms such handling is not likely to catch
an actual OOM condition.

> A more nuanced argument is that you can't check for the success of 
> stack
> allocation even when allocating fixed-sized automatic variables. 
>  When
> an attacker can control stack use without reasonable bounds, that
> creates a DOS vector, whether the stack overrun is due to recursion 
> or
> VLAs.  The same is true for heap use without reasonable bound, 
> although
> in a threaded environment the reasonable bound for stack use has to 
> be
> significantly lower than for heap use.
> 
> In a threaded environment, VLAs of attacker-controlled size, which 
> are
> accessed in non-sequential order, could cause more significant 
> security
> issues than a DOS; you might skip over the guard page and overwrite a
> different thread's stack.  The same is theoretically possible with
> fixed-sized automatic variables, but there would have to be a lot of
> them (or a few very large ones).
> 
> > But with careful use, there is a lot of benefit.
> 
> I agree with the conclusion.
>