From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1479 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: crypt* files in crypt directory Date: Thu, 9 Aug 2012 01:48:04 -0400 Message-ID: <20120809054804.GO27715@brightrain.aerifal.cx> References: <20120808022421.GE27715@brightrain.aerifal.cx> <20120808044235.GA22470@openwall.com> <20120808075233.GJ30810@port70.net> <20120808130622.GJ27715@brightrain.aerifal.cx> <20120809015104.GA24515@openwall.com> <20120809032527.GN27715@brightrain.aerifal.cx> <20120809040432.GA24985@openwall.com> 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 1344491246 20531 80.91.229.3 (9 Aug 2012 05:47:26 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 9 Aug 2012 05:47:26 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1480-gllmg-musl=m.gmane.org@lists.openwall.com Thu Aug 09 07:47:26 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 1SzLag-0006YX-5c for gllmg-musl@plane.gmane.org; Thu, 09 Aug 2012 07:47:26 +0200 Original-Received: (qmail 15406 invoked by uid 550); 9 Aug 2012 05:47:25 -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 15395 invoked from network); 9 Aug 2012 05:47:24 -0000 Content-Disposition: inline In-Reply-To: <20120809040432.GA24985@openwall.com> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:1479 Archived-At: On Thu, Aug 09, 2012 at 08:04:32AM +0400, Solar Designer wrote: > On Wed, Aug 08, 2012 at 11:25:27PM -0400, Rich Felker wrote: > > On Thu, Aug 09, 2012 at 05:51:04AM +0400, Solar Designer wrote: > > > 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. ;-) > > I think I need to clarify that the above is my own preference and some > sysadmin's preference might be different. This is a reason why we deal > with whatever DoS attacks may be easily dealt with anyway - those with > non-regular files. > > For DoS via high iteration count, I see no good solution other than to > accept this as a possibility for when group shadow is compromised. Well it's also a possibility if you're using crypt to validate passwords where both the hash and password are provided by a third party. I think that's a major problem. I generally frown upon interfaces where the run time is non-obviously superlinear in the input size. I don't see any down-size to limiting the iteration count if the limit is reasonable. For instance if the limit were such that higher counts would take more than 1 second on a theoretical 50 GHz variant of a modern cpu (which is faster than a single core will EVER be able to get), there's no way they would be practical to use, and there's no sense in supporting them except to satisfy a fetish for "no arbitrary limits" even when it conflicts with security and robustness. This would at least ensure the function can't get stuck running for hours/days/weeks at a time. The hard part is putting the limit at some point a good bit lower. > > OK, so your intent is to require sgid-shadow utilities to update > > passwords? > > Yes. > > /usr/bin/passwd and (if enabled) /usr/bin/chage on Owl are SGID shadow. If reading your own password hash also requires sgid-shadow, then screen is sgid-shadow. Which means any user can easily get full shadow group perms (since screen is full of vulns if it's running suid/sgid) and thus you might as well not have had the group protection to begin with. Same applies to things like xlock. > That's our preference (for Owl) too. I think you misunderstood our use > of group shadow. It does not "cause other users' accounts to be > compromised" if it is compromised. Indeed, I did misunderstand. Your way is not as bad as it could be, but I'm still not very comfortable with the security implications of it.. > > There's no reason applications should not be able to assume they can > > safely call crypt where both the hash/salt/setting and key were > > provided by an untrusted party. > > There is such a reason for almost two decades now - since BSDi's > introduction of iteration counts in "setting" strings in 1993 or so. > That's the reality by now, and I think we should not be trying to change > it in musl. Thanks for bringing this up. I think the same limiting logic is required there. And if there's going to be a way to configurably override the limit, it should be mostly/entirely shareable. > As to untrusted keys (passwords/phrases), I agree with you. Those kinds > of issues should be avoided. glibc's uses of alloca() in SHA-crypt were > recently patched for that reason. Good analogy. And I think this one likewise needs to be addressed and fixed. Rich