URL is also a shell script that executes some malicious(?) code(github.com)
github.com
URL is also a shell script that executes some malicious(?) code
https://github.com/jwilk/url.sh
73 comments
Yes, $() inside of double quotes is expanded. This is a documented and standardized feature of all shells derived from the bourne shell.
Every point in the article is obvious. As a script kiddie pasting stuff from the internet (including stuff from the victim's website) back in the day, I was acutely aware of the fact that you can't paste something and hit enter anywhere ever (unless you strip out ', but even that isn't very reassuring given that the shell probably has undocumented edge cases as well as other problems at other layers such as the terminal [1]).
Anyway, shells are dumb and dangerous. A real interactive language should simply have a text box for text. I guess I could write a usual 10 paragraph rant on this but it really is that simple.
1. Day of the seal soon.
Anyway, shells are dumb and dangerous. A real interactive language should simply have a text box for text. I guess I could write a usual 10 paragraph rant on this but it really is that simple.
1. Day of the seal soon.
the thing is, it gets executed when enclosed in single quote too. that's what worried me. as i had been quoting urls within single quotes in shell commands and had been feeling relatively safe -- till now.
i noticed the single quote. know how it gets escaped from the quote. the point is : we that work on command line use single quote to enclose urls as parameter to curl/wget. and that's not safe if you don't char-by-char escape the url.
i noticed the single quote. know how it gets escaped from the quote. the point is : we that work on command line use single quote to enclose urls as parameter to curl/wget. and that's not safe if you don't char-by-char escape the url.
Because you can exit the quoting any time with another single quote. This is literally how SQL injections worked 20 years ago.
No it is not. The single quote example is wrong because the evaluation part $(...) is unquoted.
Take a closer look. The first single quote part ends after the first semicolon right before the $(
It's not wrong, it's just demonstrating that slapping single quotes around a string is not sufficient to make it safe. You need to escape the string properly. Guess how many people do that.
[deleted]
Writing '...' switches from "writing shell code" to "writing a single-quoted string". It does not switch to "writing arbitrary text" (since that would give us no way to end the string!). You should always convert arbitrary text to "single-quoted string" format: most of the time it will stay the same, e.g. "google.com"; sometimes it needs escaping to prevent benign corruption, e.g. "I'm a little teapot"; in this case it needs escaping to prevent malicious code injection.
Syntax highlighting in the shell vaguely helps.
Am I missing something, or is this basically "copy this into your terminal" followed by "oh look, it did something"?
Ah yes, the legendary UN*X hacker who never pastes into his terminal.
Everyone pastes into their terminal, but you do have to be pretty naive to ever paste something blindly into your terminal (full depth of understanding of each mechanics isn't a requirement but basic understanding of high-level obvious components of the line being pasted should absolutely be).
There is literally no way to secure against people being hacked if the scenario is a user blindly following instructions without looking at / thinking about them.
There is literally no way to secure against people being hacked if the scenario is a user blindly following instructions without looking at / thinking about them.
(reply to sibling comment from unixbane which is [dead] for some reason:)
> tell me the specific way you check your stuff before pasting so I can tell you how it's either broken or you're the 0.001% user and nobody else does that.
I'm no 0.001% user, I'm not a shell expert and I can't catch everything but in the context of this particular post:
- I know how string quoting in programming languages broadly works (no need to know if ' or " escapes or not - just know that if there's any quotes inside the string it deserves a closer look)
- I know that $ in bash (& some other languages) precedes something dynamic (maybe variable substitution, maybe inline code, no need to know about stuff in any detail, just enough to be suspicious)
- I know pipe chars in shells generally separate commands (no need to understand io redirection in any detail here)
- I know that URLs tend to follow boring conventions - if it's not domain/alphanum/alphanum?alphanum=etc then it's suspect and needs further attention (URLs can contain many weird chars but normal ones tend not to).
The above bullets are pretty basic imo - you don't need to be a bash wizard to grok that much. If you know these, you'd never run the one-liner shown in the OP.
Extra:
- if it's a one-liner crossing scroll boundaries, that's too long (excepting very long URLs maybe if they're super-simple)
As a counter-example, here's the type of stuff most people copypaste into shells all the time:
1. as an inline threat, it's clearly harmless - the URL has no unusual special chars or $ and the command is very short - it can be read & grokked at a glance.
2. as a general threat, this is very dangerous because (a) it's unencryped/MITM-able and (b) you may or may not trust the hosted script being downloaded and eval-ed on your machine.
My overall point here is: there's plenty of valid & dangerous social engineering threats in your terminal; plainly obvious inline quoting problems ain't it.
> tell me the specific way you check your stuff before pasting so I can tell you how it's either broken or you're the 0.001% user and nobody else does that.
I'm no 0.001% user, I'm not a shell expert and I can't catch everything but in the context of this particular post:
- I know how string quoting in programming languages broadly works (no need to know if ' or " escapes or not - just know that if there's any quotes inside the string it deserves a closer look)
- I know that $ in bash (& some other languages) precedes something dynamic (maybe variable substitution, maybe inline code, no need to know about stuff in any detail, just enough to be suspicious)
- I know pipe chars in shells generally separate commands (no need to understand io redirection in any detail here)
- I know that URLs tend to follow boring conventions - if it's not domain/alphanum/alphanum?alphanum=etc then it's suspect and needs further attention (URLs can contain many weird chars but normal ones tend not to).
The above bullets are pretty basic imo - you don't need to be a bash wizard to grok that much. If you know these, you'd never run the one-liner shown in the OP.
Extra:
- if it's a one-liner crossing scroll boundaries, that's too long (excepting very long URLs maybe if they're super-simple)
As a counter-example, here's the type of stuff most people copypaste into shells all the time:
curl http://example.com/simple/path | bash
1. as an inline threat, it's clearly harmless - the URL has no unusual special chars or $ and the command is very short - it can be read & grokked at a glance.
2. as a general threat, this is very dangerous because (a) it's unencryped/MITM-able and (b) you may or may not trust the hosted script being downloaded and eval-ed on your machine.
My overall point here is: there's plenty of valid & dangerous social engineering threats in your terminal; plainly obvious inline quoting problems ain't it.
Usually its https nowadays but other than that there's methods a hostile webserver can detect whether the content is piped or not (IIRC I/O speed). It can decide to inject different commands based on whether it is piped or not. So you need to end up writing to a file with redirect or tee. Or by using a hash of the script. We do that with binaries, why not with scripts? If its complex enough, a shell script should be considered source code.
You can click the date of the post and then “vouch” if the post seems legitimate (I’ve done that for you now).
Thanks. I had done that but it doesn't fix ability to reply (at least not automatically - perhaps it summons mod intervention?)
Please tell me the specific way you check your stuff before pasting so I can tell you how it's either broken or you're the 0.001% user and nobody else does that. I've always just pasted into a text editor and recopied it from there (and even that may not be safe). On one hand, UN*X is not meant to have paste so you should just never use it. On the other hand, if you're using webshit you have to copy from it because there's no UN*X way to get at the data as the page has to be accessed in a proprietary way. On the other hand, I could just use a real OS that doesn't have deep reaching problems in the most basic things
and even worse: if you find a snippey of code online, once you read it carefully and you understand that it is safe to run - you might be lazy enough to copy it from the browser and paste it in the terminal. And it can be altered with JS before you copy it so you paste something different from what you have inspected. Of course you can use a buffer (say, a text editor) or even re-type that snippet yourself - but are you sure you'll never forget to do that?
True. This can be tricky but generally:
- the copy-replace trick is harder to do if you use native copy (keyboard or mouse menu) & avoid "Copy" icons pages provide
- if it's such a long snippet that's too long to re-verify at a glance, maybe it's too long...
- the copy-replace trick is harder to do if you use native copy (keyboard or mouse menu) & avoid "Copy" icons pages provide
- if it's such a long snippet that's too long to re-verify at a glance, maybe it's too long...
> the copy-replace trick is harder to do if you use native copy (keyboard or mouse menu) & avoid "Copy" icons pages provide
Pretty sure that's not true. CSS allows you to choose both what's visible to the user, and also what's included in copy/paste. There's _some_ limitations on that, but it's flexible enough to have a lot of room to be extremely scary.
You can also have a lot of fun with fonts, something that looks like "cp a b" could actually, in text, be "rm a b"
Pretty sure that's not true. CSS allows you to choose both what's visible to the user, and also what's included in copy/paste. There's _some_ limitations on that, but it's flexible enough to have a lot of room to be extremely scary.
You can also have a lot of fun with fonts, something that looks like "cp a b" could actually, in text, be "rm a b"
> Pretty sure that's not true.
> harder to do
You can do it via CSS trickery, or you can even do keyboard/mouse event detection and swap out via window.getSelection(), but both are much more involved & less reliable than via a button.
> harder to do
You can do it via CSS trickery, or you can even do keyboard/mouse event detection and swap out via window.getSelection(), but both are much more involved & less reliable than via a button.
My point was that it's still not very hard. Certainly not hard enough that you can avoid worrying about it if you just turn JS off.
*NIX
Possibly a useful pattern if you have a situation where:
1. there is some validation that checks if a URL is valid
2. this check can be bypassed with this pattern to execute code
1. there is some validation that checks if a URL is valid
2. this check can be bypassed with this pattern to execute code
That is pretty bad.
Shows that "right click, copy link, type wget ', paste, type ', enter" is a receipe to get pwned.
Same is probably true even when you do not paste it into a terminal but into a script. Like "Ok, I'm gonna automate downloading this ..."
Shows that "right click, copy link, type wget ', paste, type ', enter" is a receipe to get pwned.
Same is probably true even when you do not paste it into a terminal but into a script. Like "Ok, I'm gonna automate downloading this ..."
Pasting directly into a terminal or even a script is one step removed from blindly running eval(…) with arbitrary user input.
If you’re lucky it works. If you’re somewhat less lucky but still on the positive side, it doesn’t work with some syntax error that doesn’t corrupt anything.
There’s no excuse for not reviewing what is being executed before actually running it.
If you’re lucky it works. If you’re somewhat less lucky but still on the positive side, it doesn’t work with some syntax error that doesn’t corrupt anything.
There’s no excuse for not reviewing what is being executed before actually running it.
Reminder that copying text from a Web page is also vulnerable to "pastejacking", where the string going into the clipboard isn't the same as the user sees (e.g. adding a malicious prefix, made invisible with CSS)
Automating might actually make it safer, my typical idiom is `while read -r url; do wget "$url"; done < ./urls` (or `tail -zf ./urls|while…` to make it an url downloader daemon =P)
Not really though. How often do you paste code that's long enough to hide stuff like this from sources that you don't trust? Probably very rarely.
The real risk of this sort of thing is basically Bash injection - people who have bash scripts as part of their infrastructure that process public data. Sounds insane, yes. But there's a scary number of people who think Bash scripting is a sane thing to do.
The real risk of this sort of thing is basically Bash injection - people who have bash scripts as part of their infrastructure that process public data. Sounds insane, yes. But there's a scary number of people who think Bash scripting is a sane thing to do.
pasting things into your terminal was always a problem
Clever, but I really hope nobody is going to blindly copy-paste-go! a URL like that. Especially if you're technical enough to use a terminal, you should know better.
I'm pretty sure even the most tech-savvy users make this mistake from time to time. I certainly do.
This happens often enough, there's an entry in youtube-dl FAQ about it:
https://github.com/ytdl-org/youtube-dl#video-url-contains-an...
(They advice to add single quotes around the URL, which as you now know, is not necessarily sufficient.)
This happens often enough, there's an entry in youtube-dl FAQ about it:
https://github.com/ytdl-org/youtube-dl#video-url-contains-an...
(They advice to add single quotes around the URL, which as you now know, is not necessarily sufficient.)
Lots of legit projects encourage this practice. Especially with quotes, it's a reasonable expectation that you're getting a literal. Conversely, it's unreasonable to expect that everyone can parse shell escape strings in their brains.
Now this example wasn't exactly well camouflaged, but I'd not be surprised if you can make it much more innocent looking.
Now this example wasn't exactly well camouflaged, but I'd not be surprised if you can make it much more innocent looking.
I mean, it like dodgy to any user familiar with URLs surely?
Wouldn't
Wouldn't
wget -qO - www.example.com/script | sh
People go nuts about curl | bash but then grab random packages off pip/gem/npm/brew/VimPlug/packages.el/VS Code without so much as a second look and they can all run arbitrary code too.
If you curl | bash from http, you may get MITM'd because you're not checking the checksum. Most modern package managers at least check that what was downloaded is indeed what the original developer intended, so it's slightly better.
How is it possible to be so wrong on so many levels in just two sentences?
1. Your epistemic reasoning capabilities are broken (as in, why do you think people should know better?)
2. You are just adopting an ad-hoc philosophy based on how shells work. If interactive languages had separate text inputs instead of just parsing a stream of text from stdin, pasting would always be safe. One may be tempted to call this "UN*X braindamage".
3. You appear to possibly believe in checking a URL before opening it type voodoo as well, regardless of shell issues
1. Your epistemic reasoning capabilities are broken (as in, why do you think people should know better?)
2. You are just adopting an ad-hoc philosophy based on how shells work. If interactive languages had separate text inputs instead of just parsing a stream of text from stdin, pasting would always be safe. One may be tempted to call this "UN*X braindamage".
3. You appear to possibly believe in checking a URL before opening it type voodoo as well, regardless of shell issues
If a carpenter chops his fingers off, it's not the fault of the saw. People who use programs should be expected to know what's safe to put in and out. Having a base level expectation of competence for operators is normal.
A separate text input is just stdin by another name.
Yes, I believe people who paste URLs into the terminal should examine those URLs - you generally have to trim some stuff, quote, or rewrite things to make them useful. If you believe in wildly flinging data everywhere, good on you, I'd rather deal with easily avoidable problems such as demonstrated in TFA.
A separate text input is just stdin by another name.
Yes, I believe people who paste URLs into the terminal should examine those URLs - you generally have to trim some stuff, quote, or rewrite things to make them useful. If you believe in wildly flinging data everywhere, good on you, I'd rather deal with easily avoidable problems such as demonstrated in TFA.
> last paragraph
You can't safely paste anything into the shell ever lol. For multiple reasons. It doesn't matter how much visual inspection you do.
You can't safely paste anything into the shell ever lol. For multiple reasons. It doesn't matter how much visual inspection you do.
> If a carpenter chops his fingers off, it's not the fault of the saw.
That would be an effective argument, but this vile shit has existed for decades without being fixed, for no good reason. This saw is specifically designed to slice fingers off, rather than do useful work, for no reason.
> Having a base level expectation of competence for operators is normal.
UNIX expects perfection, while providing none of its own.
> A separate text input is just stdin by another name.
No, nitwit, it prevents in-band signalling, which is the entire problem here.
Anyway, I use Emacs for everything, and don't have these issues. With wget, I use -i - to enter multiple URLs at once, but it would also defeat this.
That would be an effective argument, but this vile shit has existed for decades without being fixed, for no good reason. This saw is specifically designed to slice fingers off, rather than do useful work, for no reason.
> Having a base level expectation of competence for operators is normal.
UNIX expects perfection, while providing none of its own.
> A separate text input is just stdin by another name.
No, nitwit, it prevents in-band signalling, which is the entire problem here.
Anyway, I use Emacs for everything, and don't have these issues. With wget, I use -i - to enter multiple URLs at once, but it would also defeat this.
Thanks for saving me a reply lol
fish catches this. It automatically escapes the single quotes when I paste it after entering `curl '`.
A careful person can use e.g. curl -- "$(xsel -o)" to deal with this. Bonus: with e.g. zsh you can press tab and see the expanded version.
I could only get it work with bash, on zsh it does not work.
Because zsh has usually the url-quote-magic feature enabled which automatically escapes all special characters typed or pasted if the current argument is identified as URL.
Most likely it escapes enough to prevent code execution, but last time I tried it didn't escape all special characters out of the box:
https://news.ycombinator.com/item?id=29071196
https://news.ycombinator.com/item?id=29071196
$ also gets escaped automatically for me if pasted
[deleted]
anybody for a little heredoc? wonderful for times when your input contains messy characters
url=$(cat <<'EOF'
http://example.com/;'$(gt=$(perl$IFS-E$IFS's//62/;s/62/chr/e;say');eval$IFS''cowsay$IFS''pwned$IFS$gt/dev/tty)';cowsay$IFS''pwned
EOF
)
wget "${url}"
After I wrapped it in quotes to workaround zsh safety mechanisms:
% curl 'http://example.com/;'$(gt=$(perl$IFS-E$IFS's//62/;s/62/chr/e;say');eval$IFS''cowsay$IFS''pwned$IFS$gt/dev/tty)';cowsay$IFS''pwned'
zsh: no such file or directory: perl \t\n
zsh: no such file or directory: eval \t\n
<!doctype html>
<html>
...I could imagine someone embedding something like this in a much larger URL, one that was full of many different characters, to make it look innocent.
fun fact: k8s uses this to always install the latest version:
https://kubernetes.io/docs/tasks/tools/install-kubectl-linux...
https://kubernetes.io/docs/tasks/tools/install-kubectl-linux...
[deleted]
Somehow I thought there is something like "disable shell expansions" option or "raw strings mode" in Bash. Seems like I was wrong.
Single quote disables shell expansions. This input contains single quotes. I have yet to see a programming language with a "raw strings mode" that wouldn't end at the next suitable marker.
havent checked, but otoh there are similar things. printf %q and ${var@Q} come to mind.
iTerm2 has a 'Advanced Paste' dialog which allows you to escape special shell characters, among other things. You can invoke it with Opt-Cmd-V. I discovered this feature a couple of days ago and wondered then under what circumstances it might be useful. Now I know.
zsh auto-quoting on paste was enough to beat it
iLoveOncall(1)