From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1474 Path: news.gmane.org!not-for-mail From: Solar Designer Newsgroups: gmane.linux.lib.musl.general Subject: Re: crypt* files in crypt directory Date: Thu, 9 Aug 2012 05:51:04 +0400 Message-ID: <20120809015104.GA24515@openwall.com> 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 1344477068 30341 80.91.229.3 (9 Aug 2012 01:51:08 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 9 Aug 2012 01:51:08 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1475-gllmg-musl=m.gmane.org@lists.openwall.com Thu Aug 09 03:51:08 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 1SzHtz-0006Lu-7x for gllmg-musl@plane.gmane.org; Thu, 09 Aug 2012 03:51:07 +0200 Original-Received: (qmail 1412 invoked by uid 550); 9 Aug 2012 01:51:06 -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 1401 invoked from network); 9 Aug 2012 01:51:06 -0000 Content-Disposition: inline In-Reply-To: <20120808130622.GJ27715@brightrain.aerifal.cx> User-Agent: Mutt/1.4.2.3i Xref: news.gmane.org gmane.linux.lib.musl.general:1474 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. Yes, but only after having compromised group shadow. If a user does compromise group shadow, I'd appreciate learning of that - even if via being DoS'ed. ;-) Direct access to tcb shadow files should not be available for other reasons as well, including password policy enforcement and not assisting in exploitation of read-any-file vulnerabilities e.g. in web apps into remote shell access. If you implement tcb differently, then _that_ should be fixed. It is not a musl issue since musl does not set file permissions (nor is it supposed to). Whatever you use to create/update the files may need to be fixed. > 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. That's not good. BTW, the extended DES-based hashes that are already supported in musl allow for variable iteration counts encoded along with hashes too, and that's the way it should be. > 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. I agree that allowing for the DoS without the attacker having to find and exploit a vulnerability first is not acceptable, but the issue is not in crypt_blowfish nor in musl per se. Our tcb suite as released by Openwall does not provide direct access to those files. It protects them with group shadow. Do you have any released (rather than private use) software that makes tcb shadow files user-writable without requiring any group privileges? If not, then this issue should not affect musl development in any way, and you may fix whatever you use privately as a separate step. Alexander