391–400 of 569 posts
I just installed Harbor, and it instantly pegged my cpu.. i was lucky to see my processes before the system hard locked. Basically it forkbombed `grep -r rpcuser\rpcpassword` processes trying to find cryptowallets or something. I saw that they spawned from harness, and killed it. Got lucky, no backdoor installed here from what i could make out of the binary
> i was lucky to see my processes before the system hard locked. how do you do that? have Activity Monitor up at all times?
Thank you for posting this, interesting. I hope that everyone's course of action will be uninstalling this package permanently, and avoiding the installation of packages similar to this. In order to reduce supply chain risk not only does a vendor (even if gratis and OS) need to be evaluated, but the advantage it provides. Exposing yourself to supply chain risk for an HTTP server dependency is natural. But exposing yo…
> Remember that you are programmers and you can just program, you don't need a framework, you are already using the API of an LLM provider, don't put a hat on a hat, don't get killed for nothing. Programming for different LLM APIs is a hassle, this library made it easy by making one single API you call, and in the backstage it handled all the different API calls you need for different LLM providers.
Earlier quoted context omitted.
It turns out that it's possible for the server to detect whether it is running via "| bash" or if it's just being downloaded. Inspecting it via download and then running that specific download is safer than sending it directly to bash, even if you download it and inspect it before redownloading it and piping it to a shell.
The server can also put malware in the .tar.gz. Are you really checking all the files in there, even the binaries? If you don't what's the point of checking only the install script?
The .tar.gz can be checksummed and saved (to be sure later on that you install the same .tar.gz and to be sure it's still got the same checksum). Piping to Bash in one go not so much. Once you intercept the .tar.gz, you can both reproduce the exploit if there's any (it's too late for the exploit to hide: you've got the .tar.gz and you may have saved it already to an append-only system, for example) and you can verify the checksum of the .tar.gz with other people.
The point of doing all these verifications is not only to not get an exploit: it's also to be able to reproduce an exploit if there's one.
There's a reason, say, packages in Debian are nearly all both reproducible and signed.
And there's a reason they're not shipped with piping to bash.
Other projects shall offer an install script that downloads a file but verifies its checksum. That's the case of the Clojure installer for example: if verifies the .jar. Now I know what you're going to say: "but the .jar could be backdoored if the site got hacked, for both the checksum in the script and the .jar could have been modified". Yes. But it's also signed with GPG. And I do religiously verify that the "file inside the script" does have a valid signature when it has one. And if suddenly the signing key changed, this rings alarms bells.
Why settle for the lowest common denominator security-wise? Because Anthropic (I pay my subscription btw) gives a very bad example and relies entirety on the security of its website and pipes to Bash? This is high-level suckage. A company should know better and should sign the files it ships and not encourage lame practices.
Once again: all these projects that suck security-wise are systematically built on the shoulders of giants (like Debian) who know what they're doing and who are taking security seriously.
This "malware exists so piping to bash is cromulent" mindset really needs to die. That mentality is the reason we get major security exploits daily.
Earlier quoted context omitted.
(I am not a security expert either) But, one of the arguments that I saw online from this was that when a security researcher finds a bug and reports it to the OSS project/Company they then fix the code silently and include it within the new version and after some time, they make the information public So if you run infrequently updated versions, then you run a risk of allowing hackers access as well. (An good exampl…
Good points. Perhaps there is a way to configure uv to only use a new version if it is 24 hours old?
How you use it depends on your workflow. An entry like this in your pyproject.toml could suffice:
[tool.uv]
exclude-newer = "5 days"Besides main issue here, and the owners account being possibly compromised as well, there's like 170+ low quality spam comments in there. I would expect better spam detection system from GitHub. This is hardly acceptable.
The same thing occurred on the trivy repo a few days ago. A GitHub discussion about the hack was closed and 700+ spam comments were posted. I scrolled through and clicked a few profiles. While many might be spam accounts or low-activity accounts, some appeared to be actual GitHub users with a history of contributions. I’m curious how so many accounts got compromised. Are those past hacks, or is this credential steeli…
It will only take one agent-led compromise to get some Claude-authored underhanded C into llvm or linux or something and then we will all finally need to reflect on trusting trust at last and forevermore.
In the end we need fully deterministic, 100% verifiable, chains. From the tiny boostrapped beginning, to the final thing.
There are people working on these things. Both, in a way, "top-down" (bootstrapping a tiny compiler from a few hundred bytes) and "bottom-up" (a distro like Debian having 93% of all its packages being fully reproducible).
While most people are happy saying "there's nothing wrong with piping curl to bash", there are others that do understand what trusting trust is.
As a sidenote although not a kernel backdoor, Jia Tan's XZ backdoor in that rube-goldberg systemd "we modify your SSHD because we're systemd and so now SSHD's attack surface is immensely bigger" was a wake-up call.
And, sadly and scarily, that's only for one we know about.
I think we'll see much more of these cascading supply chains attack. I also think that, in the end, more people are going to realize that there are better ways to both design, build and ship software.
I've been waiting for something like this to happen. It's just too easy to pull off. I've been hard-pinning all of my versions of dependencies and using older versions in any new projects I set up for a little while, because they've generally at least been around long enough to vet. But even that has its own set of risks (for example, what if I accidently pin a vulnerable version). Either that, or I fork everything,…
> Even still though, we can't really trust any open-source software any more that has third party dependencies, because the chains can be so complex and long it's impossible to vet everything. This is why software written in Rust scares me. Almost all Rust programs have such deep dependency trees that you really can't vet them all. The Rust and Node ecosystems are the worst for this, but Python isn't much better. IMO…
JS/TS > Screems aloud! never do "npm import [package containing entire world as dependency]"
Rust > Just import everything since rust fixes everything.
When you design your package management and doctrine like de facto javascript your have failed like javascript.