From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1478 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 08:04:32 +0400 Message-ID: <20120809040432.GA24985@openwall.com> 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> 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 1344485077 14189 80.91.229.3 (9 Aug 2012 04:04:37 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 9 Aug 2012 04:04:37 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1479-gllmg-musl=m.gmane.org@lists.openwall.com Thu Aug 09 06:04:38 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 1SzJzA-0006rJ-K2 for gllmg-musl@plane.gmane.org; Thu, 09 Aug 2012 06:04:36 +0200 Original-Received: (qmail 24382 invoked by uid 550); 9 Aug 2012 04:04:35 -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 24374 invoked from network); 9 Aug 2012 04:04:35 -0000 Content-Disposition: inline In-Reply-To: <20120809032527.GN27715@brightrain.aerifal.cx> User-Agent: Mutt/1.4.2.3i Xref: news.gmane.org gmane.linux.lib.musl.general:1478 Archived-At: 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. > 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. > How is this significantly better than the old suid-root > way? If someone compromises the utilities, they can change any user's > password No, they can't. They only gain the ability to perform this DoS attack, bypass password policy for their own account, and mount certain further attacks - which would require another vulnerability to succeed. So we have an extra layer of security here. > I would much rather just let users have rights to update > their own shadow files This is precisely what happens after group shadow is somehow compromised. But we don't provide that level of access right away for the reasons I mentioned. > (and throw away/ignore all the silly policy > stuff in the shadow db; PAM can handle that better anyway) PAM needs a place to store that info anyway, and in typical cases the fields of the shadow db are just sufficient. > than risk > compromise of other user's (or worse, root's) passwords due to a bug > in the passwd program or similar... Our tcb scheme was designed precisely to mitigate this risk. > I thought the whole point of tcb was to get us past suid/sgid madness. Past SUID madness, yes. SGID, on the other hand, is sometimes a way to have multiple layers of security. We use it for that in Owl - not only in tcb, but also e.g. for crontab(1). We always assume that the group access might be compromised, yet we do introduce this separation layer. This reminds me of how early versions of Postfix (VMailer at the time) tried to avoid SUID/SGID altogether, but eventually, after some debates between DJB and Wietse on Bugtraq, Postfix started using SGID for its postdrop program - similarly to how qmail does that. I think this move was just right. > > 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. Right. That's not what I was referring to here. Suppose any user can read their own tcb shadow file without any special privileges. This means that a CGI program running as them can read this file too. If the program has a remote read-any-file vulnerability, the remote attacker can read the user's password hash, possibly succeed in cracking it offline, then SSH in (if the service is running, etc.) On Owl, we avoid this risk by requiring group shadow for /etc/tcb 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. > > 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. 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. > > 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. Just implement tcb right, like we do. ;-) > 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. 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. Alexander