[lang_hl=es,Español]Enlace permanente[/lang_hl] [lang_hl=en,English]Permalink[/lang_hl]

[lang_hl=es,Español]Básicamente, el asterisco en Unix siempre sirvió para bloquear cuentas porque no es un hash válido. Pero en 2012 musl cambió su función crypt para que, al fallar, devolviera justo ese asterisco en vez de NULL. Como OpenSSH compara lo que devuelve crypt con lo guardado en shadow, si hay un asterisco ahí, cualquier contraseña pega y deja entrar. Esto pasó desapercibido años porque casi todos usan glibc o PAM, que manejan el tema distinto. Al final, un investigador lo pilló a finales de 2026 probando OpenSSH con musl sin PAM y vio que, con esa combinación, cualquier clave abre las cuentas marcadas con asterisco.[/lang_hl] [lang_hl=en,English]Back in 1980, Unix used a star to lock accounts since it isn't a valid hash. When musl libc switched its crypt function to spit out a star instead of null on errors in 2012, it accidentally revived that old trick. Throw in OpenSSH's 2016 timing-attack fix and Alpine setting root to a star in 2022, and you get a weird setup where SSH just accepts any password for locked accounts on musl systems without PAM. This sneaky bug quietly sat around for ten years until I stumbled on it while fuzzing SSH logins last year.[/lang_hl]

[lang_hl=es,Español]06 de Noviembre de 2026[/lang_hl][lang_hl=en,English]November 06, 2026[/lang_hl]

 [lang_hl=es,Español]#openssh, [/lang_hl] [lang_hl=en,English]#openssh, [/lang_hl] [lang_hl=es,Español]#unix, [/lang_hl] [lang_hl=en,English]#unix, [/lang_hl] [lang_hl=es,Español]#seguridad[/lang_hl] [lang_hl=en,English]#security[/lang_hl]  [lang_hl=es,Español]Fuentes: [/lang_hl] [lang_hl=en,English]Sources: [/lang_hl]sshhole.com

+0