From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1486 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 19:52:55 +0400 Message-ID: <20120809155254.GA28303@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> <20120809040432.GA24985@openwall.com> <20120809054804.GO27715@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 1344527585 26714 80.91.229.3 (9 Aug 2012 15:53:05 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 9 Aug 2012 15:53:05 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1487-gllmg-musl=m.gmane.org@lists.openwall.com Thu Aug 09 17:53:03 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 1SzV2j-0002iZ-LB for gllmg-musl@plane.gmane.org; Thu, 09 Aug 2012 17:53:01 +0200 Original-Received: (qmail 28512 invoked by uid 550); 9 Aug 2012 15:53:00 -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 28504 invoked from network); 9 Aug 2012 15:53:00 -0000 Content-Disposition: inline In-Reply-To: <20120809054804.GO27715@brightrain.aerifal.cx> User-Agent: Mutt/1.4.2.3i Xref: news.gmane.org gmane.linux.lib.musl.general:1486 Archived-At: On Thu, Aug 09, 2012 at 01:48:04AM -0400, Rich Felker wrote: > On Thu, Aug 09, 2012 at 08:04:32AM +0400, Solar Designer wrote: > > 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 agree that it's not great that this problem exists, but I am unsure if trying to solve it would make things better overall. > 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. This makes some sense. > > /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. No, screen is SGID screen, and group screen provides access to the tcb_chkpwd and utempter helpers, which are SGID shadow and utmp, respectively. xlock, if installed, may be made SGID chkpwd (a group provided on Owl by default for that possible use), which provides access to tcb_chkpwd only. This is what doc/REDHAT (advice on using Red Hat's packages on Owl) suggests. Being a server distro, we don't provide X ourselves. Even if group screen or chkpwd is compromised, this only allows for direct attacks on tcb_chkpwd - and it's a rather small program (5 KB binary). This does not allow for group shadow access without having found and exploited a vulnerability in tcb_chkpwd first. Obviously, certain vulnerabilities in the dynamic linker, libc, or/and the kernel would allow to compromise any SGID program's target group. That would be nasty, but not fatal - e.g., DoS attacks like what we're discussing would be possible. Alexander