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

121–130 of 201 posts

Re: Curl to shell isn't so bad

#121

Post by marcosdumay »

manojlds wrote: post #79
andreareina wrote: post #76

My experience is that software that installs via curl|bash tends to ignore my preferences as expressed via $PREFIX/DESTDIR, $XDG_{CACHE,CONFIG,DATA}_HOME, etc. It'll install who-knows-where and probably leave dotfiles all over my home directory. Maybe curl|bash is functionally equivalent to git clone && ./configure && make && make install, but my bet is on the one providing a standard install flow to be a better gues…

The curl|bash might actually clone a repo and build it. Your concern is a different one.

Yes, it could. But it that was the case, the site would say one can just clone the repo and build it instead of sending everybody into the curl route.

Re: Curl to shell isn't so bad

#122

Post by titanomachy »

esotericn wrote: post #117

For the most part this is a problem with non-rolling-release distros. There are very few instances in which I've had to even use an installer on Arch. For many of those cases, the AUR provides a package that verifies the hash of the downloaded file anyway. I've constantly been frustrated when using Ubuntu because something basic like having 'vim' not be months out of date requires a PPA. The 'official' Rust installat…

Rolling-release and fixed-version distros serve different purposes. A fixed-version OS has a set of software packages at specific versions which have been tested together, both by test suites and by the many users using the same version set. Security patches and bugfixes get patched in, but the packaged software doesn't undergo major changes. That's important if you're running a critical production system.

Rolling-release systems are awesome for personal machines where you can handle breaking updates or work around them. Usually I want the latest versions of everything when I'm doing exploratory stuff.

That said, modern software deployment is definitely moving away from "pick an LTS Linux distro and only change your application code", instead we mostly use containers now. A lot of production systems are probably still using the older technique though.

Re: Curl to shell isn't so bad

#123

Post by theamk »

akerl_ wrote: post #71
eadmund wrote: post #68

> There is no fundamental difference between curl .. | sh versus cloning a repo and building it from source. Not true: when you clone a repo with signed commits, you have forensic evidence that the repo signer provided the code you ran, while when you use curl you have … just the code itself. That's not a lot , but it's not nothing .

How many repos are there that actually sign commits, and of those, how many users are doing validation that the signer of their local checkout’s commits is actually the key they expected? The line you’ve quoted doesn’t say that there’s no fundamental difference between curl | sh and cloning a repo with signed commits, and I think it’s a stretch to think signed commits have enough usage among devs / users to make them…

I don't think signing commit matters. What matter is that if webserver is compromised, very few people are likely to notice, and the evidence can be gone at any time.

But if github repo is compromised, anyone who pullls the repo can notice strange commits - and the evidence cannot disappear, as public head rebase will bring even more scrutiny.

Re: Curl to shell isn't so bad

#124

Post by titanomachy »

hannob wrote: post #36
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…

> 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 co…

Making Debian packages is a colossal pain in the ass, or at least it's poorly documented. I've tried to learn it twice and abandoned it for more user-friendly solutions to the problem.

Some people may say I'm stupid for not figuring it out, but the standard for usability of software has improved a lot since these systems were invented. The UX needs a serious overall.

Re: Curl to shell isn't so bad

#125

Post by mceachen »

paulddraper wrote: post #116
brianpgordon wrote: post #89

Earlier quoted context omitted.

It seems like you're assuming that there's someone vetting these packages. For enterprise distros like Red Hat that's certainly true. Community package maintainers in, for example, the Debian project provide some safety as well. But there are plenty of package managers where that's just not the case. In the case of Homebrew, the package manager pulls down the program directly from upstream and installs it. It's exact…

npm removes malware when reported.

s/when/if/

Fixed that for you.

Re: Curl to shell isn't so bad

#126

Post by acdha »

paulddraper wrote: post #116
brianpgordon wrote: post #89

Earlier quoted context omitted.

It seems like you're assuming that there's someone vetting these packages. For enterprise distros like Red Hat that's certainly true. Community package maintainers in, for example, the Debian project provide some safety as well. But there are plenty of package managers where that's just not the case. In the case of Homebrew, the package manager pulls down the program directly from upstream and installs it. It's exact…

npm removes malware when reported.

Which is repeating that sources matter: curl from a source like Github with a solid abuse process is a very different story than an unknown server.

Re: Curl to shell isn't so bad

#127

Post by acdha »

titanomachy wrote: post #124
hannob wrote: post #36

Earlier quoted context omitted.

> 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 co…

Making Debian packages is a colossal pain in the ass, or at least it's poorly documented. I've tried to learn it twice and abandoned it for more user-friendly solutions to the problem. Some people may say I'm stupid for not figuring it out, but the standard for usability of software has improved a lot since these systems were invented. The UX needs a serious overall.

It’s improved a lot but also consider how many people use FPM to generate multiple formats very easily.

Re: Curl to shell isn't so bad

#128

Post by mceachen »

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.

I've had a server become unbootable after applying a curl|sh (and I actually wget'ed, skimmed the script, then executed), and it errored out. I'd just taken a backup so I didn't do much forensics before I restored.

I know, badware ≠ malware

Re: Curl to shell isn't so bad

#129

Post by fwip »

hising wrote: post #24
paxy wrote: post #15

The average non-technical user is never going to open up the terminal and run commands. The well educated technical user is going to be vary of untrusted sites and various forms of attacks (which I'm assuming the author of this post falls under). IMO this is good advice for those that fall in the middle of these two categories, i.e. slightly technical people who run into problems and copy-paste solutions from Stack O…

> copy-paste solutions from Stack Overflow On the other hand, a solution on SO that would be a hidden attack would not gain upvotes and be an alternative for the one seeking advice there.

Depends on how hidden it is.

Re: Curl to shell isn't so bad

#130

Post by tedunangst »

valleyer wrote: post #38
avaloneon wrote: post #28

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.

You might be interested to read that the timing attack doesn't rely on user agent. It detects what curl is feeding the output into.
Post reply on HN