[19207] in Kerberos_V5_Development
Re: C99 Features
daemon@ATHENA.MIT.EDU (Nathaniel McCallum)
Wed Jun 17 15:27:56 2015
Message-ID: <1434569260.17641.1.camel@redhat.com>
From: Nathaniel McCallum <npmccallum@redhat.com>
To: Greg Hudson <ghudson@mit.edu>, Danilo Almeida <dalmeida@mit.edu>,
"'krbdev@mit.edu'" <krbdev@mit.edu>
Date: Wed, 17 Jun 2015 15:27:40 -0400
In-Reply-To: <5581C06B.9000703@mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
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.
>
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
