[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201111162132.45745.sgrubb@redhat.com>
Date: Wed, 16 Nov 2011 21:32:45 -0500
From: Steve Grubb <sgrubb@...hat.com>
To: oss-security@...ts.openwall.com
Cc: Solar Designer <solar@...nwall.com>
Subject: Re: glibc crypt(3), crypt_r(3), PHP crypt() may use alloca()
On Wednesday, November 16, 2011 09:22:17 PM Solar Designer wrote:
> On Tue, Nov 15, 2011 at 06:13:24AM +0400, Solar Designer wrote:
> > Alternatively, crypt(3) and crypt_r(3) (and the reference code for
> > SHA-crypt?) could refuse to work on overly long key or/and salt strings,
> > but then the question is what they should do on error.
>
> Here's another related option:
>
> if (strlen(key) > 100000 || strlen(salt) > 100000)
> abort();
>
> (or something like this). Ridiculous? Sure, but it's better than
> overwriting another thread's stack or the heap with somewhat higher
> lengths, and 100001 chars is not a more reasonable password length to
> support than, say, 2 million or 10 million (typical thread stack sizes).
>
> So if we can't decide on a proper fix (does anyone besides me even
> care?), something as trivial as the above would be an improvement.
raise(SIGKILL) might be better because abort requests a core dump and you are in
crypto code.
-Steve
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
