[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20120121120814.GB10593@openwall.com>
Date: Sat, 21 Jan 2012 16:08:14 +0400
From: Solar Designer <solar@...nwall.com>
To: "Samuel J. Greear" <sjg@...sjg.com>
Cc: security@...gonflybsd.org, oss-security@...ts.openwall.com
Subject: Re: weird crypt-sha* in DragonFly BSD
On Fri, Jan 20, 2012 at 12:22:51PM -0700, Samuel J. Greear wrote:
> I saw this, my preference would be to get rid of all uses of alloca() and
> use malloc(), ...
I thought of this some more and I'm afraid that this change would not
bring us much closer to fully solving the problem. malloc() may fail,
which we will need to handle somehow. If we agree upon the desired
behavior of crypt() on transient errors, then we can just as well
continue using alloca() and simply treat allocation attempts larger than
a certain size as errors.
Well, with malloc() we can have this size limit larger than with
alloca(), especially if we try to make sure that we don't cross a guard
page (so with alloca() we'd have to use a limit of like 2 KB then).
On the other hand, if we permit very long passwords to be passed to the
SHA-crypt algorithm (and the specific service does not introduce its own
limit), we also permit attackers to consume excessive amounts of CPU
time per crypt() call - orders of magnitude more than what the sysadmin
had intended (for typical password lengths). So maybe 2 KB is a
reasonable limit to impose at this level anyway (whereas services should
use lower limits).
Alexander
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.
