Signal is active with 3 mentions in latest observed window
Recommended action window: Monitor and triage in normal cycle
NVD description
sshd in OpenSSH before 7.3, when SHA256 or SHA512 are used for user password hashing, uses BLOWFISH hashing on a static password when the username does not exist, which allows remote attackers to enumerate users by leveraging the timing difference between responses when a large password is provided.
Priority
LOW
Exploitation
NONE
PoC
NONE
Patch
NONE
Momentum
STABLE
If you run products in this scope, you should treat this CVE as relevant to your environment.
En 2016 arreglan CVE-2016-6210 en OpenSSH. Este fallo permitía deducir usuarios porque al procesar uno que existía tardaba algunos milisegundos más que si no. Para solucionarlo, se llama a crypt() siempre, incluso si el hash es no válido, para así tardar lo mismo.
Piece 3 (July 2016): OpenSSH’s timing fix. CVE-2016-6210 let attackers enumerate users by response time. The fix: even for accounts with *, sshd borrows a real $5$ or $6$ salt from another user and runs crypt() anyway so the timing matches. It never expected the library to return exactly "*" on a long password.
how it fails: * has no salt, so after the CVE-2016-6210 timing fix sshd borrows another user's salt via pick_salt. musl crypt() refuses keys >256 bytes and returns "*". strcmp("*","*") matches. login ok.
@LeoVasanko @wangzhr4 Brain damaged take. Ask yourself why musl decided to do that. Would that be the case if sum types were available with good ergonomics? Would CVE-2016-6210 have been mitigated in the same way if they had access to a crate like subtle?
1 of 1 entries
| Part | Vendor | Product | Version | Target SW | Target HW |
|---|---|---|---|---|---|
| App | openbsd | openssh | - | - | - |