https://news.ycombinator.com/item?id=50377221

Pedantic, but more "author's understanding of the spec" which isn't always correct.

> assume nonstandard behavior

I go back and forth on this one (spec vs standard behavior). It feels like at some point the most widely used impl -is- the spec, as we've seen in other places (web standards).

> Upon successful completion, crypt() shall return a pointer to the hashed password [...]. Otherwise, it shall return a null pointer and set errno to indicate the error.

> The crypt() function shall fail if:

> [ENOSYS]

> The functionality is not supported on this implementation.

For example on Debian the manpage says:

> Upon error, crypt_r, crypt_rn, and crypt_ra write an _invalid_ hash to the output field of their _data_ argument, and crypt writes an invalid hash to its static storage area. This string will be shorter than 13 characters, will begin with a ‘*’, and will not compare equal to _setting_.

Not every C vuln is a memory safety problem.

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.

That's what led some people to write code where it crashes without checks. Which is still their mistake. But if the type was something that can't be implicitly used like an always-present value, that would have prevented the situation, even with those same people.

But it turns out one can have a compile-time error forthis in C as well: https://godbolt.org/z/8E9z66cfs

Now, the decision to return `"*"` instead of letting poorly written code crash on `NULL` is not good either.

Given how easy it is to just forward that error to the caller, I think most Rust developers would just choose to do that.

That's exactly what you get with Result and Option, it's impossible to forget.

Compare:

    char* hash = crypt(key, salt);

    // We crash here on the hash derefence, it's no clear from the code
    // that we were supposed to check for NULL or that we forgot. 
    if (!strcmp(hash, expected)) {
    }

    let result: Result<Vec<u8>, Error> = crypt(key, salt);
    // We MUST write this line, which is a very clear signal
    // that we can panic here.
    // This can be grepped for or forbidden.
    let hash: String = result.unwrap();

    // if result == expected { would type error
    if hash == expected {
    }

You are really uninformed: different programming languages have very different volumes of bugs per line of code

do you think bugs/loc is the same between brainfuck and rust?

no the study failed to show any difference in bug count for a specific set of common used languages, where C and Python were both part of the dataset.

I don't think programming languages have a big impact on bugs per line when every line is written by a human. Now given that I was talking about bug counts, not severity.

kind of reminds me how the "research" suggests that there are no practical differences between dynamically typed and statically typed languages...except we know from practical experience that there is, and the literature there is horribly flawed.

we have real-world evidence that rust leads to significantly less bugs in the real world

https://blog.google/security/rust-in-android-move-fast-fix-t...

It showed that there's no big difference. From the link:

> Combining corrections for all of these aforementioned items, the reanalysis revealed that only 4 out of the original 11 languages correlated with abnormal defect rates, and even for those the effect size is exceedingly small.

--

> we have real-world evidence that rust leads to significantly less bugs in the real world

no, we only have evidence for memory bugs, that's not what I was talking about

oh right, because c is a crusty old language with barely any features.

You are right, C with manual memory management, no lifetime management, lack of phat pointers and a culture of leet has problems with deranged maddening bugs that other languages don't have.

But this bug first shows how inband signaling is bad news usually. But worse it's a failure to adhere to the spec properly. If you implement a library and you don't adhere to the spec you're going to bone someone.

Perhaps even worse is obviously the spec doesn't come with any standard testing framework. That was also the root of Apples infamous goto bug.

people like you are holding back software and security by decades.

in theory could someone do it? yeah, just like in theory someone could use unsafe and return a raw char pointer for some reason.

but in practice would anyone do it? no.

what will it take to move away from c? older devs retiring. Planck said that "science advances one funeral at a time" and i fear it will be the same for software.

I'll take forking and porting, thank goodness for LLMs.

Rust is a fad among HN-types. It is not used in the real world. You see logic errors reported in C/++ because 99.99% of the world's system code is written in it. The only reason you don't see headlines about logic errors in Rust is because nobody uses Rust in production code. Rust certainly does not prevent you from producing the most dogshit software imaginable, eg. https://jepsen.io/analyses/particledb-1.1.4 , which is far worse than any C/++ database anybody uses.

Rewriting it to Rust is fine attempt, just hard to call it is unix/posix anymore. It may not matter but semantically true.

    let hash = match result {
        OK(s) => s,
        Err(s) => s,
    };

@my-huge-pony does make a good point elsewhere in the thread: if the potential error was not foreseen and the code was written originally to return `String` instead of `Result<String, Error>` then even Rust would be in a pickle.

There's a good chance similar flaws will be discovered elsewhere.

One occurrence is not a statistic and should not be used as evidence - it's just an example of a vulnerability that due to various bad circumstances lead to a particularity bad outcome. This logic is in my opinion equally flawed as calling alpine safe now because this particular vulnerability has been fixed.

I'm not a big fan of blaming and I think it's just a result of bad circumstances, but it's interesting to see how some seem to blame musl, but one could argue further that musl documented the behavior of their API which was ignored by openssh and so on

Never understood why Alpine is used to actually run anything in a container - if you statically link binary, then you don't need alpine as a base and if you don't what is the point? Don't @ me about image size, even without layer caching we're talking about tiny difference that is often dwarfed by size of your runtime.

Musl itself is a great example of taking "simple and lightweight" so seriously that everyone else gets to deal with the complexity. Slow allocator, underoptimized memcpy/string routines, limited locale support, no NSS, and endless glibc compatibility headaches.

But hey, at least libc is small. %%Proceeds to pull in megabytes of <any other>malloc, and other libraries to replace the slow parts of musl.%%

And now sshhole.com is a particularly spectacular example of what happens when "simple" meets the rest of the software ecosystem.

With dynamic linking, you just upgrade the library on your system and you're done. With static linking, every binary that uses the library has to be rebuilt.

crypt() returning `*` is insane especially since these kinds of sentinels are all over /etc/passwd

One is to return NULL for errors.

Another is to make the string result a parameter and use a return code to signal error.

A third, less common but still out there, is an error parameter.

Failure to observe these is on the caller. Forcing the caller to consider the error is probably where rust shines.

But a good C programmer is thinking about these idioms when they encounter a function signature for the first time, or they write one.

Right idea at the wrong time.

Which is why exceptions in Java can bubble up the stack? You don't have to catch it in a particular method you can let it go to the caller of the method, and so on.

Having been on the receiving end of debugging that a few times, I no longer mind the in-band error handling, although admittedly I'm inexperienced enough to be confident its better. Just for the random code I've had to read where I just need to know exactly how something I didn't write and will never read again works, and whether the error is handled and how, i love reading in-band error handling, even if I too dislike the way an error laden routine must be written. Over time I've come to appreciate elegance "in the large" as opposed to the code I see in any individual function.

    h = file_open(path)
    data = file_read(h)
    file_close(h)
    return data

    return file_open(path).success(h -> h, file_read(h)).success(h, data -> file_close(h); data)

I do prefer Maybe/Option/Either style returns in some cases though. Makes for a cleaner API.

So each method has its uses.

This is the root of a lot of the evil. Yes, humans want to program for the happy path. It is a lot more fun. However, that bias leads to so much lack of diligence to properly deal with the unhappy path.

You ideally want to attack the problem at two ends:

- make the syntax noise-free so you can see what is happening

- build primitives at the syscall and stdlib level for common footguns

You would still need to deal with domain-specific logic errors, but you have at least reduced the surface area exposed to casual attacks.

It is not. Being extremely restrictive in the happy path, throwing all over the place, but have generic error handling code at the top level (e.g. HTTP entry point) makes for some pretty robust, stable, easy to read software. Albeit it typically has somewhat rough user experience.

The thing is, that's a pretty good place to start. From there on, you can handle exceptions one by one, surgically, and make things nicer.

I have written very little Java, though, so this is more of an armchair analyst position.

Rust makes handling and mapping `Result` locally more ergonomic, even though `?` makes propagation easy too. Rust, however, also makes it easy to lose the context during propagation and end up with useless `Error`.

Another Rust self-suck session rendered completely irrelevant. Again.

Looking at the unpatched Ubuntu things in my life, and I'm pretty close to asking Claude to update things to see how quickly Alpine can get close, assuming responsiveness can stay this fast and quality.

"If you cannot update yet, at least disable password logins: set PasswordAuthentication no in your sshd configuration and restart sshd. Either one closes the hole." (only AI would characterize a critical SSH implementation vulnerability as a hole closing game)

An attacker who can reach your SSH port can log in without knowing any password. It takes one connection, works every time, and needs no retries. (It sounds like the writer is bragging about the exploit instead of describing it. AI does this)

The attacker needs the name of an account whose password field is * (an account with no password set, which is normal for key-only accounts), and needs the machine to have at least one other account with a $5$ or $6$ password hash. The attacker then sends a very long password (257 to 1024 bytes). One user with a password is enough: it makes every account without one reachable. (same as above made stronger with the 'statement: statement2' format)

"Users coming from a directory service through musl-nscd (nslcd, winbind, sssd), since they have no shadow entry." (a human would be more clear about what a shadow entry is and give more context, I think)

Hmm the rest of the article (the remaining 70-80%) seems quite human.

Anyway, not sure why I spent 10+ minutes on this. It just jumps at me right away.

Can someone explain this part to me? https://sshole.com doesn't appear to mention anything like this, and something tells me this makes all the difference.

I'm not sure this gets the point across when it effectively means "any other user with a real password"

Funnily enough, they don’t recommend checking pubkey auth is enabled and working. By blindly (or agenticly) following those instructions the risk is getting locked out of some machine.