Re: crypt* files in crypt directory

[Solar Designer <solar@openwall.com>]

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