One difference is that piping to a shell is a lot easier to inspect. So you could easily argue that piping to a shell is safer.
Heck, even downloading a source tarball and compiling it yourself isn't any safer unless you actually inspect that source. And who does that?
The issue isn't executing untrusted code, it's connections terminating early and causing your shell to execute incomplete code.
The article ends with the example code
TMP_DIR=`mktemp`
rm -rf $TMP_DIR
Statistically a cosmic ray flips a few bits in your RAM every year. Theoretically those bit flips could transform a benign program into a malicious one, and I'm sure that's happened to somebody somewhere sometime.
But it's very unlikely to happen to you tomorrow. You could use ECC RAM to prevent this from happening, but how many people do that?
> This might be unlikely, but the results of this happening, even once, could be catastrophic.
Also, you don't have to kill any process, that was a PoC by the author. The scenario is a connection drop.
I haven't.
> Bug: Update the nginx (?) error pages to be bash friendly
>
> root@marius ~]# curl -s https://lv.linode.com/nGiB | sudo bash
> bash: line 1: html: No such file or directory
> bash: line 2: syntax error near unexpected token `<'
> 'ash: line 2: `<head><title>502 Bad Gateway</title></head>
>
> This could be done by just dumping out echo statements since its already
> being parsed by the shell. Additional meta about the request (headers, etc)
> could be dumped into comments too…
>
> # 502 Bad Gateway
> echo
> echo "Uh oh: Something went sideways during the install!"
> echo "("
> echo "Re-running the installer should clear things up."
> echo
> echo " sudo !!"
> echoMany wouldn't.
wget -O - https://example.com/install.sh | sudo sh
Turns into this:
wget -O install.sh https://example.com/install.sh && sudo sh ./install.sh
Big deal.
EDIT: Changed protocol to https for FiloSottile.
EDIT: Thanks <3
Straw man.
No it doesnt turn into that, it turns into wget https://install.sh && ls && less install.sh && less lala2 && echo "ok looks good enough" && ./install.sh # no sudo, to user local install, its just a package or program ffs,
when you want packages to install for all users, or system wide, then you use the default package manager of your distribution.
function install_my_software() {
...
}
install_my_software()
It just seems to me that the main should worry about interfacing with the outside world, and the rest of your code should really just be written as a library.
I made a utility "shacat", which takes a sha1 checksum as an argument and then pipes input to output iff the sum of input matches the sum
e.g.
$ curl http://site.com/script | shacat 7ef39183 | sh
Of course, getting people to use shacat is the hard part
Why that? Have we never heard of defaced web pages?
Granted, using shacat is much better than piping into sh. But basic learning from security breaches is that nothing is safe, you only can find ways to do thing in a less catastrophic manner than others.
Well if you can't trust the website you're screwed anyway. If the website is compromised then absolutely any way they have of installing software is broken
Its only really bad if some does the following:
rm -rf /$TMP_DIR
rm -rf $TMP
rm -rf /
Also, both:
rm -rf $TM
rm -rf $TMP_
> running arbitrary commands on your machine that could change based on user agent to trick you
Without even considering MitM, that running signed executables kind of mitigates.
Anyway, the point of the author is the failing mode.
Absolutely not. The author points out 1 way in which stupid inspecting could be beaten, however you can always do
$ curl https://coolscript.com/script > tmp.sh
$ cat tmp.sh
echo "I'm safe!"
$ ./tmp.shTo avoid users complaining about how dangerous it is.
This is why I distribute a tarball with an installer script in it. It's functionally almost the same, not that much harder, but it avoids all the backlash and makes my software more likely to be used.