[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <au9P8TiGg_jtRBd4@pie>
Date: Sat, 7 Nov 2026 16:21:05 +0000
From: Yao Zi <me@...ao.cc>
To: musl@...ts.openwall.com
Cc: Yao Zi <me@...ao.cc>
Subject: Re: OpenSSH password auth bypass analysis [was: Re:
Advisory for OpenSSH+musl users]
On Sun, Nov 08, 2026 at 01:08:57AM +0900, Seo Suchan wrote:
> I may missing something obvious but why we need max password size when caller already allocated memory for full password? After first pass it'd be fixed 256/512bits and we hash megabytes of files in second even in embedded.
Processing requests in seconds sounds just like a DoS attack.
But, would it be a solution to delegate the work of limiting password
lengths to the caller? Though I didn't investigate how many applications
would be then vulnerable to attacks with such change.
> On 2026년 11월 7일 오후 11시 2분 55초 GMT+09:00, Rich Felker <dalias@...c.org> 작성함:
> >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
--
Thanks,
Yao Zi
Meow-mrrp-mrow, I'm a cat.
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.
