Date: Thu, 9 Aug 2012 01:48:04 -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 08:04:32AM +0400, Solar Designer wrote: > 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. 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 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. > > 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. 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. > 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. Indeed, I did misunderstand. Your way is not as bad as it could be, but I'm still not very comfortable with the security implications of it.. > > 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. Thanks for bringing this up. I think the same limiting logic is required there. And if there's going to be a way to configurably override the limit, it should be mostly/entirely shareable. > 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. Good analogy. And I think this one likewise needs to be addressed and fixed. 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.