Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 9 Aug 2012 13:59:28 -0400
From: Rich Felker <>
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.


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.