3 ms·

> Installing software by piping from curl to bash is obviously a bad idea and a knowledgable user will most likely check the content first. I’ve yet to hear a

by tomp 4y ago

> Installing software by piping from curl to bash is obviously a bad idea and a knowledgable user will most likely check the content first. I’ve yet to hear a coherent explanation why this is any worse than installing software from the internet in general. It’s not like you check the source of all software you install.

deleted 4y ago
[deleted]
ducktective 4y ago
If maintainers of the distro review their accepted packages thoroughly, then apt install would be superior to curl | bash But 9 out of 10 times I used apt install cargo, I've been bitten by dependency hell
jacooper 4y ago
I think its more that the packages are vetted by your distro, but this script isn't, and you don't know what's in it.
- tomp 4y ago
  Most software I install isn’t distro software, but Python binaries (python, mamba, numpy, pytorch) and packages via pip/mamba/conda.
LilBytes 4y ago
Source in this instance doesn't always mean source code but _the source were you're downloading it from_. If canonical.com tells me to curl $url | sh, I'm fairly confident the script Im downloading is safe. as much as an .iso, .bin or .exe would be. But I'd be a lot more hesitant doing the same from craigs-legit-swe-blog.com.
l33tman 4y ago
I guess it's a question of effort on the side of the person doing the trojan - if enough suckers just copy those snippets regularly you can be lazy and just do it like that, you don't need to go through the hassle of creating fake Ubuntu PPAs with trojans or distribute a big repo on GitHub and risk someone seeing the trojan part.
lexandstuff 4y ago
Before SSL certs were as ubiquitous as they are now, we used to warn about the danger of curl to bash for unsecured URLs, as it's a vector for a DNS spoofing attack. Now that nearly all URLs are HTTPS with valid certificates, the remaining risk seems to be that the host could be intentionally or unintentionally doing something destructive. Sure it would be great to review the code of every install script before you run it, but as you allude to, it isn't practical. Maybe something like ChatGPT could help us here?
colinsane 4y ago
let’s say some software has 100,000 users. the maintainer goes bad and wants to steal some users’ bank passwords to profit. if they ship a keylogger to every user, the odds of being noticed before they’re able to cleanly get away are substantially lower than if they ship that to a subset of users. so they may prefer to scam only 100 users, chosen by delivering a malicious payload to only every 1000th curl/https request for the source code. even if one of those users notices, said user will have a tough time confirming and attributing it. now try doing that with a modern package manager. you can’t, because the package manager ensures every user gets the same code. you can still deliver different experiences at runtime — but you’re not likely to have the superuser privileges needed to run a leylogger or read ~/.ssh/id_rsa, etc, at that point. it’s a safety in numbers game. i’m sure you play that game elsewhere in society. i won’t say it’s foolproof, but i’m not sure why it would seem incoherent to you when applied to the digital.
- slimsag 4y ago
  > you can still deliver different experiences at runtime — but you’re not likely to have the superuser privileges needed to run a leylogger or read ~/.ssh/id_rsa, etc, at that point. Keyloggers are trivial to do in userspace Linux via LD_PRELOAD attacks[0], and typically your user account has permission to read ~/.ssh/id_rsa. [0] https://github.com/Aishou/wayland-keylogger https://github.com/Aishou/wayland-keylogger
frumiousirc 4y ago
Main reason I will download and examine instead of blindly run is that often the install script will fail to work as advertised or it will mess up my desired file system conventions. In both cases I'll need to check and perhaps modify the script so it must be bodily downloaded prior to executing. While looking for these problems I also check for obvious malicious instructions.

by tomp 4y ago

deleted 4y ago

[deleted]

ducktective 4y ago

If maintainers of the distro review their accepted packages thoroughly, then apt install would be superior to curl | bash But 9 out of 10 times I used apt install cargo, I've been bitten by dependency hell

jacooper 4y ago

I think its more that the packages are vetted by your distro, but this script isn't, and you don't know what's in it.

tomp 4y ago
Most software I install isn’t distro software, but Python binaries (python, mamba, numpy, pytorch) and packages via pip/mamba/conda.

LilBytes 4y ago

Source in this instance doesn't always mean source code but _the source were you're downloading it from_. If canonical.com tells me to curl $url | sh, I'm fairly confident the script Im downloading is safe. as much as an .iso, .bin or .exe would be. But I'd be a lot more hesitant doing the same from craigs-legit-swe-blog.com.

l33tman 4y ago

I guess it's a question of effort on the side of the person doing the trojan - if enough suckers just copy those snippets regularly you can be lazy and just do it like that, you don't need to go through the hassle of creating fake Ubuntu PPAs with trojans or distribute a big repo on GitHub and risk someone seeing the trojan part.

lexandstuff 4y ago

Before SSL certs were as ubiquitous as they are now, we used to warn about the danger of curl to bash for unsecured URLs, as it's a vector for a DNS spoofing attack. Now that nearly all URLs are HTTPS with valid certificates, the remaining risk seems to be that the host could be intentionally or unintentionally doing something destructive. Sure it would be great to review the code of every install script before you run it, but as you allude to, it isn't practical. Maybe something like ChatGPT could help us here?

colinsane 4y ago

let’s say some software has 100,000 users. the maintainer goes bad and wants to steal some users’ bank passwords to profit. if they ship a keylogger to every user, the odds of being noticed before they’re able to cleanly get away are substantially lower than if they ship that to a subset of users. so they may prefer to scam only 100 users, chosen by delivering a malicious payload to only every 1000th curl/https request for the source code. even if one of those users notices, said user will have a tough time confirming and attributing it. now try doing that with a modern package manager. you can’t, because the package manager ensures every user gets the same code. you can still deliver different experiences at runtime — but you’re not likely to have the superuser privileges needed to run a leylogger or read ~/.ssh/id_rsa, etc, at that point. it’s a safety in numbers game. i’m sure you play that game elsewhere in society. i won’t say it’s foolproof, but i’m not sure why it would seem incoherent to you when applied to the digital.

slimsag 4y ago
> you can still deliver different experiences at runtime — but you’re not likely to have the superuser privileges needed to run a leylogger or read ~/.ssh/id_rsa, etc, at that point. Keyloggers are trivial to do in userspace Linux via LD_PRELOAD attacks[0], and typically your user account has permission to read ~/.ssh/id_rsa. [0] https://github.com/Aishou/wayland-keylogger https://github.com/Aishou/wayland-keylogger

frumiousirc 4y ago

Main reason I will download and examine instead of blindly run is that often the install script will fail to work as advertised or it will mess up my desired file system conventions. In both cases I'll need to check and perhaps modify the script so it must be bodily downloaded prior to executing. While looking for these problems I also check for obvious malicious instructions.