[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 9 Aug 2012 13:59:28 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: crypt* files in crypt directory
On Thu, Aug 09, 2012 at 07:52:55PM +0400, Solar Designer wrote:
> > > /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.
OK, so basically if you have screen installed, any user has permission
to run tcb_chkpwd any way they like (because essentially every user
now belongs to group screen).
> 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.
This sounds fairly reasonable, but given the history of vulns in
xlock, it probably means all users now belong to group chkpwd.
> 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.
Have you considered changing tcb_chkpwd to communicate with a daemon
over a unix socket rather than being sgid? That reduced the number of
input channels an attacker has from N (which grows with time since
Linux keeps adding more and more ridiculous amounts of state processes
can inherit) to 1 (the socket). I think the change could be made
transparently to programs which use it.
Rich
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.
