CVE-2016-6210. ask sshd about a user that doesn’t exist and it says no instantly, cause there’s nothing to hash. [The solution is] sshd grabs some other account’s salt and hashes your password anyway
I’m not sure how this is relevant to what caused this bug. Seems to me like a random point that was added by the AI writing this blogpost without human review.
The article doesn’t clearly explain how all of these fit together, but here’s what I think they mean happens:
Attacker tries to connect on a user account that should not accept a password, ie the user’s hash is “*”.
This should be outright rejected (“*” means no password login), but because of the point you highlighted, it just grabs a random salt and tries to calculate the password hash anyway.
The password is too long so it gets automatically rejected… with the magic value “*”.
User hash is “" and the “calculated” hash is also "”, so login accepted.
Without the “fix” of using another user’s salt, the process would fail immediately for a password-less account. Note that the other user’s salt never plays a role in the calculation because the password is too long and the hash function doesn’t bother calculating it. But it’s the reason execution continues and allows the rest of the bad behaviors to accept the login.
In hindsight, the mistakes are pretty silly. They shouldn’t actually care if the hash matched the user’s hash if they are one the codepath that is only performing the hash to waste time. Long passwords should be rejected earlier as invalid user inputs instead of reaching the hash functions. These decisions are basically saying “I’m going to do something stupid, but it shouldn’t affect anything because the other parts of the code are surely not doing something stupid at the same time”. It’s obvious why this design philosophy didn’t scale.
I’m not sure how this is relevant to what caused this bug. Seems to me like a random point that was added by the AI writing this blogpost without human review.
The article doesn’t clearly explain how all of these fit together, but here’s what I think they mean happens:
Without the “fix” of using another user’s salt, the process would fail immediately for a password-less account. Note that the other user’s salt never plays a role in the calculation because the password is too long and the hash function doesn’t bother calculating it. But it’s the reason execution continues and allows the rest of the bad behaviors to accept the login.
In hindsight, the mistakes are pretty silly. They shouldn’t actually care if the hash matched the user’s hash if they are one the codepath that is only performing the hash to waste time. Long passwords should be rejected earlier as invalid user inputs instead of reaching the hash functions. These decisions are basically saying “I’m going to do something stupid, but it shouldn’t affect anything because the other parts of the code are surely not doing something stupid at the same time”. It’s obvious why this design philosophy didn’t scale.