Re: crypt* files in crypt directory

[Rich Felker <dalias@aerifal.cx>]

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. ;-)

OK, so your intent is to require sgid-shadow utilities to update
passwords? How is this significantly better than the old suid-root
way? If someone compromises the utilities, they can change any user's
password (including perhaps root's?) and thus gain access to any
account. I would much rather just let users have rights to update
their own shadow files (and throw away/ignore all the silly policy
stuff in the shadow db; PAM can handle that better anyway) than risk
compromise of other user's (or worse, root's) passwords due to a bug
in the passwd program or similar... I thought the whole point of tcb
was to get us past suid/sgid madness.

> 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.

> 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. Of course if you handle it with a daemon rather than suid
(where there's only a single channel of input, not all sorts of ways
you can control the environment the program runs in) then it may be
okay to use a group like this...

> > I don't know how to solve it, but in musl I think we'll have to put a
> > low limit on count if we're going to support blowfish.
> 
> That's not good.
> 
> 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. I consider O(2^2^n)
performance when processing potentially-untrusted input a major DoS
vuln. (It's 2^2^n where n is the number of bits in the logarithmic
iteration count).

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.

Rich