Hope @dalias is having an alright day...
(Can't say I understand the bug, but if it were musl's problem, wouldn't dropbear be affected too?)
0 Boosts
0 Likes
This federated comment is not yet available here.
@equinox @cr1901 It says "The algorithm is implementation-defined."
The choice of definition here is one that does not treat any input as an error but treats some inputs as unmatchable.
I don't think that's a great choice, and it's one we've been considering changing for some time now. But it is the choice almost every existing implementation takes now.
@dalias @equinox @cr1901 One way I see it could be part of POSIX requirements would be with "the first two bytes of the returned value shall be those of the salt argument", which doesn't works in all cases.
Plus returning an error like with NULL here depends on the ERRORS section, which doesn't have any requirement for an invalid value passed to salt, so consistently returning NULL for the OpenSSH vulnerability is an extension.
@equinox @cr1901 I'm sorry if I'm in a bit of a bad mood over this. But this morning Theo, knowing full well this is a difference OpenBSD is in the minority on and that he's been fighting to change for decades, decided to gaslight me trying to act like musl is the only one doing it this way and we did something horrible and irresponsible.
@dalias@hachyderm.io @equinox@chaos.social @cr1901@mastodon.social someone should point him to NetBSD's manpage for crypt.3: https://man.netbsd.org/crypt.3#RETURN%20VALUES
@cr1901 It's not musl's problem, and my day is fine except for Theo being an abusive asshole and trying to gaslight me into thinking it's my problem by pretending every other system out there behaves like OpenBSD (spoiler: none but Fedora and FreeBSD do) despite knowing this is a crusade he's been on for decades already.
@dalias (Just for my own reference: Does POSIX say crypt is allowed to _not_ return NULL if it can't do its job? If so, feels like the crypt behavior change got lost before the openssh devs could fix it.)
@cr1901 It says the transformation is implementation-defined. One choice of definition, which is by far the most common historical one, is a string chosen to never be matchable when passed back in as the salt argument.
@cr1901 The problem is that openssh is not passing it back in as the salt argument, as is required to use the interface correctly.
Instead of checking if crypt(candidate_pw,hash)==hash, they are checking if crypt(candidate_pw,other_users_hash)==hash.
They're doing this for users who have disabled password login in order to mask timing differences that would reveal that fact.
