Live data from Hacker News

URL is also a shell script that executes some malicious(?) code

github.com

51–60 of 74 posts

Re: URL is also a shell script that executes some malicious(?) code

#52
post #21

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.

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…

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.

Re: URL is also a shell script that executes some malicious(?) code

#53

Quoted post unavailable.

I know this is HN, but never ever write this without explaining exactly what it does.

The chances that that one guy who's never come across it will try it to see what it does is extremely low, but definitely non-zero.

Re: URL is also a shell script that executes some malicious(?) code

#56
post #45

Earlier quoted context omitted.

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

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…

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...

Re: URL is also a shell script that executes some malicious(?) code

#57

Quoted post unavailable.

I know this is HN, but never ever write this without explaining exactly what it does. The chances that that one guy who's never come across it will try it to see what it does is extremely low, but definitely non-zero.

To be fair I think modern versions of your favorite shell warn you when trying to run it, asking for confirmation even with the -f.

(For that one guy: it deletes every file on your computer)

Re: URL is also a shell script that executes some malicious(?) code

#58
post #52

Earlier quoted context omitted.

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…

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

> 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.

Re: URL is also a shell script that executes some malicious(?) code

#59

Earlier quoted context omitted.

I know this is HN, but never ever write this without explaining exactly what it does. The chances that that one guy who's never come across it will try it to see what it does is extremely low, but definitely non-zero.

To be fair I think modern versions of your favorite shell warn you when trying to run it, asking for confirmation even with the -f. (For that one guy: it deletes every file on your computer)

SUSv4 requires that "if an operand resolves to the root directory, rm shall write a diagnostic message to standard error and do nothing more with such operands":

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/r...

But last time I checked, busybox's rm happily removed everything. :-/

Re: URL is also a shell script that executes some malicious(?) code

#60
post #45

Earlier quoted context omitted.

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…

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

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"

Post reply on HN