From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1469 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: crypt* files in crypt directory Date: Wed, 8 Aug 2012 14:10:26 -0400 Message-ID: <20120808181026.GK27715@brightrain.aerifal.cx> References: <20120808022421.GE27715@brightrain.aerifal.cx> <20120808044235.GA22470@openwall.com> <20120808075233.GJ30810@port70.net> <20120808130622.GJ27715@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1344449391 20222 80.91.229.3 (8 Aug 2012 18:09:51 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 8 Aug 2012 18:09:51 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1470-gllmg-musl=m.gmane.org@lists.openwall.com Wed Aug 08 20:09:51 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1SzAha-0005rA-DE for gllmg-musl@plane.gmane.org; Wed, 08 Aug 2012 20:09:50 +0200 Original-Received: (qmail 18282 invoked by uid 550); 8 Aug 2012 18:09:49 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 18272 invoked from network); 8 Aug 2012 18:09:48 -0000 Content-Disposition: inline In-Reply-To: <20120808130622.GJ27715@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:1469 Archived-At: On Wed, Aug 08, 2012 at 09:06:23AM -0400, Rich Felker wrote: > Actually this brings up a HUGE DoS vuln in blowfish crypt: with tcb > passwords, a malicious user can put a password with count=31 (it's > logarithmic, so this means 2^31) in their tcb shadow file. This will > cause a root-owned process to eat 100% cpu for hours if not days. > Perform a few simultaneous login attempts and the whole server becomes > unusable. > > I don't know how to solve it, but in musl I think we'll have to put a > low limit on count if we're going to support blowfish. Unfortunately I > don't see a good way to make it runtime configurable without > hard-coding additional non-standard config paths, but letting the DoS > bug slip in is not acceptable. OK, here's my proposed direction for a fix. I definitely don't want to be _unconditionally_ reading a config file for every crypt() call, since that would adversely affect even calls with sane iteration counts and perhaps dominate the run time or at least the cache thrashing. Instead, I propose we come up with a range of iteration counts that are "remotely sane" in the sense of taking (for example) less than 250ms on a very low-end system, and always allowing any count in this range. Initially we can just forbid higher counts, and later we can extend the code to probe some sort of configuration when the default limit is exceeded to see if there's a configuration extending the limit. On the other hand, for self-contained static binaries, it might be desirable the have the limit be configured into the binary. This could be achieved by making a weak symbol whose address is used as the limit, and then -Wl,--defsym=__crypt_iter_max=20 or similar could be used to configure it at link time. In any case, if the default limit is sufficiently large, I think we can get away without taking any action on the configurability right away.. Rich