Live data from Hacker News

Don't copy paste from a website to a terminal

thejh.net

51–60 of 257 posts

Re: Don't copy paste from a website to a terminal

#51
This is properly viewed as a bug in bash (and most other shells). Shells can tell terminals to do "bracketed paste": the start and end of a pasted block is marked with escape sequences. The correct behavior is to use bracketed paste, and to treat newlines inside pastes as multiline text input, not as a ready-to-execute signal.

Apparently that hasn't happened because of compatibility problems with broken terminals, plus perhaps a bit of work that no one's stepped up to do. If anyone wants to tackle this, the GNU readline library would be the place to do it.

Re: Don't copy paste from a website to a terminal

#52
post #33

Earlier quoted context omitted.

No, unfortunately not. I did a "cat >/dev/null" before pasting so I could see what it was. Clever masked/hidden content, with embedded shell commands and newline to commit the commands.

I'm not understanding this approach. Cat is for files. How would you use it to protect against this trick? Do you mean you pre-typed "> /dev/null" and then pasted his git command where the cat is?

[deleted]

Re: Don't copy paste from a website to a terminal

#53
post #32

Off-topic/meta: "Oh, and it seems that other people wrote a detailed text about this issue in 2008." Well ... yeah. We've known about this. And yes, we need to keep making people aware. I'm also amused by all the young people and their containers: always doing things in a root shell. I'm waiting for that to implode in a few more years. My point here is that maybe it's time we started designing some curricula around t…

As someone who develops high-performance systems and is continually learning, I think this is a fantastic idea!

Honestly, something that seems desperately needed as that knowledge is currently spread out among hundreds of thousands of blog posts, forums and threads -- diamonds in the rough.

I'm going to try to get something published on gumroad (and open-sourced on github) in this vein, if you're interested let me know and I'll reach out when it's done :)

Re: Don't copy paste from a website to a terminal

#55
post #50

Aside: its not sufficient to look at a file you 'curl | bash' into bash via your browser. It is very trivial to detect curl/wget's UA (mine has: "User-Agent": "curl/7.43.0") and dynamically modify files depending on the request's UI. if 'curl' in request.UA: return 'something malicious' else: return 'something nice' Always create a local file with the content, read it, then perhaps run it.

... so this: wget -qO- 'http://example.com/script.sh' | less won't work to review the script?

no but if you change the user agent of the wget to the same one the curl uses, it would be much harder to figure out the differences.

Re: Don't copy paste from a website to a terminal

#56
post #50

Aside: its not sufficient to look at a file you 'curl | bash' into bash via your browser. It is very trivial to detect curl/wget's UA (mine has: "User-Agent": "curl/7.43.0") and dynamically modify files depending on the request's UI. if 'curl' in request.UA: return 'something malicious' else: return 'something nice' Always create a local file with the content, read it, then perhaps run it.

... so this: wget -qO- 'http://example.com/script.sh' | less won't work to review the script?

No. Totally possible to serve the "bad stuff" only some of the time.

Browser exploit kits commonly will return different stuff depending on user agent, and will track what IPs they have interacted with so that if after someone clicks the link you try to look at it, you'll get something harmless. Nasty business. The only way to be sure is to save it, inspect what you saved (make sure you use something that will show tricky escape sequences trying to hide things), then maybe run it.

Re: Don't copy paste from a website to a terminal

#57
post #29
post #2

The problem is that there's a lot of software out there that expects you to install it this way - particularly by piping into sh or bash or the like. See also http://www.seancassidy.me/dont-pipe-to-your-shell.html and http://output.chrissnell.com/post/69023793377/stop-piping-cu... and https://www.chef.io/blog/2015/07/16/5-ways-to-deal-with-the-... . There was also a blog out there collecting instances of this, but I…

One example: http://curlpipesh.tumblr.com/

That was the blog I was looking for. Thanks.

Re: Don't copy paste from a website to a terminal

#58
post #38

Earlier quoted context omitted.

Why especially in open source? The leap of faith is larger with a binary blob. (Although I admit it doesn't make much difference in practice, most people don't audit source code).

I think the argument is that open source is based on the fundamental ideal of trust - I put this software out into the world so that people can better it, tweak it, make it their own. If those people don't trust you, and have to audit everything they install, the model breaks. Re binary blobs - honestly, for me at least, if I'm installing a blob it's probably because I purchased the software. Maybe it's naive but I m…

Proprietary software is equally if not more based on trust. Trust without being able to verify.

Re: Don't copy paste from a website to a terminal

#59
post #55
post #50

Earlier quoted context omitted.

... so this: wget -qO- 'http://example.com/script.sh' | less won't work to review the script?

no but if you change the user agent of the wget to the same one the curl uses, it would be much harder to figure out the differences.

I'm pretty sure wget still makes it's http requests as version 1.0 rather than 1.1 (which nearly everything else uses), and if you want to change that you need to patch it.

Re: Don't copy paste from a website to a terminal

#60
post #50

Aside: its not sufficient to look at a file you 'curl | bash' into bash via your browser. It is very trivial to detect curl/wget's UA (mine has: "User-Agent": "curl/7.43.0") and dynamically modify files depending on the request's UI. if 'curl' in request.UA: return 'something malicious' else: return 'something nice' Always create a local file with the content, read it, then perhaps run it.

... so this: wget -qO- 'http://example.com/script.sh' | less won't work to review the script?

The web server could serve up a different version the 2nd time, to thwart people doing this.
Post reply on HN