Re: weird crypt-sha* in DragonFly BSD

[Solar Designer <solar () openwall com>]

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