[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130127175444.GA5329@openwall.com>
Date: Sun, 27 Jan 2013 21:54:44 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: getting rid of alloca() and variable-sized arrays (was: krb5-23 or wow bug (or what?))
On Sun, Jan 27, 2013 at 06:43:10PM +0100, magnum wrote:
> For portability reasons, or some other reason as well?
Also for reliability and (maybe later) for security reasons. (I said
"maybe later" because JtR -jumbo is insecure when faced with untrusted
input now, and it is unclear if we'll ever fix that, although it'd be
nice to do so. We might instead document the risk - in fact, we should
do that for next -jumbo.)
alloca() may bring the stack pointer outside of the stack area, and into
some other area such as the heap.
> There are also some uses of variable-size arrays,
These are just as bad for security and reliability, and are even less
portable.
> which boils down to the same thing. These are harder to just grep out but I can easily list them trying to do OMP with Apple's gcc :)
>
> How do we get rid of them? Using stack arrays of maximum size that will ever be needed?
We'll need to review and revise the code on a case by case basis.
When there's a clear maximum size and it's small enough, we can use
fixed-size arrays on the stack (and do proper bounds checking).
In other cases, we can allocate dynamic memory and MEM_FREE() it before
the function returns.
I suspect that there are also cases where the allocation can be avoided
altogether without complicating the code much (or even simplifying it).
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
