[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20261107140254.GF23438@brightrain.aerifal.cx>
Date: Sat, 7 Nov 2026 09:02:55 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: OpenSSH password auth bypass analysis [was: Re:
Advisory for OpenSSH+musl users]
On Fri, Nov 06, 2026 at 01:54:55PM -0500, Rich Felker wrote:
> As for hardening musl against this kind of issue, pursuing a switch to
> returning an error (null+errno) has been an open issue for a long time
> now, and one I'd like to assess in the next release cycle. In the
> immediate, I am going to propose a patch switching to the more common
> "*0"/"*1" convention for failure tokens. This does not prevent misuse,
> but it's safer under the assumption that the conventional "*" is what
> appears in shadow. This should be able to go into the pending release
> and would be easy for distros to apply as a backport if desired.
There is another measure I've considered. I'm not sure if it's a good
idea, but it would get rid of the "password too long" error condition.
Instead of having sha256/512 produce an error hashing long passwords
(current behavior) or silently truncate them or something (risks
making password hashes that won't validate the same with other
implementations), fallback to DES in this case. The output would be a
valid DES hash *specific to the password entered* which would compare
not-equal to the correct sha256/512 hash in a password-validating
role. This would never compare equal to anything but a valid DES hash
created for the same password.
The reason for not choosing a better algorithm is to avoid silently
generating hashes that might not be supported by the implementation
reading the hashes (in the case where we're generating new passwords).
But maybe there are implementations now that have dropped DES too?
But we could do the fallback only when validating (the input salt has
a hash with it) not when generating new passwords (setting part only).
This would just safely ensure that the password can't falsely match a
special token in the shadow/passwd file.
This is a kinda wild idea that I haven't seen proposed before. I'm not
committed to actually trying it, but wanted to throw it out there for
feedback in case it's interesting.
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.
