| ▲ | Alpine Linux Security Advisory: OpenSSH-server password authentication bypass(alpinelinux.org) |
| 226 points by pantalaimon 3 hours ago | 18 comments |
| |
|
| ▲ | NewJazz 2 hours ago | parent | next [-] |
| musl’s crypt() returns the string * as an error indicator when the key is over 256 bytes long. * is also exactly what the stored field contains for every account with no password, so the “hash” matches and the login succeeds. Does anyone know why musl does this? Are they the only C library that behaves this way? For a C library that famously tries to adhere to POSIX as much as possible, this seems like a crazy choice. From POSIX standard: Upon successful completion, crypt() shall return a pointer to the encoded string. The first two bytes of the returned value shall be those of the salt argument. Otherwise, it shall return a null pointer and set errno to indicate the error. https://pubs.opengroup.org/onlinepubs/9699919799/functions/c... |
| |
| ▲ | hnfong 2 hours ago | parent | next [-] | | There's a very detailed trace of how the bug was developed over decades at sshhole.com and the relevant discussion in https://news.ycombinator.com/item?id=50378228 | | |
| ▲ | NewJazz an hour ago | parent [-] | | Thanks yeah just woke up, finished making my way through the single-article website and still unclear if other libcs do the same thing (the article says libxcrypt picked it up, but only after musl did it). |
| |
| ▲ | worksonmine an hour ago | parent | prev | next [-] | | Apparently because some devs didn't check for NULL which resulted in crashes. Weird choice to fix other peoples' bad programming by deviating from the spec. | | |
| ▲ | cyphar an hour ago | parent [-] | | To be fair (as the sshole site mentions) it is also necessary to fake a password hash check to avoid timing side channels revealing to remote clients whether users exist, so returning a sentinel value is not a horrifically unreasonable solution to make sure even naive code does approximately the right thing. Though I am surprised that all of the code examples do not use constant-time strcmp(). Actually, I wonder if even constant-time strncmp() would still leak information about whether the account is disabled because in that case both arguments are much shorter? Food for thought. But yeah, the crypt(3) API is very 80s C, the man page even features a lengthy description of a long-deprecated and utterly broken hashing algorithm using DES that is even implied to be broken in the text itself (and the warning message is so old it refers to "parallel computers" as though they were a new concept). Given that the default mode is to use a broken hashing algorithm, I'm shocked anyone actually uses the libc crypt(3) -- surely it's trivial to just write your own that isn't awful...? |
| |
| ▲ | api 2 hours ago | parent | prev [-] | | TBH that sounds like a straight up bug in that it deviates dangerously from the spec. | | |
| ▲ | NewJazz 24 minutes ago | parent [-] | | Which is notable because musl is more known for adhering to the spec to the point where they break programs that assume nonstandard behavior. |
|
|
|
| ▲ | throwa356262 2 hours ago | parent | prev | next [-] |
| Discussion from a few hours ago: https://news.ycombinator.com/item?id=50377221 |
|
| ▲ | slopinthebag 25 minutes ago | parent | prev [-] |
| i think it's just unbelievable there isn't a bigger push to move away from c to languages that can prevent stuff like this from happening. this and just the pure unsafety. it's 2026. it's like pure negligence at this point, the equivalent of building a bridge with matchsticks because you like using it more. |
| |
| ▲ | my-huge-pony 9 minutes ago | parent | next [-] | | How would using a language different than C help here? At it's core this bug is a logic bug, where "*" == crypt(x), because crypt in musl started returning "*" in some cases some years ago. This could be Rust. This could be Go. Not every C vuln is a memory safety problem. | | |
| ▲ | rhdjebejdbd 4 minutes ago | parent | next [-] | | Another comment said that returning a * was to avoid returning null which would crash users of the library who didn't check for null. That seems like a C smell to me | |
| ▲ | realharo 6 minutes ago | parent | prev | next [-] | | >because crypt in musl started returning "*" in some cases some years ago In Rust, the type of the return value would be a `Result<T, E>`, which means the chain of events that led to this would never have started in the first place. | | | |
| ▲ | slopinthebag 4 minutes ago | parent | prev [-] | | why does this logic bug exist? why are they returning a string, why not a result type, (nil, err), or something else? oh right, because c is a crusty old language with barely any features. |
| |
| ▲ | oguz-ismail2 7 minutes ago | parent | prev | next [-] | | What exactly do you mean "push"? What do you think is going to make musl developers switch languages? | |
| ▲ | anonreplier 7 minutes ago | parent | prev | next [-] | | guess what, this kind of sentinel value mistake could even be made in rust | | | |
| ▲ | rpdillon 6 minutes ago | parent | prev [-] | | musl's crypt function could be written in Rust, Python, or JavaScript, and still return * when the key is too long. |
|
