Re: Real-World Impact of Hash DoS in Lua

[William Ahern <william@...>]

On Fri, Jan 20, 2012 at 07:46:39PM +0900, Rob Kendrick wrote:
> On Thu, Jan 19, 2012 at 10:11:11AM -0800, William Ahern wrote:
> > On Thu, Jan 19, 2012 at 01:47:16PM +0000, John Graham-Cumming wrote:
> > <snip>
> > > 1. Randomize the hash seed.  In the patch I developed I generate a new
> > > unsigned int using rand() and store it in the global state and then use it
> > > to initialize the hash value instead of the string length (as is done
> > > today).
> > 
> > rand() is anything but random. Likewise for random(). They're extremely
> > predictable. You're going to have to go platform specific. For OpenBSD or OS
> > X, for example, use arc4random(). For Linux use sysctl() and mib[] = {
> > CTL_KERN, KERN_RANDOM, RANDOM_UUID }.
> 
> How about use the pointer to one of Lua's symbols?  If you care about
> security, you'll have address space randomisation.  If you don't have
> address space randomisation, you clearly don't care about security :)

You'd have to do it for multiple symbols, since the placement of each symbol
is going to be in a much narrower window then 32-bits.

I don't think ALSR helps with statically linked apps, does it?

> > Trying to use /dev random devices is broken for security conscious
> > applications that have already called chroot().
> 
> Why?  I suppose it means that anybody who broken into the chroot can
> make /dev/random block, but is that much of an issue when you also have
> /dev/urandom?

Ideally you want to chroot to an empty directory, without write permissions,
and without the ability to use devices (e.g. nodev mount option). Those
things aren't redundant when the purpose is to reduce the kernel attack
surface.