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?
Not sure whether this anecdote fits the thread well, but does address "don't copy and paste from a website to, well, anywhere without examining what you just pasted":
I was administering a final exam to a programming class. Exam was done on class computers, so with me in the front of the room most of the time I couldn't actually see what everyone was doing (and given the nature of the class, if you cheated it probably wouldn't really help you anyway).
Grading one student's submission, the wording of most of the "essay" questions seemed ... odd. Nothing objectively wrong, but everyone has their own writing style and his answers weren't, well, his. Scrolling thru one particular answer there were some blank lines after the answer ... and then a URL. The URL contained much of the test question. Checking the unfamiliar site, it was a paid technical-question-answering service, base price for answers $30 and rising depending on depth, quality & speed of answer. Copying-and-pasting the purchased answers added the source URL to the selected text, proving malicious plagiarism on the final exam. I figure he spent at least $300 to fail that exam and get one strike per the school's "three strikes and you're out" policy.
Does your school really have a "three strikes and you're out" policy for plagiarism? It seems like that would almost encourage cheating, up to the point where someone gets their second strike.
In a US university I have noticed that some international students (I was one too) took a very liberal attitude towards cheating, I won't name any specific countries (think East though) and noticed students from those countries played fast loose when it came to cheating. Maybe I am being prejudiced or that particular school had a knack for picking cheaters from some countries but not from others. Anyway just my observation.
My anecdata: I did some work at an Australian university engineering department and there was a cultural disconnect with some of the Chinese students; they did not understand that the university wanted them to figure out problems individually -- supposedly they would get together with the smartest students to figure out the answers, and then share them among themselves.
I went to university both in Spain and Canada, and the approach to cheating is very different. In Spain cheating is pretty much acceptable as long as you don't get caught. And even if you do get caught, usually all that happens is that you fail the exam and you have the option to retake it a month later. I don't know about the rest of Europe.
As it should be. The whole system is underpinned by the assumption that no one can cheat. Everyone knows tons of people cheat, but any university who has a "n-strike" policy for academic dishonesty (aka fraud), is purely in it for the money. To students who busted their asses to graduate legitimately, it's a hard slap in the face.
That's way too hardline, surely some people are wrongly accused or some cases are borderline. This sort of "zero tolerance" nonsense always just ends up removing human judgement and common sense from the equation.
Also the idea that "the system is underpinned by the notion nobody can cheat" is absurd. Cheating is rampant! Even in the ivy leagues. Especially in the ivy leagues! But people still value college degrees.
Cheating is rampant, but that doesn't mean that we all as a society don't still ignore that fact! It's a beautiful display of cognitive dissonance. There's no way to know if someone truly achieved their degree, so you have to test them, which is one of the reasons the degree was valuable. You shouldn't have to test someone if they had certain credentials. They've passed their rigorous training program.
I'm not really a fan of no tolerance policies; I would rather the system be re-evaluated so that credentialing and training are the goals of the system, not pushing as many credit hours through the administration as possible. :)
I probably have super skewed view on the matter, but what is the point of expelling someone for cheating? Not everyone learns the same way and not everyone needs the same set of skills/knowledge. I feel like people put way too much value on a degree considering what real world is like.
So far in my short SW engineering career I haven't used a single thing I "learned" from my B.Sc degree, but what school did was to let me hang around with same minded people for few years which encouraged us to work on side projects together which taught us way more than any class.
That being said, I didn't cheat either, but I don't think cheating once is a good grounds for expelling someone.
As your instructor you are asking me to certify, on my professional reputation and honor, that you know the material and can be expected to perform to minimum standards. If you cheat, you are untrustworthy, disrespectful, incompetent, and willing to engage in behavior which can cost a company millions - or even get people killed. He11 yeah I'll want you expelled.
I was this kind of student, to the bemusement of people at my year. And I can say we like to tell ourselves that - that by honest learning we somehow gained more. But to be honest, what you do at work is so different than what you learn at university that in retrospect, you may just cheat your way through bullshit exams. If you're an autodidact, it could be even better for you, since you won't waste so much time learning nonsense to pass arbitrary performance bars.
I'm not encouraging cheating here. But I learned that sometimes you have to accept that you hold to some rules just because morality, and you don't need to invent practical reasons to justify it to yourself and others. Sometimes following the rules leaves you worse off, but the world where people follow those rules is better for everyone than the world where they don't, and I want to live in the former.
I feel much the same way. Especially centered around worthless electives classes when I was studying maths. If I was interested in "Movies & Music," I would be reading about it already, and it's completely unrelated to my subject matter.
"Three strikes" would be 3 major offenses like flagrant plagiarism/cheating. I was rather surprised buying answers to a final exam wasn't sufficient for expulsion. Didn't dig into the policy details further.
My school gives undergrads one warning before kicking you out for academic dishonesty. However, we've been repeatedly reminded that graduate students know better and we'll get kicked out for a first instance of plagarism
Usually these policies work where the first strike is a zero on the assignment, the second strike is a F in the class, and the third strike is getting expelled from the school.
And I thought it was ridiculous when someone had cut and pasted a page from an Oracle manual in response to a set of pre-screening questions for a hiring round, headers included (for a generic SQL question we expected a one sentence answer to).
At least that guy didn't pay for it - to my knowledge at least (he did cut and paste most of his answers from various places, though, and got many of them wrong, including an word-for-word copy of an answer from a forum where the answer he had quoted was torn to pieces by other commenters right below).
Isn't the first place you would go to the Oracle manual? I use stack overflow all the time these days (documentation pages before that existed), not quite cutting and pasting but close enough.
The most important skill is to know how to look something up.
No one knows everything; or even a majority of things. How fast you can find an answer is what determines your productivity. Whether its via a book, a man page, google, stack overflow, or asking the right people doesn't matter.
For a basic SQL question? No. I'd never even seen an Oracle manual prior to that, and I haven't since.
If I needed specifics about Oracle, sure. I don't expect to ever need that.
But the more important aspect was that the full, complete answer to the question we raised took a single, short sentence. It was not clear from the page he had cut and pasted whether or not he even understood the question, so even if he hadn't copied it without telling us the source we'd not have considered it an acceptable answer.
Keep in mind that if the paste buffer includes a newline, everything preceding that newline will be executed. Pasting into an intermediate buffer, like a text editor, would be advisable.
It's a different threat model to your other examples though. The pizza guy, the driver, the lady down the street, unless they know you and have something against you, they would want to target you with no apparent motive in your examples. There is plenty of motive to hack random computers by just putting up a malicious website. And people try to do it all the time, and install malware with various degrees of stealth. It's not really an unknown or crazy threat.
The website threat model also allows the bad guy to target someone by IP, or some country, or only put the malicious code 1 in 1000 times, so it's not going to be widely noticed, etc.
Or it could be an HTTP (not -S) website and someone MitMs you (OK that is a pretty far-fetched attack vector for someone who MitMs you, I admit).
edit: although I agree with you that I've personally never encountered a case where this specific malicious trick happened
> It's a different threat model to your other examples though. The pizza guy, the driver, the lady down the street, unless they know you and have something against you, they would want to target you with no apparent motive in your examples.
No obvious motive or relationship is needed, especially when mental illness is considered. It could be that some stranger who lives elsewhere is walking down your street and might be looking to mug someone.
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
2) It's very likely the perpetrator will get caught.
3) No one else is left with control over your resources
Trusting a script from a website to the point where you execute it in your terminal could result in someone controlling a rootkit on your machine, without you ever knowing, with little chance of a savvy perpetrator getting caught, and with all of your operating system tools subsequently lying to you about any information you could use to detect the event.
That said, I've trusted such scripts and "gotten on with my life" on several occasions.
Similarly, running "make" in the directory of a freshly downloaded repo is dangerous too. It's really difficult to check all code running on our behalf and to quantify the risks.
If someone take control of a popular git repo and push a malicious build script. How many people will be affected before the fix ?
Good point. It is important to realize that being too obsessive about security is possible, and to know a reasonable point at which to draw the line.
But there is a difference between the two types of attack you describe that seems to change the rules on the web at least somewhat.
The difference is risk to the attacker. If I start punching someone on the bus, getting thrown off is the optimistic outcome. I could reasonably expect to be arrested, or assaulted in return, possibly fatally.
But if I post malware on the web, the worst I could reasonably expect is that the offending content is taken down, my account with that host rescinded, and assuming I do nothing to conceal my identity, I may become known as the type of scumbag who does such things. I grant that much worse results are possible, but it just doesn't seem realistic to expect much worse punishment, so long as a government or large corporation wasn't a serious victim.
While I agree with you, I also think this line of reasoning is a distraction. If we could prevent people from punching you on the bus by technological means with very little drawback, we would.
It's hard for me to see what is the difference between people who question formalizing best practices in computing and people who disagree with modern car engines and seatbelt laws.
We do these things not because it always makes a difference for one single person all the time but because it the system move in the right direction leading to possibilities we couldn't foresee from the beginning.
Someone who works in "real world" security and always have to weight in the downsides, e.g. the implications of privacy when installing a security camera on a bus, must think we are crazy questioning such low hanging fruit.
This is a great point, and something I often wonder about as well. I think it's reasonable to think that only a compromised site or site run by someone with ill-intent would pose any real risk. And in such a scenario, it's going to get out pretty quickly that the site is compromised/dangerous.
While this doesn't help that theoretical set of initial victims, it just doesn't feel like a credible risk worthy of too much worry, especially for information from higher profile sites with reputable backing.
Perhaps the solution here is better mechanisms for validating what a script can do - "script is attempting to access xyz, allow? y/n".
Little Snitch serves this purpose to some extent on OS X. If the malicious hidden script invoked a remote server I'd get a popup asking if I would like to allow it.
And in such a scenario, it's going to get out pretty quickly that the site is compromised/dangerous.
If a perpetrator is smart, the malicious script is going to be hidden a few invocation layers deep, and will only remain up for short intervals. A naive or stupid perpetrator is going to get caught quickly. But the medium is such that a smart one can hope to evade detection.
I do that regardless because I'm super paranoid about stuff like this but I'm really wondering if I'm not taking it a bit too far. I've also yet to run into any kind of attempt to pull a stunt like this in a very long time of activity so I'm wondering what the actual incidence is.
I generally find it worth it for the simple risk that you may end up breaking stuff without anything malicious on behalf of the site.
E.g. cut and paste a command and get a linebreak in the wrong location and the "rm -rf /var/tmp/foo" turns into "rm -rf /var/". Fun times.
These days I'm more and more often just spinning up temporary containers as well. Not so much for security as to avoid making a mess of my environment with all the stuff I'm testing. So trivial to start out with a "docker run --rm -t -i ubuntu -v /some/suitable/host/dir:/mnt /bin/bash -l" or similar to get a fresh container with a directory I can dump anything I decide I want to keep in.
So is it safe to cut-and-paste that line there ;) ?
I type very fast but if I see a 100+ character line with a whole bunch of flags and what not the chances of introducing a fatality while re-typing it (was that / var or /var?) are quite large.
And of course anything that involves 'rm' or other nice and friendly commands gets an extra eyeball but at some point you have to decide to pull the trigger or not.
I do not do that. I have copied and pasted git clone commands directly in my terminals many times. The questions is, for those who do it, how often you notice a malicious command and this saves your day.
I've never encountered a malicious command in the wild, but having the commands I execute saved in a "notes.txt" or a wiki page I keep to document whatever I'm doing at any given time, sure has saved my day more than once. Usually several days after, when I can look back at what I did and replicate, fix or enhance whatever procedure.
So if it also protects me against this, I say doubleplusgood.
"What is the actual risk here, how many people have been bitten by this sort of thing and what was the resulting damage?"
Exactly. And what I essentially typically say is "the scope of the problem has not been defined".
We see this often on news reports on TV as an example. They go off with hyperbole about some issue but fail to address exactly how many people have been effected by it. Simply saying things like "there is a growing concern..." or cherry picking examples.
We see this now with cases of "police brutality" and use of unwarranted force. It's not that it doesn't exist, but that any reports totally ignore how often it actually happens vs. how many times it doesn't happen.
I think the message is mostly directed at developers. It's worth noting that a developer's PC is often a very good target. It carries a lot of power, i.e. source codes, host names and private keys, etc. So even the number is small, a targeted attack might have a big impact. And a targeted attack is much, much more difficult to quantify or even study.
Not burned in the sense that I executed some hidden commands in the terminal, but I've tried pasting snippets of text in IRC and ended up pasting several lines of text that absolutely did not select.
While this may not be a huge issue in practice, I have no idea what motivates the inclusion of functionality that manipulates the clipboard in the browser. I don't really think that the analogies of anyone swerving on the highway or someone poisoning your pizza apply. It's more like your seat belts were deliberately removed, or someone put arsenic right next to the pizza box just in case anyone would want to poison you.
Technically, they're not manipulating the clipboard at all. That is definitely disallowed by browsers. What they are doing is extending the selection to an invisible part of the page, so you're copying more than you bargained for.
But without being able to manipulate selections, some nice features of certain sites would be lost. (e.g. the "share" link in StackOverflow automatically selects the URL for you so you only need to press Ctrl-C, instead of having to select it manually.)
> I have no idea what motivates the inclusion of functionality that manipulates the clipboard in the browser.
I'm not sure, but I expect that it's the same sort of thing that motivates the inclusion of the ability to enable page content obfuscation schemes that -say- scramble a page's plaintext, but use CSS styles and JS voodoo to make it appear like the page contains only comprehensible text.
I expect that -when using such a scheme-, you'd need to be able to modify what is being tossed on to the clipboard, as -I expect that- the inbuilt selection tool will pick up your garbage data as well as the intended text. [0]
Edit: To be a little more practical, you could (for instance) use the ability to modify the contents of a clipboard to -say- create custom representations of your web application data formats and allow relatively easy transfer between instances of the software.
[0] Yes, I do recognize that allowing copy and paste kinda defeats the purpose of this scheme, but the scheme is something that I've seen in the wild.
It's not just trust in strangers - its trust in the strangers and whomever may have infected the stranger with a mind-control parasite.
For web-sites, that includes direct hacks that make the site distribute malware, as well as "malvertising", etc.
So that old lady next to you may actually be the gang of thugs waiting in a dark alley.
But I don't think that the malware distributors are likely to choose an uncommon channel like copy-and-paste as a distribution vector, so you're probably still OK.
Except its very uncommon to be poisoned or stabbed and very common for IT systems to be hacked, because there's a pretty big incentive to do so (setup a spamming farm, steal data, enlarge a botnet, script kiddie cred, etc).
>Has anybody been personally burned by this?
I imagine a lot of devs who follow bad practices cause a lot of havok, but its up to the security and sysadmin team to clean up after them. They may not be fully aware of all their bad practices and a refrain of "Let us be bad, it hasn't caused any problems yet," is short-sighted.
>say installing Ubuntu from a website
At the very least you have a SSL identified site and published checksum hashes on a separate server. That's a far cry from a random shell script. Installing an OS is a special case anyway, so its not really a good comparison here.
I've seen a gist posted at bitcointalk (a scammerful place) to do currency convert in php or js, can't remember. The gist contained hidden code at column 300. Not that I was personally burned, but yea, I've seen in it the wild.
The title of this piece should be "check out this cool trick I learned." Then it could have been a quarter the length and wouldn't have had to have been couched with all the motherly scolding.
If you trust the source, you might as well install it. Otherwise, we're basically arguing that everyone who has ever installed any non-distro software is an idiot.
Consuming http or the connection dying and script ending early and being left in a weird state is probably a more interesting argument than the trust issue.
The connection-closed problem can be solved by wrapping the code in the script within a function, then calling that function at the end of the script. Of course, that needs to be done by the software's author, but we trust the authors of our software if we're going to run it, yes?
It would make for a good spearphishing attack. If you know the target's stack and can guess what sorts of issues they might run into, you can throw up a few pages detailing fixes for those issues. Give half-right answers on stack and link to your honeypot for "more in-depth discussion of the issue". Then sit back and wait for a dev to run your "fix" on one of their servers.
That's too much work. It would be easier to just tell them to curl | sh and put all your malicious stuff in the script. That way they won't actually see anything malicious on their screen.
That requires more stupidity on the target's part. I think most devs know not to `curl | sh` random scripts, but something as innocuous as `ps -ef | grep /some/longish/annoying/path/to/script` would seem both safe at first glance and long enough to want to avoid typing.
With both binaries and curl|sh, trust in the source is a major factor in whether or not you do it. But copying an innocuous-looking terminal command (like `ps | grep`) doesn't seem like it would require trust.
I'll absolutely grab a binary or `curl | sh` from slack.com. I won't do it from a forum. But I would copy a terminal command that didn't look like it was doing anything fishy from a forum.
For a long time I had the bash fork bomb without any further explanation as my signature line on /, I'd just about forgotten about it when I got a really angry email from someone telling me that I'd blown up his server and thanks very much for that.
It's the same level of risk experienced, when dealing with the types of individuals who invariably always download and execute unsafe email attachments, click malicious links in emails, respond to chain letters, business solicitations from Nigerian princes, and so on, and so on, and so on...
People get burned by this sort of thing all the time, malicious downloads were hip when Clinton was in the White House. Yes, only on Windows, and yes, easy to thwart if you know what to look for, but it's disingenuous to say that it's never happened. These things are attacks on your ability to recognize and be vigilant, and you can't recognize and be vigilant of everything at the same time.
Obviously the particular vector of console pastes hasn't been exploited yet but that doesn't mean it won't ever. When it does, we'll mourn the passing of our current free-wheeling days the same way we mourn the old Usenet.
Not sure you will anything more than anecdotal evidence but the propensity of people I've interviewed to go to a site like Stack Overflow and cut/paste "solutions" into their shell or terminal is sadly quite large. I much prefer people who can internalize the core knowledge of their craft over those who are living with all their technical knowlege currently swapped out to the web.
I think you're wildly underestimating how much "core knowledge" there is in the entire field of computing. You can be a absolute master of several disciplines and still need help when stepping outside that area.
In my experience, this sort of attitude leads to things like people saying "What the hell? Your resume said you knew Linux!" when you fail to know every single quirk of the specific unpopular distro that they're using. Don't be that guy.
If you'd be capable of injecting this sort of trick into stackoverflow that would be news. It's all about the source...
And truth be told, I have used stackoverflow to look up things, even things that I knew before but somehow lost due to inactivity, a lack of RAM refresh so to speak. I'm not ashamed of that and the IT field is now so incredibly broad that I don't feel that I'm the exception there, it's very hard to keep all of the moving parts of a webstack in your head and even harder to keep up when the platforms are changing right underneath you.
And yet I don't feel as if I fall under the 'guy that hasn't internalized the core knowledge of our craft' rule :)
Thats normal (I think). Its one of those use "every 6 months" commands, once you get away from the usual tar -xzvf falgs.(Enough tiime to know it exists but too long to remember the actulay syntax).
Ditto rsync and the more obscure gcc stuff (though that usually ends up in makefiles rather than be typed in on the command line after trying it the first time).
I think, though I'm not sure I can explain why exactly, there's a difference between using one utility—Google—to answer all questions (with no real understanding of what's the 'right' place to ask), and doing focussed research—even if that focus is as minor as just reading the relevant documentation for the specific question.
At some level google (or ddg or whatever you use) is the new 'man'. Especially since many man pages now simply read:
"The GNU folks, in general, abhor man pages, and create info documents instead. Unfortunately, the info document describing tar is licensed under the GFDL with invariant cover texts, which makes it impossible to include any text from that document in this man page. Most of the text in this document was automatically extracted from the usage text in the source. It may not completely describe all features of the program."
I agree; it comes down to trusting your source. I trust, say, github and bitbucket, and will gladly copy-paste their commands into my terminal. I'm already trusting them with much more.
I would hope that with all the resources they command that the NSA would not resort to methods involving such co-operation by their intended victims. Though anything goes I guess and why bother doing something intricate certain if something dumb and chancy works just as well.
They frequently use methods where you have to double-click on an email attachment. Most people consider cut-and-paste from a web site to be safer than that.
Also, non-TLS web sites can potentially be hijacked in flight, so this could happen even if the site in question wasn't directly cooperating.
"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.
Not entirely sure about that; my first intuition here was "temperature and pressure do pretty similar things to chromodynamic interactions—so if materials become more conductive [or even superconductive] at low temperature, then gas media probably become more conductive [or even superconductive] at low pressures, too."
(don't want to nitpick) Chromodynamic? As in QCD? We certainly are not probing anywhere near those regimes :) Also, conductivity is not the thing to think about, arcing has to do with dielectric breakdown. I guess my loosey-goosey explanation (less stuff to support current, as in less valence electrons to get stripped off to actually make a current from negative to positive plates) confused it a little.
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...
Don't jump to conclusions; my comment says nothing about sudo. There's a time to use the root shell, and a time to sudo; the key is knowing the difference. Dismissing advice because "it's never caused me a problem before" or "you don't know what you're talking about" will cause problems at some point.
If you can elucidate the reasons (plural), you need to be in a root shell, by all means use a root shell. If you're doing because "it's easier" and no other reasons, then you probably need a bit more experience. In any case, always using a root shell is the Wrong Thing To Do.
>Don't jump to conclusions; my comment says nothing about sudo
Yeah sure this has nothing to do with sudo. Right, gotcha.
> If you can elucidate the reasons (plural)
"Reasons" means plural where I come from(denoted by the "s"). There is no reason to repeat yourself. I decline your request for an elaboration. The "don't use a root shell crowd" has clearly won the popularity contest in the same way TSA now has a significant presence at larger US airports.
> If you're doing because "it's easier" and no other reasons, then you probably need a bit more experience.
Don't jump to conclusions. There are few people here who can truthfully claim more experience than I could. Regardless of our experience levels, it bears no weight in the validity of my statement.
> In any case,
Not really.
> always using a root shell is the Wrong Thing To Do.
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.
Or, for that matter, a source download. Or one you've hashed (how do you know the hash hasn't been tampered with?), a microprocessor (have you looked at the microcode? the masks), a circuit, etc.
Turtles^H^H^H^H^H^H^HTrust all the way down.
I'm not being entirely facetious, either, given the advice about disposing of electronics after visiting certain countries.
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.
for instance, if I know you are using VI I can create a series of characters that will escape out of insert mode and run a shell command (note: ^[ is ESC (ascii 27))
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.
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.
I'm not sure why you're taking about browser exploit kits when we're talking specifically about using curl or wget to pipe an HTTP payload into a shell.
Ok. Someone posed a scenario where an attacker uses the User-Agent to differentiate between a victim vetting the URL via a regular browser and someone using curl/wget to pipe it to the shell. I suggested a simple solution to this specific scenario.
There are any number of scenarios where any given solution could be broken. Why not point out that you OS might be compromised and the wget/curl binary that you're using is patched to present the wrong information to you?
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.
of course. There are also other differences. Actually, I have no idea why it even matters unless you are specifically exploiting curl. And they are not in this case. You can redirect wget output to stdout too...
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.
Start programming editors and you will understand. What you see in a rich text editor contains hundreds of debugging flags and formatting tweaks. When copying, you want to copy something clean which will paste nicely in Word or Excel. And you want to add some metadata, so you can trace is source if it's pasted back in one of your editors.
> 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?
Most terminal users these days are intelligent enough not to download a random executable from a google result and run it locally under root (without researching it). We've been well inundated not to ever run sketchy programs that you've never heard of.
However, a huge portion of people (who this article is targeting), will freely copy and paste a terminal command from a random google result. That makes it a great attack vector for, say, intro to CS students who just want to make this linux thing work right.
I'm not so sure we're really capable of distinguishing between "random executable" and everything else. What do you have to go on in making the distinction? Let's say you're installing a new version of Sublime, or curl, or Chrome. These aren't 'random executables' - or are they? If someone poisons DNS, they could be. If someone MITMs them, they could be.
What about stack overflow? Surely they are trustworthy. But if someone hacks them, and inserts an attack like the OP's, then you are in trouble.
There are two problems. First, the hardware we own is almost comically powerful, both in compute and network bandwidth. Second, that same hardware mediates between us and everything that is important to us: our lovers, friends, business partners, banks, and so forth. A subtle enough hacker might get into our system and we might not know it, ever. (Indeed, if the hardware manufacturer put some secret code into their stuff then such a hack might be very subtle and very universal indeed.)
I'm not throwing my hands up and saying it's all pointless. But consider that your typical gigabyte program has a tremendous amount of surface area to check. And no, you can't discount "dumb" resources like images and videos because they aren't executable. A smart attacker will encode instructions in, say, a viral YouTube video that will trigger those hidden CPU instructions that will load a steganographically encoded program. For now we have to be practical, and not freak out. For the future, we have to move toward smaller, more efficient software that makes unexpected computation and resource usage obvious from an outside observer. This means small code, short call-chains, and minimal screen, network or disk interaction.
(I'm particularly worried by the trend for basically all software to be constantly connected to multiple unknown external hosts, any of which could be controlling code on my machine at the same level as the program I installed!)
Of course there's always going to be attack vectors, but clearly it's safer to execute a known program (Firefox) from a trusted website (firefox.com) than it is to use an unknown program (Jons Legit Calculator App) from an unknown website (some bit.ly link). Sure there's still attack vectors at play, but you've mitigated the easy ones. This is the same thing. Everyone needs to know not to go copying terminal commands unless they really trust the source. Obviously there's still a security issue there, but its significantly lower, and that's really all we can aim for.
It was somewhat hyperbolic, showing the first line of /etc/psswd. With a normal user account that doesn't actually give you much, while giving the impresion that your password has been revealed (certainly those were my first thought upon reading the message). I imediately saw there was more going into the terminal than I expected (and was surprised) but it would have needed me to actually type a password to do much harm. (OK, some securtiy expert point can probably point out where I am wrong, but as a general rule....)
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).
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 more or less assume no company is going to actively screw over a paying customer
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.
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.
Bracketed paste can save you from accidental damage, but not from malicious pastes. As the fine article says, the end sequence can be inside the text you paste unless your terminal emulator filters out the bracketed paste characters (and last time I checked, at least urxvt didn't).
Besides, teaching shell about bracketed paste could only help for pasting directly to shell; it won't help if you're pasting to vim (think of "^[:q!echo pwned^J") or cat (think of "^Decho pwned^J").
Ok, sounds like it's two bugs - terminals definitely shouldn't pass through a bracketed paste end-marker, and probably shouldn't pass any control characters at all (ie, no esc or ^D). Passing special control characters through the clipboard is already unreliable, so I don't think this change would break anything legitimate.
I personally do web stuff in GUI with a mouse (I have vimium chrome extension, but old habits die hard) and select text by multitap: 60% of the time it works all the time. When it does not work I just drag-select and paste to terminal. Seems rather safe, as this does not work on this example.
tripple-tap on both urls give "git://git.kernel.org/pub/scm/utils/kup/kup.git" (with the exception that the first one contains a newline), and in such cases I am too lazy to reselect and just prepend the url with muscle memory git clone.
Except that every help forum about the more idiosyncratic OSS tools is full of text you need to copy and paste from a website into a terminal. It's virtually the main workflow.
I mean, even venerable Git is well-known for having this workflow:
This is an excellent example that shows the dangers of terminal escape sequences. Just a shameless plug, but here's a more detailed post (of mine) on the subject:
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?
No, I just put my terminal into a mode where I could see what I pasted without any possibility executing it. If you don't give cat any arguments, it reads from stdin and writes to stdout.
I could have just as easily opened vim/emacs/notepad and done the same, or for that matter, written the contents to an actual file instead of redirecting the contents to /dev/null.
Like many Unix commands, if you don't give cat any files to read, it reads from stdin instead. So first he runs the command (as he typed it), and then while cat is waiting for input he pastes in whatever he copied from the website.
Another handy convention is the magic "-" filename (which is not actually a file). Many tools interpret that to mean stdin/stdout. For example here is a trick to copy a tree of files:
I'm glad I asked, I wasn't realizing that `cat` would read from stdin in this case. Makes sense, given the Unix piping philosophy (which I use to great effect on buffers in vim).
But wrt your trick to copy a tree of files, what's wrong with `cp -r src dest`, or `scp -r src desthostname:/dest` if it's over a network? Is there some advantage this way?
It's not quite the same as `cp -r`. Tar will create the directories if necessary, but it will also drop the files into an existing folder hierarchy. So you could use it to create/update a few entries in an existing tree of files. For instance you could deploy updates to a website like this (locally):
cd ~/src/mysite && tar cf - . | (cd /var/www/public_html && tar xvf -)
or this (remotely):
cd ~/src/mysite && tar czf - . | ssh mysite 'tar xvzf - -C /var/www/public_html'
I would probably actually use rsync for this, but there have been times the tar approach came in handy.
A long time ago, in the dark ages of version control, I used to use tar for rollback-able deployments: I would create a tarball of the files in development to be deployed, and I would create a tarball of the files in production to be overwritten. Then I could just explode one tarball to deploy and the other to rollback. Not something I'd do today, but we didn't always have such nice tools. :-)
Generally I take a "Trust, but Verify" approach to most everything, and luckily, modern browsers have a nifty "search google for..." context menu option that lets me check anything that I highlight out on google (what a wonderful world), so the second I right clicked on what was highlighted the 'hidden' content was revealed.
Here's my biggest secret. I almost always use Chome's URL address bar as a text buffer. Not only to make sure what I copied is what I expected, but to remove new-lines, and if it's a terminal command, to allow me to edit the arguments in free-form before pasting into terminal.
The middle mouse paste (select to copy) in Ubuntu makes it even more seductive. In many occasions I have accidentally pasted code into my terminal window and many times without even knowing (debugging phantom menaces). I have started using Clipit/gedit to screen code now.
Can't remember which oh-my-zsh plugin it is but you can prevent pasting-and-executing in the terminal. What it does is that you still have to hit enter when you paste something, even if there are breaklines in it. That way you can read what you will execute.
There are some good clipboard viewers on most platforms. I've used Butler on OS X, Klipper on Linux w/ KDE, and Ditto on Windows. A quick keyboard shortcut will show you what's in your clipboard and tons of recent clipboard entries.
At the time I'm typing it the post has 516 points and 201 comments, so many people have been here. Now: how many people will actually stop doing that after reading the post? Because I don't think I will.
Super guilty of this. I'm a novice to Linux, so I didn't really know this was a thing (until now!) That said, I'm glad this was posted so that going forward I will be mindful of the risks and can mitigate them.
Is it me or the issue isn't copy-pasting here? The problem is downloading and running a piece of code you haven't looked at. I don't know if git is supposed to work this way but it sure looks dangerous.
For those trying to find it...the added code is injected in the space character between "git clone" and "git://git.kernel.org/pub/scm/utils/kup/kup.git"
My approach is in the same lines of short urls I checked the long url first, so whenever I do the copy and paste I open my text editor, because almost every time need adjustments.
This sounds like a browser bug to me: When I select text and then copy it, only the text that is actually visible should be selected and copied to the clipboard.
It's not changing what you copy, rather when you highlight that, it's also selecting text that you can't see because it's been positioned outside of the viewport.
A good terminal should show you the full pasted text in a confirmation popup before executing it. Also should never accept new lines from a paste. Or rather; if and when the paste contains new lines, it should show a confirmation popup so you know what the hell you're executing.
Something like windows?
It should treat any newline signs in the pasted text as starts of new lines, not as "enter command". The person would need to press enter after pasting.
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?