[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20261107162826.GA3542221@port70.net>
Date: Sat, 7 Nov 2026 17:28:26 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: Yao Zi <me@...ao.cc>
Cc: musl@...ts.openwall.com
Subject: Re: OpenSSH password auth bypass analysis [was: Re:
Advisory for OpenSSH+musl users]
* Yao Zi <me@...ao.cc> [2026-11-07 16:21:05 +0000]:
> 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.
you are confusing sha256 hash with sha256 crypt.
the latter is an iterated password hash, that is
supposed to be "slow" or at least hard to bruteforce.
and supposed to be adjusted via a round= setting.
but due to bad design the slowness depends on the
key length such that a sysadmin cannot set round=
in a reasonable way. (ideally you don't want the
computation time to depend on the input at all,
but in sha256 crypt it's O(keylen^2+round*keylen)).
the caller can limit the key len, but when this
code was written i checked a number of callers
including ssh servers and almost none of them
had reasonable limit for common round= settings.
there are low powered openwrd devices hanging
on the net, usually passwd hash is disabled, but
if somebody enables it the keylen limit gives a
decent protection.
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.
