[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120809155254.GA28303@openwall.com>
Date: Thu, 9 Aug 2012 19:52:55 +0400
From: Solar Designer <solar@...nwall.com>
To: musl@...ts.openwall.com
Subject: Re: crypt* files in crypt directory
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
