From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1476 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 23:25:27 -0400 Message-ID: <20120809032527.GN27715@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> 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 1344482688 576 80.91.229.3 (9 Aug 2012 03:24:48 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 9 Aug 2012 03:24:48 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1477-gllmg-musl=m.gmane.org@lists.openwall.com Thu Aug 09 05:24:49 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 1SzJMf-0006iP-2P for gllmg-musl@plane.gmane.org; Thu, 09 Aug 2012 05:24:49 +0200 Original-Received: (qmail 9338 invoked by uid 550); 9 Aug 2012 03:24:48 -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 9328 invoked from network); 9 Aug 2012 03:24:47 -0000 Content-Disposition: inline In-Reply-To: <20120809015104.GA24515@openwall.com> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:1476 Archived-At: 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. ;-) OK, so your intent is to require sgid-shadow utilities to update passwords? How is this significantly better than the old suid-root way? If someone compromises the utilities, they can change any user's password (including perhaps root's?) and thus gain access to any account. I would much rather just let users have rights to update their own shadow files (and throw away/ignore all the silly policy stuff in the shadow db; PAM can handle that better anyway) than risk compromise of other user's (or worse, root's) passwords due to a bug in the passwd program or similar... I thought the whole point of tcb was to get us past suid/sgid madness. > 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. Hm? We already protect against symlink issues. This was discussed when tcb support in musl was first discussed. > 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. Indeed, this has nothing to do with musl. It's just my preferred policy of having NO suid programs at all and no sgid programs that could cause other users' accounts to be compromised if they were compromised. Of course if you handle it with a daemon rather than suid (where there's only a single channel of input, not all sorts of ways you can control the environment the program runs in) then it may be okay to use a group like this... > > 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. Hmm, then we need to address that issue too. I consider O(2^2^n) performance when processing potentially-untrusted input a major DoS vuln. (It's 2^2^n where n is the number of bits in the logarithmic iteration count). 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. Rich