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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ