Hacker News new | ask | show | jobs
by rosnd 1327 days ago
Is it meaningfully sketchier than downloading a .deb and calling dpkg -i on it?

Or cloning a git repo and building it?

2 comments

The difference is that the stream coming out of curl and entering sh is ephemeral. With this device, there is no checksum or signature (as with apt). If you pipe curl into sh, you also leave no trail of what you've run. A malicious actor can also hinder analysis by serving different payloads per user-agent, per time of day, per subnet; or only serving the malicious payload intermittently.

With .deb-files you're expected to verify the checksum. Maybe you don't, and even if you don't, you can theoretically go back and verify after as part of a forensic process. This checksum is also typically distributed across different mirrors, making bait-and-switch attacks difficult. It means that if you're going to do a supply chain attack, you must do it in the open.

Compiling from sources is a bit sketchy, but it is also the vector that is easiest to analyze, so I think they cancel out.

>Compiling from sources is a bit sketchy, but it is also the vector that is easiest to analyze, so I think they cancel out.

Is it really meaningfully easier to analyse? I get that it feels better, but I'd bet that the people saying this would fail to catch the backdoor every time.

Yeah, it's possible for a web server to detect and change the returned data maliciously. Even with user agent and all other factors changed to match, it's possible to detect even the difference between being piped into another command vs being redirected to a file.
It's also possible for a web server to selectively serve you a backdoored .deb or git repo
It helps that Signal uses an HTTPS apt repo and includes "signed-by=/usr/share/keyrings/signal-desktop-keyring.gpg" in the apt list entry. If their download server were compromised, (and assuming the hacker didn't also get the private gpg key) the attacker would have to provide malicious archives selectively to avoid detection. Anyone who installed the old key (e.g., me) would notice the key validation errors.
So what? I can inspect downloaded code and find the backdoor, or a trojan, or an error. I did it few times already in last 30 years. If you cannot do that doesn't mean that nobody can. But I cannot do that with `curl | bash`.
If you can't save the output of curl into a file, you certainly aren't one of the few people capable of meaningfully inspecting anything you download.
I cam do that on MY machine. I cannot do that on your. I can download code, inspect it, install, and then create a RPM package, which can be installed in a safe way by DNF package manager, but I cannot do that with `curl | bash` method of installation.
>I can download code, inspect it, install, and then create a RPM package, which can be installed in a safe way by DNF package manager, but I cannot do that with `curl | bash` method of installation.

But you can?