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

51–60 of 201 posts

Re: Curl to shell isn't so bad

#51

Post by dmitriid »

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…

What’s the difference between a curl you blindly pipe into sh and a blind brew install/npm install command?

Re: Curl to shell isn't so bad

#53

Post by aasasd »

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

This is pretty much the only real answer to the article. However, if the software itself is distributed via the site then the same caveat applies since replacing the release itself is much more enticing. It comes down to either the software being published on Github where a hijacked release might be noticed, and/or files having signatures that you can somehow trust.

Re: Curl to shell isn't so bad

#54

Post by mike_hock »

marcthe12 wrote: post #41
Un1corn wrote: post #22

Earlier quoted context omitted.

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

Or, you know, pipe to a file and verify the content, then execute.

Re: Curl to shell isn't so bad

#55

Post by aasasd »

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…

Funny thing, I've pasted wrong text into the terminal on multiple occasions—from having copypasted some paragraphs of text and immediately forgetting about that. Each time I expect my files to be botched, but the worst that's happened so far is some unwanted files appearing due to ‘>’ being there in the text.

Re: Curl to shell isn't so bad

#56

Post by nabdab »

m0xte wrote: post #39
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.

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…

The element of you story that deals with how you distributed your solution has no relevance to the rest of it. You could have been using any type of distribution it’s irrelevant that you actually used curl. If people trust you and ru. Your code, you can abuse that trust.

You could argue that by not having high quality independent third party review on a controlled market place (like the Apple App Store) has security implications. Because that would have checked for and vetted against abuse. But again this has nothing to do with curl.

Re: Curl to shell isn't so bad

#57

Post by Carpetsmoker »

LIV2 wrote: post #52
hqrlk wrote: post #37

https://arp242.net/images/me.jpg

Possibly related to how the author of the article is downvoting everything

The only two posts I've downvoted are your two "partial content" posts because they only repeat a point that is addressed in the article without adding any form of rebuttal or even recognition that it's even mentioned in the article.

I have no idea what the point of posting that link is shrug, so I downvoted that too

Re: Curl to shell isn't so bad

#58

Post by mehrdadn »

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

How is this any different from just downloading a binary from their website and running it? Which people have been doing for ages?

Re: Curl to shell isn't so bad

#59

Post by lozf »

Boulth wrote: post #50
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.

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

Which some have attempted to solve, so now we also have Flatpack, AppImage, and Snap -- each with their own little issues.

Re: Curl to shell isn't so bad

#60

Post by eavotan »

> Not knowing what the script is going to do.

This is more like: not knowing what to do, when it doesn't work. And this is always the case until it works. Which is just a local Phenomenon and i can't expect things that work for me to work for others. So why don't write an expressive installation documentation with multiple steps instead of one-liners that either work or don't. There is just no in between.

Take the installation instruction of syncthing for example:

    curl -s https://syncthing.net/release-key.txt | sudo apt-key add -

    echo "deb https://apt.syncthing.net/ syncthing stable" | sudo tee /etc/apt/sources.list.d/syncthing.list
These two steps are hard to automate, if you don't have an interactive shell.

Same goes for the saltstack-boostrap-script. This script doesn't work on all platform equally good. This is not an reliable state. So in the end I'll stick with the normal way to install things which is very easy to automate.

Post reply on HN