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

191–200 of 201 posts

Re: Curl to shell isn't so bad

#191

Post by y4mi »

tln wrote: post #167
vbezhenar wrote: post #148

Earlier quoted context omitted.

Is it undetectable? `curl | tee file | bash` should detect IMO.

True, you can detect it without a way to stop the damage! Or easier and more thorough, curl | bash -x

Piping through tee doesn't trigger the sever side detection (it doesn't stop to read every few ms) and using the x flag isn't inherited, so it's gone as soon as subshells are invoked, which is pretty normal for an installation script.

This has all been mentioned in the linked comment thread

Re: Curl to shell isn't so bad

#192

Post by dickeytk »

brianpgordon wrote: post #190
jsjohnst wrote: post #144

Earlier quoted context omitted.

> In the case of Homebrew, the package manager pulls down the program directly from upstream and installs it. Sure, in the most basic case it does this, but even in the most basic case it does more than that. At minimum it also verified the download matches a known good hash. The important part (to me) is that Homebrew also ensures the package installed conforms to Homebrew’s standard. There’s a lot of standards (ins…

How exactly is the file going to get tampered with if you're using curl-to-sh? Everyone uses HTTPS nowadays. Validating the hash is not really doing anything significant. As for ensuring that the package is well-behaved, could you elaborate on that? I'm not aware of Homebrew doing something like chrooting to /usr/local before running the install script. And the install script can do anything as your local user, same…

They do chroot. You can only install to specific directories

Re: Curl to shell isn't so bad

#193

Post by brianpgordon »

dickeytk wrote: post #192
brianpgordon wrote: post #190

Earlier quoted context omitted.

How exactly is the file going to get tampered with if you're using curl-to-sh? Everyone uses HTTPS nowadays. Validating the hash is not really doing anything significant. As for ensuring that the package is well-behaved, could you elaborate on that? I'm not aware of Homebrew doing something like chrooting to /usr/local before running the install script. And the install script can do anything as your local user, same…

They do chroot. You can only install to specific directories

Ah, I found it. On MacOS they rely on sandbox-exec which uses the sandboxing mechanism provided by the kernel:

https://github.com/Homebrew/brew/blob/e2c76cce8e01fd80e0910d...

https://github.com/Homebrew/brew/blob/master/Library/Homebre...

Re: Curl to shell isn't so bad

#194

Post by tln »

y4mi wrote: post #191
tln wrote: post #167

Earlier quoted context omitted.

True, you can detect it without a way to stop the damage! Or easier and more thorough, curl | bash -x

Piping through tee doesn't trigger the sever side detection (it doesn't stop to read every few ms) and using the x flag isn't inherited, so it's gone as soon as subshells are invoked, which is pretty normal for an installation script. This has all been mentioned in the linked comment thread

Actually the server side detection in [0] isn't really affected by putting tee in the middle... and neither does -x, of course.

Good point about -x being fallible to an adversarial script, even a simple set +x would be enough!

Where's the link where this has been mentioned? I missed it.

0: https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...

Re: Curl to shell isn't so bad

#195

Post by jsjohnst »

brianpgordon wrote: post #190
jsjohnst wrote: post #144

Earlier quoted context omitted.

> In the case of Homebrew, the package manager pulls down the program directly from upstream and installs it. Sure, in the most basic case it does this, but even in the most basic case it does more than that. At minimum it also verified the download matches a known good hash. The important part (to me) is that Homebrew also ensures the package installed conforms to Homebrew’s standard. There’s a lot of standards (ins…

How exactly is the file going to get tampered with if you're using curl-to-sh? Everyone uses HTTPS nowadays. Validating the hash is not really doing anything significant. As for ensuring that the package is well-behaved, could you elaborate on that? I'm not aware of Homebrew doing something like chrooting to /usr/local before running the install script. And the install script can do anything as your local user, same…

> Validating the hash is not really doing anything significant.

Yes it is, it’s ensuring that what the maintainer of the formula verified is still what’s being downloaded now. HTTPS does nothing to protect someone modifying the source URL, but the hash does that (assuming the maintainer actually inspected the initial download, which many if not most do).

> but given that most formulas download code from the Internet and run it, that's not much help.

1) the previously erroneously dismissed hash helps there.

2) the sandbox which you linked to later also helps too.

Re: Curl to shell isn't so bad

#196

Post by theamk »

nimih wrote: post #181
theamk wrote: post #176

Earlier quoted context omitted.

Their argument is this: > you’re already trusting the vendor and site, and you’re already going to run the software that install.sh downloads. I don't see how this makes sense? People do check what they run, and especially for sudo-calling commands.

If the folks at rust-lang.org are malicious and willing to put in some extremely customized web-server logic to serve up evil code when they think it won't be noticed, why wouldn't they just sneak it into ./configure or some unnoticed corner of the compiler's source or the standard library or a precompiled binary? To be clear, when I go to rust-lang.org, my goal is to download a large amount of extremely complex code…

I disagree. I think "webserver got hacked, and no one noticed" is a very realistic threat model. The webpage tells me to get a script from "sh.rustup.rs" -- what is the security behind this server? How can I be sure that it was not hacked? If the server was hacked, how long would it be before the hack it is detected?

I have full trust in Rust team, but even kernel.org was hacked once! And the worst part, experienced users won't likely to notice that installer does something weird -- because it is fully opaque, and because it

An alternative approach is a manual "git clone". This is way more secure, because the same endpoint and protocol is used by both new users and devs doing daily work.

Can someone compromise dev account and backdoor git repo? Sure. How long before this is detected? Not very long at all, I bet there are people who work on Rust and watch every incoming change.

Re: Curl to shell isn't so bad

#198

Post by brianpgordon »

jsjohnst wrote: post #195
brianpgordon wrote: post #190

Earlier quoted context omitted.

How exactly is the file going to get tampered with if you're using curl-to-sh? Everyone uses HTTPS nowadays. Validating the hash is not really doing anything significant. As for ensuring that the package is well-behaved, could you elaborate on that? I'm not aware of Homebrew doing something like chrooting to /usr/local before running the install script. And the install script can do anything as your local user, same…

> Validating the hash is not really doing anything significant. Yes it is, it’s ensuring that what the maintainer of the formula verified is still what’s being downloaded now. HTTPS does nothing to protect someone modifying the source URL, but the hash does that (assuming the maintainer actually inspected the initial download, which many if not most do). > but given that most formulas download code from the Internet…

I suppose it comes down to whether the Homebrew maintainer who accepts the formula PR containing the hash is actually examining the upstream code in detail. I think that is unlikely; there's too much code for Homebrew maintainers to be experts on everything contained in homebrew-core and follow every single patch.

So yes, the hash prevents the upstream project from switching out the code at any time, but if they wanted to add some malicious code all they have to do is file a homebrew-core PR and hide it in a legitimate change.

Re: Curl to shell isn't so bad

#199

Post by jsjohnst »

brianpgordon wrote: post #198
jsjohnst wrote: post #195

Earlier quoted context omitted.

> Validating the hash is not really doing anything significant. Yes it is, it’s ensuring that what the maintainer of the formula verified is still what’s being downloaded now. HTTPS does nothing to protect someone modifying the source URL, but the hash does that (assuming the maintainer actually inspected the initial download, which many if not most do). > but given that most formulas download code from the Internet…

I suppose it comes down to whether the Homebrew maintainer who accepts the formula PR containing the hash is actually examining the upstream code in detail. I think that is unlikely; there's too much code for Homebrew maintainers to be experts on everything contained in homebrew-core and follow every single patch. So yes, the hash prevents the upstream project from switching out the code at any time, but if they want…

> I think that is unlikely; there's too much code for Homebrew maintainers to be experts on everything contained in homebrew-core and follow every single patch.

By that logic, everything in any package manager should be treated with distrust then. Debian, RHEL, Arch, etc etc.

Not saying I disagree with distrusting, just making the point that risk exists everywhere, at some point you have to decide what you’re comfortable with.

Re: Curl to shell isn't so bad

#200

Post by brianpgordon »

jsjohnst wrote: post #199
brianpgordon wrote: post #198

Earlier quoted context omitted.

I suppose it comes down to whether the Homebrew maintainer who accepts the formula PR containing the hash is actually examining the upstream code in detail. I think that is unlikely; there's too much code for Homebrew maintainers to be experts on everything contained in homebrew-core and follow every single patch. So yes, the hash prevents the upstream project from switching out the code at any time, but if they want…

> I think that is unlikely; there's too much code for Homebrew maintainers to be experts on everything contained in homebrew-core and follow every single patch. By that logic, everything in any package manager should be treated with distrust then. Debian, RHEL, Arch, etc etc. Not saying I disagree with distrusting, just making the point that risk exists everywhere, at some point you have to decide what you’re comfort…

To some extent, sure, but I think that extent is greater with Homebrew. It's my understanding that package maintainers for Debian, RHEL, etc are typically experts in the packages that they maintain. They overlay their own patches to ensure compatibility and submit patches upstream. With Homebrew there's only a small number of committers who maintain the homebrew-core repository, accepting PRs from thousands of people in the community. It's just a different situation.
Post reply on HN