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

curl | sh

curlpipesh.tumblr.com

Post reply on HN
Print view View original

71–80 of 115 posts

Re: curl | sh

#71

Post by sarciszewski »

earthrise wrote: post #14
TeeWEE wrote: post #5

Note that dowloading an app (.exe for windows, or an apple app) and running it, is just as bad. Downloading an installer, and running it, is also insecure. So the question is... What is the proper alternative? I think the best alternatives are appstores such as found on ios and android, right? However that doesnt really fit for open source. Is the way to install open source software, to download the source and compil…

I've written down some general principles we should follow, but any reasonable implementation of them seems pretty far off: https://defuse.ca/triangle-of-secure-code-delivery.htm tl;dr: (1) Reproducible builds, (2) Make sure everyone is getting the same thing (to detect targeted attacks) and (3) Cryptographic signing. Package managers and appstores are the best we have right now, but they're missing (1) and (2). In t…

I'm really surprised this hasn't gotten more attention from the commenters here. :(

^~ To the people scrolling by at 70 mph: READ THIS

Re: curl | sh

#72

Post by dllthomas »

coriny wrote: post #44
mping wrote: post #38

I normally do a curl | less before doing a curl | sh and take a quick peek. Not perfect, but at least it's a step in the right way. Like someone says, it's a matter of trust (but verify).

As already mentioned, save to disk first to avoid network connection failures messing you up. To avoid an extra command use "tee" to output to file while viewing it (i.e. it's "less" and ">" functionality combined).

'To avoid an extra command use "tee" to output to file while viewing it (i.e. it's "less" and ">" functionality combined).'

That's undesirable. First, because you should be making the decision about whether to run the script after you look at it, and if it's already running while you read it then it's probably too late. Second, because you should not be echoing possibly-malicious characters to the terminal - view with less or an editor, tee works like cat here.

Re: curl | sh

#73

Post by mikeash »

michaelmior wrote: post #67
mikeash wrote: post #58

Earlier quoted context omitted.

HTTP pipelining is about reusing a TCP connection for multiple requests. It doesn't influence when curl outputs data and wouldn't apply here anyway. I don't think there's any mode which would cause curl to buffer the entire response before writing any of it.

Yes, I'm aware of how HTTP pipelining works. It was a poor choice of terminology. My point is that by default curl does buffer some of the response. And if the connection was terminated before the first buffer was output, then I would expect this to result in an error which would abort the shell pipeline.

Yes, in some cases curl won't produce any output, like if the web server is down, or the connection fails before anything is returned. And yes, it would also happen if curl buffers some of the response and then dies. I don't really see why that's interesting.

Re: curl | sh

#74

Post by mooreds »

maccard wrote: post #40
cowabunga wrote: post #10

Earlier quoted context omitted.

No it's not because MSI packages and EXEs are signed so there is at least a chain of trust. SmartScreen kicks you in the face if it's not "known" by various metrics and it's hard to get around that these days (as someone who just had to get EV certs for their MSI). If you click through that, and you don't know what the source was then you're a muppet. curl + bash is suck and blam the machine. Hope you didn't do a sud…

> No it's not because MSI packages and EXEs are signed Sure, some are. But most software packages that a user is going to download aren't signed.

Right. And really, who checks signatures?

I'm a developer and I don't think I've every checked an md5 signature of a jarfile/gem/package I've downloaded. Nor have I ever been in an environment where that was ever mentioned. (Have mostly worked in small to medium businesses--I imagine that bigger orgs or the defense department might do this.)

Re: curl | sh

#75

Post by facepalm »

sarciszewski wrote: post #64
facepalm wrote: post #60

Earlier quoted context omitted.

How do you get the public key? I've heard the ssl certificate system that ships with browsers is broken, too. Maybe it would be an improvement to create a small command line tool that ensures https connections and asks for a hash before running a script?

Key management is out of scope for this discussion. Ideally, it's shipped with your OS. If your OS is insecure, you're already vulnerable.

So you are a fan of the solution that you have to pay the OS provider a fee so that they certify your app? Sure, that's a possibility, but hardly conductive to the open web.

Re: curl | sh

#76

Post by sarciszewski »

facepalm wrote: post #75
sarciszewski wrote: post #64

Earlier quoted context omitted.

Key management is out of scope for this discussion. Ideally, it's shipped with your OS. If your OS is insecure, you're already vulnerable.

So you are a fan of the solution that you have to pay the OS provider a fee so that they certify your app? Sure, that's a possibility, but hardly conductive to the open web.

Nope. Don't try to put words in my mouth, please.

apt-get install php-composer is much better than curl https://getcomposer.org/installer | php

Re: curl | sh

#77

Post by michaelmior »

mikeash wrote: post #73
michaelmior wrote: post #67

Earlier quoted context omitted.

Yes, I'm aware of how HTTP pipelining works. It was a poor choice of terminology. My point is that by default curl does buffer some of the response. And if the connection was terminated before the first buffer was output, then I would expect this to result in an error which would abort the shell pipeline.

Yes, in some cases curl won't produce any output, like if the web server is down, or the connection fails before anything is returned. And yes, it would also happen if curl buffers some of the response and then dies. I don't really see why that's interesting.

The default buffer size is typically the page size, which is typically 4096 bytes. I would expect a large number of these scripts to be less than 4096 bytes meaning curl would output nothing before producing an error and the partial script would never be evaluated.

Re: curl | sh

#78

Post by edwintorok »

dllthomas wrote: post #70
edwintorok wrote: post #51

Earlier quoted context omitted.

Why should shells encourage this behaviour (piping unknown stuff to them?) You should at least download, verify the size and checksum (if available), take a peek at it, and only then run it.

Because you might be piping known stuff to them. Receiving a partial input stream is not necessarily reliant on networking.

OK, but the detection of partial vs complete script is not as simple as 'does last line have EOL'? There are various builtins that require an end token, like case/esac, if/fi, etc. Do these work properly when truncated at an arbitrary line?

Re: curl | sh

#79

Post by coriny »

dllthomas wrote: post #72
coriny wrote: post #44

Earlier quoted context omitted.

As already mentioned, save to disk first to avoid network connection failures messing you up. To avoid an extra command use "tee" to output to file while viewing it (i.e. it's "less" and ">" functionality combined).

'To avoid an extra command use "tee" to output to file while viewing it (i.e. it's "less" and ">" functionality combined).' That's undesirable. First, because you should be making the decision about whether to run the script after you look at it, and if it's already running while you read it then it's probably too late. Second, because you should not be echoing possibly-malicious characters to the terminal - view wit…

"First, because you should be making the decision about whether to run the script after you look at it" - exactly, which is what my suggestion is. All I'm suggesting with tee is that it allows you to read in terminal what you are writing to file in the same command. The OP was downloading the script to view in less, and then downloading it again to execute. This method at least ensures that what you view is what you are going to execute but ...

"Second, because you should not be echoing possibly-malicious characters to the terminal" - this is something I know nothing about, so I would be (and maybe others) highly appreciative of any links about this class of attacks that you could post. Is it possible to execute malicious code while writing to STDOUT, or is it because you can hide malicious code with escape characters? Also, I don't quite understand the "cat" comment as we're not doing any file concatenation here?

Re: curl | sh

#80

Post by marcusramberg »

sarciszewski wrote: post #21
TimWolla wrote: post #4

At least most of the examples are using https.

Mojolicio.us is a good counter-example. Unfortunately, they're not on the Tumblr yet.

Unfortunately the default way of installing Perl modules (cpan command line tool). is just as insecure as curl | sh - Note that we have added an example of securely installing Mojo on the homepage as well, if you have configured Perl for signature verification - http://mojolicio.us/
Post reply on HN