echo "!!! Very EXPERIMENTAL new code v0.0.2 !!!"
echo "!!! It may or may NOT WORK AND DELETE ALL YOUR DATA !!!"
...right after the $(id -u) != 0 "are you root" check. Neat. The first 10 lines are "TODO fix foobar". set -x is commented out, also no -o pipefail. Last two lines are sleep 23 (magic numbers, anyone?) and echo "Takeover probably failed." - no matter if it failed or not ;-p
Not even starting about the dozen mounts that never get checked. Guess OP never had a full disk \^\^
Finally, the obvious: never run random code, especially not as root. The script downloads several binaries and archives:
I've never really understood this advice. Don't run any scripts from a random nobody on a forum or do so with extreme caution. But if you're installing software direct from the developer you've already decided to trust them completely at that point.
If you're really interested in an explanation behind this advice, I'll provide it. Without getting into a deep technical discussion, it's all about verification.
Just because I trust the developer who created the software I want to install on my system doesn't mean that I trust that developer's web hosting service or any of the other intermediaries (like ISPs) that might come between us. It is trivial to provide a URL where a regular browser or other tool designed to view the information would see one (safe) version of a shell script, and the curl binary would see a different (compromised) version of a shell script. Anyone involved in the communication chain between me and the developer can screw with that if they have the technical expertise of a first-year CS student.
If you use a packaging system with a signing algorithm, then you can verify the signature and confirm that the source code you wanted from the developer you trust is the source code you received across an insecure medium.
You sound like the type of person that would tick the "i agree" box without first having read the terms and conditions, or one who doesn't check that the hash of a download matches the one listed on the website..... /s
I largely agree with you though, trust is a huge part of it and there's not a lot of difference between "hey curl -> shell this installer" and "hey add this PPA, or this apt repo". There's a level of trust needed regardless. There are edge cases for the more highly protective, particularly in the context of the link being on a 3rd party site like reddit. Homograph attacks come to mind, which you're less likely to notice in a curl to shell scenario than you are in other ways, though again granted there's certainly no guarantee you'll catch it with other methods either.
tldr: yes, trust is an important part, but curl -> shell relies solely on that trust and offers no other checks and balances to help establish that trust.
Before curl-shell most install commands instructions would point you to your distro's repo (ex: sudo apt install ...). But devs be lazy and getting your app into multiple different upstream packages is difficult and time consuming.
KlePu@reddit
From the code:
...right after the
$(id -u) != 0
"are you root" check. Neat. The first 10 lines are "TODO fix foobar".set -x
is commented out, also no-o pipefail
. Last two lines aresleep 23
(magic numbers, anyone?) andecho "Takeover probably failed."
- no matter if it failed or not ;-pNot even starting about the dozen
mount
s that never get checked. Guess OP never had a full disk \^\^Finally, the obvious: never run random code, especially not as root. The script downloads several binaries and archives:
Very good way to catch yourself some malware!
franktheworm@reddit
Curl to shell? Hard pass.
UrbanPandaChef@reddit
I've never really understood this advice. Don't run any scripts from a random nobody on a forum or do so with extreme caution. But if you're installing software direct from the developer you've already decided to trust them completely at that point.
PracticalPersonality@reddit
If you're really interested in an explanation behind this advice, I'll provide it. Without getting into a deep technical discussion, it's all about verification.
Just because I trust the developer who created the software I want to install on my system doesn't mean that I trust that developer's web hosting service or any of the other intermediaries (like ISPs) that might come between us. It is trivial to provide a URL where a regular browser or other tool designed to view the information would see one (safe) version of a shell script, and the curl binary would see a different (compromised) version of a shell script. Anyone involved in the communication chain between me and the developer can screw with that if they have the technical expertise of a first-year CS student.
If you use a packaging system with a signing algorithm, then you can verify the signature and confirm that the source code you wanted from the developer you trust is the source code you received across an insecure medium.
franktheworm@reddit
You sound like the type of person that would tick the "i agree" box without first having read the terms and conditions, or one who doesn't check that the hash of a download matches the one listed on the website..... /s
I largely agree with you though, trust is a huge part of it and there's not a lot of difference between "hey curl -> shell this installer" and "hey add this PPA, or this apt repo". There's a level of trust needed regardless. There are edge cases for the more highly protective, particularly in the context of the link being on a 3rd party site like reddit. Homograph attacks come to mind, which you're less likely to notice in a curl to shell scenario than you are in other ways, though again granted there's certainly no guarantee you'll catch it with other methods either.
tldr: yes, trust is an important part, but curl -> shell relies solely on that trust and offers no other checks and balances to help establish that trust.
qlwekr@reddit
Before curl-shell most install commands instructions would point you to your distro's repo (ex:
sudo apt install ...
). But devs be lazy and getting your app into multiple different upstream packages is difficult and time consuming.Fully agree with you. Don't trust random scripts.
stonkysdotcom@reddit
Note to any newbie who reads this: NEVER pipe from the web directly to shell! Should go without saying?!