Stuart Henderson wrote:
> On 2015/07/17 20:24, Ted Unangst wrote:
> > Jeremy Evans wrote:
> > > As an aside, crypt("passwd", "$2") returns ":" instead of NULL. I'm not
> > > sure if that's a security issue, but I think it is and we should fix it.
> > > I'll see if I can get a patch for that and send it to tech@.
> >
> > This is a weird edge case where niels decided to make bcrypt() work
> > differently than crypt(). i don't really know why. I think null is the safer
> > return, and we should probably switch. we don't have code that looks for ":"
> > (and certainly no third party code ever does), but there is code that checks
> > for null.
>
> Solar had some concerns about crypt returning null in the past, there's
> a thread starting at http://www.openwall.com/lists/oss-security/2011/11/15/1
> which might be worth a read.
moving to tech.
Programs may not be checking null, but they're definitely not checking for
strange alternative strings. At least null is standard.
Now, returning ":" or "*" or whatever works in some cases because that's not
the input string. But what happens when a program takes the return and saves
it to the database? Then you *do* have a string that matches.
(i think solar then fixed this by alternating between "*1" or "*2" but now
we're getting really deep into the rabbit hole.)
my perspective is: absent clear knowledge of what programs are doing, attempts
to second guess them in a library function are perilous. let us be standards
compliant, and then at least any resulting holes are clearly the program's
fault.
have i mentioned that i think the whole crypt(3) api can die in a fire?
