Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Curl to shell isn't so bad

arp242.net

Post reply on HN
Print view View original

41–50 of 201 posts

Re: Curl to shell isn't so bad

#41

Post by marcthe12 »

Un1corn wrote: post #22
Carpetsmoker wrote: post #20

Earlier quoted context omitted.

If people have access to change the content of the script then they can also change foo-1.2.3-src.tar.gz or foo-1.2.3-linux-amd64.gz. These are all general problems with downloading anything from the internet.

Right but the attacker can make it look legit even for someone that look at the script. The attacker can change the content of the script by the user agent or even by detecting when you pipe it to bash[0] [0] https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...

Well there is a way to resolve that. Have command in between curl and sh that effectively only prints to stdout once stdin receive EOF. A double tac is an xample

Re: Curl to shell isn't so bad

#42

Post by m0xte »

Arnt wrote: post #34
sjy wrote: 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 int…

Yes. I had a pretty bad one from a commercial software company. Running any script someone else wrote badly intentionally or otherwise is dangerous. The source is moot. Rather than provide distribution packages they had a shell script that installed and updated their stuff. If you ran the update script it would evaluate rm -rf $(SOFTWARE_ROOT)/

That environment variable was not set if the software hadn’t been installed and it wouldn’t run unless it was a root shell.

Guess who ran the update script instead of the install script and hosed the machine? I gave them a whole lifetime of bile over that.

The product turned out to be horrible as well.

Re: Curl to shell isn't so bad

#43

Post by blablabla123 »

sjy wrote: 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.

It's also already more than a decade ago. But a friend of mine wanted to format a USB stick. So there was this tutorial online how to do it. I'm not sure if he copy&pasted it or typed the command himself. But anybody who used dd a lot, knows what happened, he damaged his root filesystem irreversibly by pointing to the wrong disk. I think repairing damaged filesystems with Norton suite or so was never a thing on Linux... ;)

Long story short, even when typing well intended shell commands, you can damage your system. (Even on Windows or macOS!) Directly piping curl into bash shows a lot of trust. It's amazing how well-intended the web is, must be at least 99,999999%

That said, I cannot count how many times following some tutorial blindly/some shell based installer made my carefully crafted *nix installation a bit worse. Nonetheless, most adware/spyware/malware I got through commercial download websites I think.

Re: Curl to shell isn't so bad

#45

Post by minitech »

Carpetsmoker wrote: post #11
LIV2 wrote: post #7

I disagree with some of this, I.e paste jacking. Plenty of software projects put more care and focus into their software and not in their website, if you're running a vulnerable version of Wordpress or whatever CMS it'd be easy for someone to insert something malicious without being noticed whereas something that modified your code would show up in git, code reviews etc

Pastejacking should be mitigated if you use zsh, as it will never run pasted commands automatically. From quick test it seems that recent(?) versions of bash also implemented this feature and have it enabled by default. I don't know about fish or other shells.

Not running pasted commands automatically isn’t a security feature on its own, because the paste “brackets” of bracketed paste can be inside the clipboard. It’s kind of ridiculous that most terminal emulators don’t defend against that by default.

Re: Curl to shell isn't so bad

#46

Post by zshev »

y4mi wrote: post #33
tastroder wrote: post #31

Earlier quoted context omitted.

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…

> It opens you up to a literally undetectable attack.

This is the crux of it for me. This is why it is dangerous. The author appears to have overlooked this attack vector entirely.

Re: Curl to shell isn't so bad

#47

Post by Carpetsmoker »

LIV2 wrote: post #21
tonyedgecombe wrote: post #17

Earlier quoted context omitted.

Is that really much of a problem? I can't remember the last time I had a download fail part the way through and they are usually much bigger than a bootstrapping script.

I mean it's unlikely but imagine it did happen and something in the script like "rm -rf /some/path" gets truncated to "rm -rf /" & immediately run Even if your connection is TLS secured an MITM attack of causing a connection reset after X bytes could be a viable attack

As was pointed out both in the article and the comments here, this is easily addressed by wrapping everything in a function (or subshell, for that matter).

Re: Curl to shell isn't so bad

#48

Post by bonoboTP »

yoavm wrote: 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…

The package manager is only an option if you have root rights. Otherwise you either download binaries or compile it yourself, from the source downloaded from their website.

Re: Curl to shell isn't so bad

#49

Post by forty »

> There is no fundamental difference between curl .. | sh versus cloning a repo and building it from source

I would say it depends. If the commits are signed by a key you know it's probably better. Even if it's not the case, cloning with SSH if you know the host key is also slightly better than downloading through HTTPS where any (compromised) trusted CA can MITM your connection :) (you can argue that those to use cases are rare in practice, and I would agree with you ;))

Re: Curl to shell isn't so bad

#50

Post by Boulth »

kijin wrote: post #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 i…

The problem with deb, rpm, etc is that you need to add instructions to all supported systems one by one. Check out this site for reference: https://www.sublimemerge.com/docs/linux_repositories and compare with curl URL|sh that can detect target system and delegate to appropriate system. Much simpler.

The root cause of this is no universal packaging format for Linux in my opinion.

Post reply on HN