So, ok. Don't copy and paste from a website to a terminal, I get it and I got it the last time that this kind of thing was posted. But if I look around I put so incredibly much trust in total strangers all the time that compared to say ordering a pizza (where the cook could put anything in the food they wanted), driving on the highway (where anybody could swerve any moment if they wanted) and simply walking down the street (where that old lady on the left of me could pull a knife and stab me any time they wanted) that you have to wonder if the downsides weigh up against the upsides of simply trusting the website you get the information from and getting on with your life (besides the fact that it is the browser acting in an un-expected way here, the bit selected does not mirror the visual feedback given to the user, this might even simply qualify as a bug).
What is the actual risk here, how many people have been bitten by this sort of thing and what was the resulting damage? I'm not saying there isn't any risk, clearly there is a possibility for exploitation here so chances are this is an actual risk. But I find it hard to make the case that we should all now start re-typing all the text in how-to's and scripts. It's one thing to run wget | curl, quite another to distrust each and every snippet of code on the web. I don't see much difference compared to say installing Ubuntu from a website whose contents I haven't inspected and that may have been built with a bunch of malicious stuff in it, I did not actually inspect all the source code this machine was built up with and I would be busy for half a lifetime if I did, so I outsourced the trust and verify that trust by looking at some checksum but that's about the extent of it.
Is there anybody that can quantify this risk somehow?
"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 these things that people keep rediscovering: Why you do indeed want a relational database manager and probably not a 'NoSQL' store; and when you do want a NoSQL store. Multiplexing existing systems with VMs; how your VPS works and why it worked so well on mainframes back in the day. (and oh, btw did you know that you can just pull hardware, including CPUs, right out of the mainframe and it'll keep doing its job?) Dangerous things we've all done at some point and prime (hands-on) examples of the failures that might ensue...
And no, I don't mean (necessarily) to teach in schools. Maybe an online collection. "So you wanna 'do computers' without getting hacked and without re-inventing everything..."
Further from the main topic but related to your sentiment. One of the best ways to deal with this is to have more experienced guys who have faced these difficulties hanging around.
I am a theorist in an experimental laser group, and the group head remarked on a possible counter-intuitive arcing between two separated plates (for the sake of making an electric field) when pumping out the air in a chamber. One would expect that pumping out the air reduces the "stuff" (air) that could support a current between the plates, but due to other physics (longer mean-free path) actually allows a sweet point in which the plates can arc, possibly ruining equipment like power supplies. No one thinks about this until it happens because it's physically counter-intuitive, and its too late...it really is one of those "never happens until it happens" sort of unexpected catastrophes that even if you read it in a book, you'd probably never remember it. He said this is why it's important to have newer grad students work with senior graduate to provide continuity and experience so these mistakes don't reoccur...that, I suppose, the horrific memory of destroying expensive power supplies helps the senior grads remember it better compared to someone reading a list of warning labels in a manual...
I'm assuming if you're a small start-up, you don't have more experienced people unless you hire them. So yeah, something like the C++-faq for general hacking suggestions is fun, if someone reads it.
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 :)
I made a very similar suggestion, perhaps less well articulated, just a few minutes ago on HN re: instragram v2 going to multi-DC;
When there is a write up of "We just did this super awesome scaling migration to the new hotness!" -- there will be mini-how-to articles in them... or at least more in-depth reasons why and for what problem they were specifically solving.
A how-to-wiki-gist? with "this is how you connect X with Y over ABC service in order to eliminate problem XYZ" would be great and allow for people to contribut to the how-to...
I had to hold my nose and paste some commands like this in order to reinstall Composer [1] and Drupal Console [2] earlier this week. Ugh, it feels so dirty, but it's often the first and/or the easiest, if not the only, way that software like this documents how it's to be installed.
On one hand, I'm glad people are working on easier ways to install software. On the other, everyone is ignoring distro package managers.
Docker gets it right [1] and then gets it wrong [2] - depends which set of instructions you read.
I know creating distro packages and self-hosted repos is difficult, maybe we should be attacking that as a problem instead of writing hundreds of different shell scripts.
I ran into this for the first time just recently when installing ruby and was very surprised and hesitant to follow the instructions ( see here https://www.digitalocean.com/community/tutorials/how-to-inst... ). Glad to see people speaking out against it.
Luckily both can be installed almost as easily without the curl pipe hack... Not sure why so many projects want to reduce install steps from three to one with a shell script. I could understand if you have 90 steps (in which case I would recommend you figure out a better install process in general), but not for simple 'download something, move it to a path, run a command, and you're done'. See my roles for both of the packages you mentioned above on Ansible Galaxy for more info; I tend to avoid doing the curl pipes for sanity even more so than security.
I want to know what I'm doing with my server when I'm installing packages or other software!
On the other hand, if it's over SSL, you're just as well off as installing the software any other way. Although, I noticed the Drupal console installer isn't even on SSL.
None of those commands are so long that you shouldn't just be retyping them by hand. It's obviously not an ideal way to install anything, but it's much safer than copy and pasting.
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.
One possible response to this information is to try to educate all users of the web not to copy paste from a web site into a terminal.
Another possible response -- the one I prefer -- is to change the web browsers so that the copy operation only ever copies selected text visible to the user. That is how the copy operation works in my text editor and how it used to work in web browsers in the 1990s.
Copying and pasting are useful. The fact that some are trying to persuade all web users to stop doing it -- or to stop doing one common kind of it -- is a sign that there is something wrong with current web browsers.
Yes, I know that Unicode contains glyphs that look so much like common ASCII glyphs that a user can be fooled into, e.g., curling from a site controlled by an attacker when he thinks he is curling from github.com or some other trusted site. Maybe that means that the browser warns the user whenever the copied extent of text contains non-ascii characters; maybe the browser simply refuses to copy the non-ascii characters. Regardless of how we deal with malicious use of obscure Unicode characters, I think my previous paragraph holds up.
(Users of languages other than English should replace "non-ascii" above with "characters not commonly used by writers of the languages that the user usually uses".)
Should I consider my browser betraying me by selecting stuff that's outside the viewport without a hint / warning ? (absolute positioned element, (-100,-100)). It's simply too convenient to copy/paste from the browser.
P.S. I have a paranoid habit of pasting copied text into the address bar or a notepad to quickly check for unwanted characters. For once, I don't feel like I'm crazy.
I think it's incredible that most of the comments here seem to accept or even defend that this is just the way things are, even explaining all the ways they work around it, rather than considering that this is a serious browser security issue and violates the idea that software should generally do what the user expects.
It's because for the browser the visual selection is not the same as the textual selection. I'd say this qualifies as a browser bug rather than a user failure. What you see is not what you get.
> That was a bad idea. Don't copy code from websites you don't trust!
Or indeed, download software from websites you don't trust.
I guess the worry would be that hackers would, as an example, take over brew.sh and do bad stuff with installation url. As opposed to taking over brew.sh (in an alternate world where brew.sh hosts a dmg file or something) and hosting an entirely different file.
Bar the relative ease of hiding bad stuff in copy paste compared to making a fake dmg file, this seems to be basically the same situation no?
It boils down to trust. I trust that Mint won't screw up securing my bank credentials. I also trust that OSX HomeBrew's install instructions aren't fubar.
Well, that is why I always paste stuff into a text editor first.
git clone /dev/null; clear; echo -n "Hello ";whoami|tr -d '\n';echo -e '!\nThat was a bad idea. Don'"'"'t copy code from websites you don'"'"'t trust!
Here'"'"'s the first line of your /etc/passwd: ';head -n1 /etc/passwd
git clone git://git.kernel.org/pub/scm/utils/kup/kup.git
CTRL-X CTRL-E will take you into your editor[1] from the command line, where you can paste away and see/edit if necessary. Once you exit from the editor the commands that were entered will be run.
So (if vi): CTRL-X CTRL-E i CTRL-V[2] ESC :wq
[1] at least in bash, possibly others.
[2] or whatever your paste shortcut is, and then edit if necessary
Shouldn't have to be a pain? Browser plugin to paste content to editor window. Then something that runs the document its pasted into when you've read it?
However, copy, paste, (save as a script|paste in terminal), run isn't exactly the most strenuous task in the history of man either. So it'd be a fairly meaningless chain of plugins for close to zero benefit.
I never paste anything directly anywhere when copied from a webpage. I first paste it on Notepad to handle any formatting and hidden text. Once pasted on notepad, I copy/paste to the final destination.
Another reason against copy-pasting from the web is using unicode characters that look like ASCII ones. This was on HN a week or so ago, but it doesn't hurt to repeat.
Example shell command:
eⅽho 'hello world'
Copy-pasting the above command will fail with the message `eⅽho: command not found`. The reason? 'ⅽ' in 'eⅽho' is a unicode character "SMALL ROMAN NUMERAL ONE HUNDRED" that looks identical to regular ascii 'c'.
The above can also be mis-used for any programming language, not just shell commands.
OK, i've replied with this elsewhere in the thread but will repeat it here for those who miss it. If you're on the command line and want to drop into your editor to paste, or just write a long command, and then have the command(s) executed after exiting the editor:
If you bother to compose half a page on a software problem, might as well provide a solution, no?
runCb(){ cb; echo -e '\n\nGo on? (y/n)'; read -sn 1 ans; if [ "$ans" = y ]; then eval "`cb`"; else true; fi; } #cb should output the contents of your clipboard
Or another option would be to switch your terminal to editing mode (v in the normal mode of `set -o vi`), paste it there, and do `:wq` to run it.
I don't copy paste from anything to a terminal really. I was dealing with an enterprise client once who had an 'IT guy' who insisted for months that the Git repo was broken because the URL I had provided was invalid. dude was copy-pasting directly from the PDF guide I'd sent them (and copying incorrect characters), which actually specifically sates never to copy-paste any commands into the terminal as a basic security guideline.
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).
Totally arbitrary. If you're simply copy and pasting commands you probably don't know what you're doing, OR you're just looking for the quick shortcut.
Either way, when I paste I usually put it through a scrapped terminal. Meaning I have to hit enter twice for any command to actually be executed.
If you're not checking your commands before you hit enter it's like getting in a car for the first time and bringing it to top speed hoping that it won't rattle apart and kill you.
To further this analogy, if I were to get a car from a dealership brand new it might have some issues but for the most part it's brand new and safe. If I'm buying a car from some shady lot behind a Waffle House, well then I should probably bring it to a mechanic to get inspected and such.
To detract from the analogy, dealerships are giving out different new cars while copy/pasting code from tutorials such as Linode are always giving the user the same content, they've been checked numerous times and hopefully the bullshit has been caught already.
I decided an alternative route: copied the text and pasted it into a text editor first. Shows the attack. So, I think the lesson is to do two things:
1. Copy in a harmless way first to be sure WYSIWYG.
2. Compare the commands against the man page or local docs to make sure they look right.
This is the method I created after someone posted this in response to me using an online cheat sheet for console app. I appreciated that person bringing it to my attention. However, this should knock out most risk in that area.
Other objections were essentially about how one shouldn't use commands from sources they couldn't totally trust. That's a BS double standard easily countered by, "Oh and I guess you don't run any code/binary you get from proprietary vendors or FOSS repositories unless you inspect every line to be sure it's safe?" Hell will both be empirically proven to exist and freeze over before those people's preaching and practices are consistent.
I found out the hard way that a lot of websites on Linux are either out of date or give instructions that can ruin your system.
In trying to solve a black screen with Mint 17.2 I followed directions on adding a PPA to install Nvidia drivers and then remove the open source drivers. When I rebooted I still got the black screen and in recovery mode I could not log in because it said an ACL for a card was missing a file.
When I went to reinstall Mint it didn't want to overwrite the partition and wanted to create a new one alongside it. Forcing me to delete the Linux partition and start all over again.
A lot of websites just give wrong advice and if you aren't an advanced user who knows how to fix things when they break, you could be stuck with an unusable system.
I ran into a similar issue with a black screen in Ubuntu, seemingly a result of driver issues too. It turns out the normal installation wasn't partitioning enough space for it to run in (I installed it alongside Windows 7). I had to manually partition the disk to give it ample room. Once I did that, everything ran just fine. Along the way I encountered a lot of advice similar to what you did, and it set me back several hours before I realized what the actual cause was.
[+] [-] jacquesm|10 years ago|reply
What is the actual risk here, how many people have been bitten by this sort of thing and what was the resulting damage? I'm not saying there isn't any risk, clearly there is a possibility for exploitation here so chances are this is an actual risk. But I find it hard to make the case that we should all now start re-typing all the text in how-to's and scripts. It's one thing to run wget | curl, quite another to distrust each and every snippet of code on the web. I don't see much difference compared to say installing Ubuntu from a website whose contents I haven't inspected and that may have been built with a bunch of malicious stuff in it, I did not actually inspect all the source code this machine was built up with and I would be busy for half a lifetime if I did, so I outsourced the trust and verify that trust by looking at some checksum but that's about the extent of it.
Is there anybody that can quantify this risk somehow?
Has anybody been personally burned by this?
[+] [-] delinka|10 years ago|reply
"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 these things that people keep rediscovering: Why you do indeed want a relational database manager and probably not a 'NoSQL' store; and when you do want a NoSQL store. Multiplexing existing systems with VMs; how your VPS works and why it worked so well on mainframes back in the day. (and oh, btw did you know that you can just pull hardware, including CPUs, right out of the mainframe and it'll keep doing its job?) Dangerous things we've all done at some point and prime (hands-on) examples of the failures that might ensue...
And no, I don't mean (necessarily) to teach in schools. Maybe an online collection. "So you wanna 'do computers' without getting hacked and without re-inventing everything..."
[+] [-] noobermin|10 years ago|reply
I am a theorist in an experimental laser group, and the group head remarked on a possible counter-intuitive arcing between two separated plates (for the sake of making an electric field) when pumping out the air in a chamber. One would expect that pumping out the air reduces the "stuff" (air) that could support a current between the plates, but due to other physics (longer mean-free path) actually allows a sweet point in which the plates can arc, possibly ruining equipment like power supplies. No one thinks about this until it happens because it's physically counter-intuitive, and its too late...it really is one of those "never happens until it happens" sort of unexpected catastrophes that even if you read it in a book, you'd probably never remember it. He said this is why it's important to have newer grad students work with senior graduate to provide continuity and experience so these mistakes don't reoccur...that, I suppose, the horrific memory of destroying expensive power supplies helps the senior grads remember it better compared to someone reading a list of warning labels in a manual...
I'm assuming if you're a small start-up, you don't have more experienced people unless you hire them. So yeah, something like the C++-faq for general hacking suggestions is fun, if someone reads it.
[+] [-] j42|10 years ago|reply
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 :)
[+] [-] samstave|10 years ago|reply
When there is a write up of "We just did this super awesome scaling migration to the new hotness!" -- there will be mini-how-to articles in them... or at least more in-depth reasons why and for what problem they were specifically solving.
A how-to-wiki-gist? with "this is how you connect X with Y over ABC service in order to eliminate problem XYZ" would be great and allow for people to contribut to the how-to...
But we've been saying this for 15+ years... :-)
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] GalacticDomin8r|10 years ago|reply
Ah yes. The sudo high horse. I knew I'd see you again.
Viva La #
[+] [-] Albright|10 years ago|reply
I had to hold my nose and paste some commands like this in order to reinstall Composer [1] and Drupal Console [2] earlier this week. Ugh, it feels so dirty, but it's often the first and/or the easiest, if not the only, way that software like this documents how it's to be installed.
1. https://getcomposer.org/doc/00-intro.md#globally
2. http://drupalconsole.com
[+] [-] coldtea|10 years ago|reply
The real problem is that this is nothing different than trusting a binary download -- which many more millions (billions) do.
[+] [-] voltagex_|10 years ago|reply
Docker gets it right [1] and then gets it wrong [2] - depends which set of instructions you read.
I know creating distro packages and self-hosted repos is difficult, maybe we should be attacking that as a problem instead of writing hundreds of different shell scripts.
1: https://docs.docker.com/engine/installation/ubuntulinux/
2: https://docs.docker.com/v1.8/installation/ubuntulinux/#insta...
Bonus: https://twitter.com/mjg59/status/655812609715769349
[+] [-] robotkilla|10 years ago|reply
[+] [-] nosir33|10 years ago|reply
[+] [-] geerlingguy|10 years ago|reply
I want to know what I'm doing with my server when I'm installing packages or other software!
[+] [-] vectorjohn|10 years ago|reply
On the other hand, if it's over SSL, you're just as well off as installing the software any other way. Although, I noticed the Drupal console installer isn't even on SSL.
[+] [-] dublinben|10 years ago|reply
[+] [-] jjuhl|10 years ago|reply
[+] [-] Goopplesoft|10 years ago|reply
[+] [-] Sir_Cmpwn|10 years ago|reply
http://joeyh.name/code/moreutils/
[+] [-] mortenlarsen|10 years ago|reply
https://ma.ttias.be/terminal-escape-sequences-the-new-xss-fo...
[+] [-] pyre|10 years ago|reply
[+] [-] hollerith|10 years ago|reply
Another possible response -- the one I prefer -- is to change the web browsers so that the copy operation only ever copies selected text visible to the user. That is how the copy operation works in my text editor and how it used to work in web browsers in the 1990s.
Copying and pasting are useful. The fact that some are trying to persuade all web users to stop doing it -- or to stop doing one common kind of it -- is a sign that there is something wrong with current web browsers.
Yes, I know that Unicode contains glyphs that look so much like common ASCII glyphs that a user can be fooled into, e.g., curling from a site controlled by an attacker when he thinks he is curling from github.com or some other trusted site. Maybe that means that the browser warns the user whenever the copied extent of text contains non-ascii characters; maybe the browser simply refuses to copy the non-ascii characters. Regardless of how we deal with malicious use of obscure Unicode characters, I think my previous paragraph holds up.
(Users of languages other than English should replace "non-ascii" above with "characters not commonly used by writers of the languages that the user usually uses".)
[+] [-] chdir|10 years ago|reply
P.S. I have a paranoid habit of pasting copied text into the address bar or a notepad to quickly check for unwanted characters. For once, I don't feel like I'm crazy.
[+] [-] mmagin|10 years ago|reply
[+] [-] jacquesm|10 years ago|reply
[+] [-] teleclimber|10 years ago|reply
Try copying the Hello World text in this fiddle and paste it in a text editor:
http://jsfiddle.net/teleclimber/8q6sp5ga/
(Tested in Chrome)
[+] [-] cbg0|10 years ago|reply
[+] [-] eveningcoffee|10 years ago|reply
[+] [-] RyanMcGreal|10 years ago|reply
[+] [-] SCdF|10 years ago|reply
> That was a bad idea. Don't copy code from websites you don't trust!
Or indeed, download software from websites you don't trust.
I guess the worry would be that hackers would, as an example, take over brew.sh and do bad stuff with installation url. As opposed to taking over brew.sh (in an alternate world where brew.sh hosts a dmg file or something) and hosting an entirely different file.
Bar the relative ease of hiding bad stuff in copy paste compared to making a fake dmg file, this seems to be basically the same situation no?
[+] [-] balls187|10 years ago|reply
It boils down to trust. I trust that Mint won't screw up securing my bank credentials. I also trust that OSX HomeBrew's install instructions aren't fubar.
[+] [-] hackbinary|10 years ago|reply
git clone /dev/null; clear; echo -n "Hello ";whoami|tr -d '\n';echo -e '!\nThat was a bad idea. Don'"'"'t copy code from websites you don'"'"'t trust! Here'"'"'s the first line of your /etc/passwd: ';head -n1 /etc/passwd git clone git://git.kernel.org/pub/scm/utils/kup/kup.git
[+] [-] jgome|10 years ago|reply
[+] [-] ajmarsh|10 years ago|reply
[+] [-] leejo|10 years ago|reply
So (if vi): CTRL-X CTRL-E i CTRL-V[2] ESC :wq
[1] at least in bash, possibly others.
[2] or whatever your paste shortcut is, and then edit if necessary
Edit: seems this is also possible for zsh but needs some config first: http://nuclearsquid.com/writings/edit-long-commands/
[+] [-] tolle|10 years ago|reply
However, copy, paste, (save as a script|paste in terminal), run isn't exactly the most strenuous task in the history of man either. So it'd be a fairly meaningless chain of plugins for close to zero benefit.
[+] [-] codegeek|10 years ago|reply
[+] [-] duncan_bayne|10 years ago|reply
[+] [-] brunosutic|10 years ago|reply
Example shell command:
Copy-pasting the above command will fail with the message `eⅽho: command not found`. The reason? 'ⅽ' in 'eⅽho' is a unicode character "SMALL ROMAN NUMERAL ONE HUNDRED" that looks identical to regular ascii 'c'.The above can also be mis-used for any programming language, not just shell commands.
[+] [-] steveklabnik|10 years ago|reply
[+] [-] leejo|10 years ago|reply
CTRL-X CTRL-E
If using zsh: http://nuclearsquid.com/writings/edit-long-commands/
[+] [-] pskocik|10 years ago|reply
[+] [-] xlvio|10 years ago|reply
hah.
[+] [-] spdy|10 years ago|reply
[+] [-] andreasvc|10 years ago|reply
[+] [-] jjuhl|10 years ago|reply
[+] [-] condescendence|10 years ago|reply
Either way, when I paste I usually put it through a scrapped terminal. Meaning I have to hit enter twice for any command to actually be executed.
If you're not checking your commands before you hit enter it's like getting in a car for the first time and bringing it to top speed hoping that it won't rattle apart and kill you.
To further this analogy, if I were to get a car from a dealership brand new it might have some issues but for the most part it's brand new and safe. If I'm buying a car from some shady lot behind a Waffle House, well then I should probably bring it to a mechanic to get inspected and such.
To detract from the analogy, dealerships are giving out different new cars while copy/pasting code from tutorials such as Linode are always giving the user the same content, they've been checked numerous times and hopefully the bullshit has been caught already.
[+] [-] mod|10 years ago|reply
How does this work / how do you do it?
[+] [-] nickpsecurity|10 years ago|reply
1. Copy in a harmless way first to be sure WYSIWYG.
2. Compare the commands against the man page or local docs to make sure they look right.
This is the method I created after someone posted this in response to me using an online cheat sheet for console app. I appreciated that person bringing it to my attention. However, this should knock out most risk in that area.
Other objections were essentially about how one shouldn't use commands from sources they couldn't totally trust. That's a BS double standard easily countered by, "Oh and I guess you don't run any code/binary you get from proprietary vendors or FOSS repositories unless you inspect every line to be sure it's safe?" Hell will both be empirically proven to exist and freeze over before those people's preaching and practices are consistent.
[+] [-] orionblastar|10 years ago|reply
In trying to solve a black screen with Mint 17.2 I followed directions on adding a PPA to install Nvidia drivers and then remove the open source drivers. When I rebooted I still got the black screen and in recovery mode I could not log in because it said an ACL for a card was missing a file.
When I went to reinstall Mint it didn't want to overwrite the partition and wanted to create a new one alongside it. Forcing me to delete the Linux partition and start all over again.
A lot of websites just give wrong advice and if you aren't an advanced user who knows how to fix things when they break, you could be stuck with an unusable system.
[+] [-] psyonix|10 years ago|reply