Live data from Hacker News

Curl to shell isn't so bad

arp242.net

31–40 of 201 posts

Re: Curl to shell isn't so bad

#31

I'm surprised that no one has yet mentioned that piping curl to bash can be detected by the server (previous discussion at https://news.ycombinator.com/item?id=17636032 ). This allows an attacker to send different code if it's being piped to bash instead of saved to disk. IMHO, "curl to shell" is uniquely dangerous, since all the other installation vectors mentioned don't support the bait-and-switch.

An unmodified curl invocation does not require weird timing based attacks, it sends an appropriate user-agent header the server can use (and which the article already adresses).

Re: Curl to shell isn't so bad

#32
I ran into this recently at work. I wanted to write a script that you could curl into bash to quickly set up some common tools.

Firstly, I made sure that the script told you what it would do before doing it.

Secondly, my instructions are two lines. Curl to a file, then run it through bash. A compromise, but if you mistrust the script, you can inspect it yourself before running it.

Re: Curl to shell isn't so bad

#33

I'm surprised that no one has yet mentioned that piping curl to bash can be detected by the server (previous discussion at https://news.ycombinator.com/item?id=17636032 ). This allows an attacker to send different code if it's being piped to bash instead of saved to disk. IMHO, "curl to shell" is uniquely dangerous, since all the other installation vectors mentioned don't support the bait-and-switch.

An unmodified curl invocation does not require weird timing based attacks, it sends an appropriate user-agent header the server can use (and which the article already adresses).

different attack vector.

by detecting the usage of `curl | bash` you can serve a different script only when someone does it, so someone doing `curl -O /tmp/some_script.sh` to audit the script wont see the harmful code.

It opens you up to a literally undetectable attack.

nonetheless, the point of the article author does have some truth. there is always a degree of trust involved when you're installing binaries from a third party. by using curl|bash you're just increasing the required trust a bit.

Re: Curl to shell isn't so bad

#34
post #30

Has running a curl-to-bash command found during normal user-initiated web browsing ever resulted in a malware infection? Even anecdotal evidence would be valuable at this point.

Not as far as I know, but I have heard about people pasting the Wrong Thing into a root shell.

In a way it's a casting error. A type safety violation. You paste text into a privileged shell and coerce it to be sh, and when it goes wrong the sh input is rich in characters.

Friends of mine have mentioned at least a) people accidentally pasting much more than the intended line into sh because they selected more than intended and b) sites that modify the cut buffer silently to add some "pasted from … blah … like us on facebook" or somesuch, I forget the details. The person who wrote the page intended one line to be castable to sh, another person who worked on the site added the script that transformed the cut/paste without realising that.

Re: Curl to shell isn't so bad

#35
Not so bad comparing to what? Yeah, comparing to downloading a tar file from the website and running ./configure, make etc - right, it's probably quite a similar risk. But who does that?

Every decent Linux distro has a package manager that covers 99% of the software you want to install, and comparing to an apt-get install, pacman -S, yum install and so on - running is a script off some website is way more risky. My package manager verifies the checksum of every file it gets to make sure my mirror wasn't tempered with, and it works regardless of the state of the website of some random software. If I have to choose between a software that's packaged for my package manager and one I have to install with a script - I'll always choose the package manager. And we didn't even start to talk about updates - as if that isn't a security concern.

The reason we should discourage people from installing scripts of the internet is because it would be much better if that software would just be packaged correctly.

Re: Curl to shell isn't so bad

#36
post #35

Not so bad comparing to what? Yeah, comparing to downloading a tar file from the website and running ./configure, make etc - right, it's probably quite a similar risk. But who does that? Every decent Linux distro has a package manager that covers 99% of the software you want to install, and comparing to an apt-get install, pacman -S, yum install and so on - running is a script off some website is way more risky. My p…

> Every decent Linux distro has a package manager that covers 99% of the software you want to install

I wish this were true, but plenty of experience with Linux usage tells me that not having something packaged is a very common occurence.

Though of course this can be improved: More people should actually help working on their favorite Linux distro, so more software gets packaged. And upstreams should try better to collaborate with distros, which unfortunately they rarely do.

Re: Curl to shell isn't so bad

#38

I'm surprised that no one has yet mentioned that piping curl to bash can be detected by the server (previous discussion at https://news.ycombinator.com/item?id=17636032 ). This allows an attacker to send different code if it's being piped to bash instead of saved to disk. IMHO, "curl to shell" is uniquely dangerous, since all the other installation vectors mentioned don't support the bait-and-switch.

You might be interested to read the section titled "User-Agent based attacks" of the linked article.

Re: Curl to shell isn't so bad

#39
post #30

Has running a curl-to-bash command found during normal user-initiated web browsing ever resulted in a malware infection? Even anecdotal evidence would be valuable at this point.

A close anecdote. I posted one on IRC about 15 years ago, before this was even a thing, which called home by calling curl to an endpoint I controlled only. The sales pitch for the script was setting up vim properly which it did do. 80% of the downloads executed instantly. I had 12 people run the script. No one read it first or downloaded it and ran it as the request count matched the callback count exactly and there wasn’t more than a couple of seconds before the request and callback.

After the fact I realised I should have put if the account was root or not in the callback!

Alas all it needs is some trust and a sales pitch and someone will run it. At the time I didn’t think of the security consequences until after I had done it.

Re: Curl to shell isn't so bad

#40
I hate install scripts, period. They feel so Windows-ish. Just distribute a .deb, .rpm, .snap, homebrew package, npm package, or whatever is the most appropriate for your software. All the scripting you need to do should be done inside of the regular package installation process, and even that should be kept to a minimum.

The only software that has any right to rely on an ad-hoc install script on a Unix-like system is the package manager itself. It's awful enough that I have to do apt update and npm update separately. Please don't add even more ways to pollute my system.

Post reply on HN