Actually the dude was looking to profile some other program of his own and tried to reduce nose on the machine. That’s when he noticed sshds creating a load of load with no reason.

On any server, you want unattended upgrades.

https://lemmy.ml/post/13801726

OpenSSH backdoor

Opensautists

Yeah he didn’t find the right unmaintained project. There are many many many cs undergrads starting projects that will become unmaintained pretty soon.

True. And the “given enough eyeballs, all bugs are shallow” is a neat sounding thing from the past when the amount of code lines was not as much as now. Sometimes it is scary to see how long a vulnerability in the Linux kernel had been there for years, “waiting” to be exploited.

Even in open source, responsible disclosure is generally possible.

See, e.g. Spectre/Meltdown, where they worked privately with high level Linux Kernel developers for months to have patches ready on all supported branches before they made the vulnerability public

Was the transition into management easy for you, or was it a slow acceptance?

bUt gUyS WhAt aBoUt sEcUrItY ThRoUgH ObScUrItY??

Honestly, for closed source software the POCs are also immediately available. Lots of threat actors just use patch diffing.

These days vulnerabilities are at times also patched with other non-related commits to conceal what exactly has changed.

In this case it seems the backdoor is only usable with someone who has the correct key. Seeing and reverting something fishy is in some cases, like this easier than finding an exploit. It takes a lot of time in this case to figure out what goes on.

Fixing a bug never automatically give an easy to use exploit for script kiddies

If your security relies on hidden information then it’s at risk of being broken at any time by someone who will find the information in some way. Open source security is so much stronger because it works independently of system knowledge. See all the open source cryptography that secures the web for example.
Open source poc and fix increases awareness of issues and helps everyone to make progress. You will also get much more eyes to verify your analysis and fix, as well as people checking if there could other consequences in other systems. Some security specialists are probably going to create techniques to detect this kind of sophisticated attack in the future.
This doesn’t happen with closed source.
If some system company/administrator is too lazy to update, the fault is on them, not on the person who made all the information available for your to understand and fix the issue.

I’m pretty sire there are plenty of ways to exploit proprietary systems. You can’t stop the power of the keyboard

this is why we invented responsible disclosure, which is a thing companies like apple do even. Although in this case, this was the very beginning of what seemed to be a rollout, so if it does effect systems, it’s not very many. And if they are affected. The solution is pretty obvious.

Don’t be a dunce, report responsibly.

I second this. I love to feel part of a community even tho I could have never found the backdoor, let alone fix it.

It’s a really wicked problem to be sure. There is work underway in a bunch of places around different approaches to this; take a look at SBoM (software bill-of-materials) and reproducible builds. Doesn’t totally address the trust issue (the malicious xz releases had good gpg signatures from a trusted contributor), but makes it easier to spot binary tampering.

I’m not familiar with rust but at least for java there’s a owasp plugin that tells you if you’re using an unsafe library.

Like, what are we even suppose

supposed

to tell “normal people” about security? “Yeah, don’t download files from people you don’t trust and never run executables from the web. How do I install this programming utility? Blindly run code from over 300 people and hope none of them wanted to sneak something malicious in there.”

You’re starting to come to an interesting realization about the state of ‘modern’ programming and the risks we saw coming 20 years ago.

I don’t want to go back to the days […]

You don’t need to trade convenience for safety, but having worked in OS Security I would recommend it.

Pulling in random stuff you haven’t validated should feel really uncomfortable as a professional.

Do you really need to download new versions at every build? I thought it was common practice to use the oldest safe version of a dependency that offers the functionality you want. That way your project can run on less up to date systems.

Which is why you shouldn’t do that. Dependency nightmare is a real problem many developers face. More to the point they impose it on you as well if you are by any reason forced to use their software. Well established libraries are gateway to this. People are getting out of their way to complicate lives to themselves and massive amount of others just so they could avoid writing a function or two. Biggest absurdity I like to point out to people is the existence of is-number NPM package, which does that. It has 2300 dependent projects on it!!! Manifest file for said package is bigger than the source. And the author had the hubris to “release it under MIT”. How can you claim copyright on num - num === 0?

On all the projects I manage I don’t allow new dependencies unless they are absolutely needed and can’t be easily re-implemented. And even then they’d have to be already in the Debian respository since it’s a good and easy way to ensure quick fixes and patching should it be needed. Sometimes alternative to what we wanted to use already is in repo, then we implement using different approach. We only have few Python modules that are not available in repo.

Managing project complexity is a hard thing and dependencies especially have a nasty habit of creeping up. I might be too rigid or old-school or whatever you want to call it, but hey at least we didn’t get our SSH keys stolen by NPM package.

THIS.

I do not get why people don’t learn from Node/NPM: If your language has no exhaustive standard library the community ends up reinventing the wheel and each real world program has hundreds of dependencies (or thousands).

Instead of throwing new features at Rust the maintainers should focus on growing a trusted standard library and improve tooling, but that is less fun I assume.

Debian actually started to collect and maintain packages of the most important rust crates. You can use that as a source for cargo

For the uninitiated, this is a representation of the Survivors Bias.

Essentially, the red dots represent bullet holes from aircraft which returned from battle.

If you were to ask someone which places should be reinforced with armour, someone who has the Survivors Bias would say “where the red dots are”, whereas people who know anything about engineering would say “everywhere else!”

To put it another way. If an aliens looked at survivors at war and saw very few had head wounds, they might be confused why we put so much emphasis on wearing a helmet, since we almost never get hurt there.

A true fact: Did you know wearing a helmet increases your chances of dying of cancer.

What are you saying? That there are people doing the top version (“I want a backdoor / I ask the corpo to grant me access”) for FOSS but they’re less likely to get caught if they don’t do all the gymnastics?

Queensbury Rules init.

It’s about the complex rationalizations used to create excuses (pretexts).

The original is this:

related blog - https://robmensching.com/blog/posts/2024/03/30/a-microcosm-of-the-interactions-in-open-source-projects/

Make no mistake. This is the way it works.

It needs to change.

Agreed.