Pastejacking Attack Appends Malicious Terminal Commands To Your Clipboard (softpedia.com)

An anonymous reader writes: "It has been possible for a long time for developers to use CSS to append malicious content to the clipboard without a user noticing and thus fool them into executing unwanted terminal commands," writes Softpedia. "This type of attack is known as clipboard hijacking, and in most scenarios, is useless, except when the user copies something inside their terminal." Security researcher Dylan Ayrey published a new version of this attack last week, which uses only JavaScript as the attack medium, giving the attack more versatility and making it now easier to carry out. The attack is called Pastejacking and it uses Javascript to theoretically allow attackers to add their malicious code to the entire page to run commands behind a user's back when they paste anything inside the console. "The attack can be deadly if combined with tech support or phishing emails," writes Softpedia. "Users might think they're copying innocent text into their console, but in fact, they're running the crook's exploit for them."

Comments

Misfeature

[vux984]

This was *always* a mis-feature and it should simply be disabled at the browser level to permanently ignore.
 

Re:Misfeature

[Anonymous Coward]

no kidding. it's insane that this is even a thing.

Re:Misfeature

[fustakrakich]

Advertisers have been doing this for years with all sorts of their stuff attached to the paste. Is there an extension that can disable it?

And don't people read what they pasted into the terminal before hitting the Enter key?

Re:Misfeature

[fisted]

I'd venture a guess that the paste ships with the newline already...

Re:Misfeature

[Anonymous Coward]

What is ‘this’ in your sentence? CSS? Copying in general? All the page does is use some CSS to move part of the text off-screen where it cannot be seen.
Detecting what is and isn't visible when copying text is a non-trivial task, as is defining what visibility means: obviously when you press Ctrl+A, Ctrl+Ins you want the entire document, even those parts for which you'd need the scrollbar to read them. But what if text is placed in such a way that it's always inside the scrollable region, but outside the visible window client area?
And so far there have been no successful attacks based on this mechanism. It is hard to exploit, it requires the victims to paste console commands (that reduces your audience quite a lot, most people never use the console), it likely requires specific environments, it requires the console to execute it immediately rather than show it, and it's really obvious to victim that something is up, even when, especially when, it doesn't work.
So, a very difficult and low-priority feature then.
And one might wonder if it's really the browsers which need to fix this. I think it would help a great deal if terminals detected if the text likely came from the web (this can be checked since when you copy from a browser, HTML gets put on the clipboard as well as a plain text version). One of the most dangerous aspects of this attack is that the BR-tag must translate to a newline, and terminals execute commands when they encounter newlines. If the terminal would simply show these newlines on the prompt and only execute stuff when the user actually presses enter, most of the attack surface would be gone.

Re:Misfeature

[fustakrakich]

Yeah, you gotta be careful not to copy that. I only had to get burned once.

Re:Misfeature

[Anonymous Coward]

It is pretty clear that the people over reacting to this are those who don't understand the markup/stylesheets.

This isn't a issue that should be dealt with on the browser end. Pretty clear this is a PEBKAC error.

Users should clearly inspect any commands before they copy and paste them to their terminal.

If I ever paste anything into terminal I always paste it into a text editor first.

Re:Misfeature

[Snotnose]

How do I disable it at the browser level?

Re: Misfeature

[Anonymous Coward]

I understand the markup/stylesheets are a hotbed of vulnerabilities stacked a mile deep. I understand that ctrl+c should copy the visibile highlighted text only, not some backend hidden obscure bullshit. I understand that this shit should be disabled at the browser level, and ideally at the fucking spec.

Re:Misfeature

[viperidaenz]

Disable Javascript and CSS, or don't copy and paste web content in to your terminal.

The CSS method puts an inline span in the middle of what you're supposed to copy and gives it an absolute position so it's out of the visible area. Being inline, the browser doesn't care it's been re-positioned and adds it to the selected content.

The Javascript method, I assume listens for the selection events and insert inline content into the selection at a place on screen you can't see.

Re:Misfeature

[skids]

Newlines are one thing. but browsers should not be allowing escape sequences to get into the paste buffer. Which, by the way, is why you cannot use most text editors to check what the clipboard contains without taking special measures.

("xclip -o > file.txt" and "xclip -selection prmary -o > file.txt" are your friend.)

Re:Misfeature

[Anonymous Coward]

I reported this 10 years ago. How is this still a thing?

Re:Misfeature

[Anonymous Coward]

I don't understand what you're suggesting with "should not be allowing escape sequences to get into the paste buffer."

What exactly are your referring to as "escape sequences". We use "escape sequences" in programming/scripting/shells as a way to represent the raw data since it is easier than the alternatives. When you copy a string to the clipboard, it does not interpret escape sequences i.e. \n does not become a newline char, \r does not become a carriage return, \t does not become the tab char and \x00 does not get interpreted as a null character.

So my question for you, what are you saying we shouldn't allow?

Disallowing newlines, carriage returns, tabs etc would just screw up formatting when copying information from the web. You would cause more problems than the one you're trying to solve.

Re:Misfeature

[Zeroko]

I just tried pasting ESC [ A (with character 27 in place of ESC & without the spaces) into a terminal, & it switched to the last history entry (& kept going back with more pastes). That may be the sort of escape sequence that was meant. So keyboard commands for terminal-based applications (someone mentioned there is an example exploit for vi) should work.

Re:Misfeature

[Anonymous Coward]

Just my opinion, but seems to be more of a problem to be handled on the terminal application level than in the browser.

Check out this link regarding bracketed paste mode.

Re:Misfeature

[johannesg]

Disable javascript and CSS. Then disable the clipboard and the graphical environment. Then format your harddisk, take apart your PC, and throw every part into a fire. It will hurt as they burn, but at least you will be still alive.

Seriously, what sort of shitty advise is "disable javascript and CSS"? Might as well tell people to only ever browse with Lynx. Which basically means 'giving up on the world wide web as a whole'. That seems a rather drastic solution for working around a very, very minor problem in the first place. For one thing, if you run Windows none of this is a problem, so 99% of the worlds' population is already safe by default...

Re:Misfeature

[viperidaenz]

It's pretty much the only answer to the question "How do I disable it at the browser level?", which is what I replied to.

If you ask a stupid question, expect a stupid answer.

Re:Misfeature

[Anonymous Coward]

What we could do is burn the people who write idiotic misfeatures like this. The example should serve to prevent similar security problems in the future.

Re:Misfeature

[operagost]

Actually, this is still a problem with Windows because you could paste this crap into a cmd or Powershell window just fine.

Re: Misfeature

[Anonymous Coward]

In that case, if you're using Firefox you can just select from the menubar: View > Page Style > No Style
This disables all CSS, including inline styles, which seems to me like the only solution that could make you happy. If it doesn't, just stop browsing the web.
However I disagree that the spec should be changed because of this, because although it'd make you happy, it'd negatively impact everyone else.

Re:Misfeature

[Hylandr]

I always paste into Notepad to remove the extra junk anyways. I too would love to see that extra copy BS die in a napalm fire.

Re:Misfeature

[vux984]

Actually the browsers need to be updated to fix this.

The Javascript oncopy event maybe shouldn't even be fired by default on untrusted sites.

The default copy to clipboard action should ignore hidden divs, inline spans to offscreen locations, etc.

The default copy to clipboard action should perhaps ignore html/css entirely and just copy selected plaintext. Because I can see other vectors for attack, not just the terminal.

Re:Misfeature

[tlhIngan]

What is âthisâ(TM) in your sentence? CSS? Copying in general? All the page does is use some CSS to move part of the text off-screen where it cannot be seen.
Detecting what is and isn't visible when copying text is a non-trivial task, as is defining what visibility means: obviously when you press Ctrl+A, Ctrl+Ins you want the entire document, even those parts for which you'd need the scrollbar to read them. But what if text is placed in such a way that it's always inside the scrollable region, but outside the visible window client area?

You forgot about Unicode, where one visible character you see can easily consist of 4-5 or more codepoints that get copied as well. There are a few deadly sequences that can screw up your terminal if it's Unicode aware.

Re:Misfeature

[vux984]

That seems a rather drastic solution for working around a very, very minor problem in the first place.

Clipboard attacks could do all sorts of nastiness. What if they used javascript to dynamically attach a media container with a malicious file, knowing that you are pasting it into word or excel or something which will activate that container outside of the browser sandbox.

For one thing, if you run Windows none of this is a problem, so 99% of the worlds' population is already safe by default...

Because there is no command prompt in windows? And there aren't any sites on the web where you might be instructed to open a command prompt and copy/paste a bit of script... to clean up a virus infection, or disable telemetry, or whatever.

There's aren't any sites on the web where admins are given snippets of powershell to copy and paste ... to setup some feature of hyper-v server; configure some firewall rules, or whatever.

There aren't any sites on the web where programmers are copy and pasting bits of script and code to tools like R Studio? Or an interactive shell for ruby, python, javascript.

Not to mention the ability to craft malicious content and tack it onto to the clipboard that can crash office suites, etc. (sneak in a deliberately corrupt embedded image, or media container...)

Re:Misfeature

[Anonymous Coward]

I'm more interested in "how can I make this happen on stackoverflow and github".

Which is something that Slashdot denizens of years past would have told me.

Re:Misfeature

[Anonymous Coward]

All the characters in Unicode which are dangerous are actually already present in ASCII: things like U+000A, U+000D and U+001B are from ASCII originally. I think that terminals should be more careful about not automatically treating pasted text like user-initiated key presses. And there may be some terminals that are buggy and split the code points in bytes, or that may do funny things when they encounter RTL markers, but I consider those flaws in the terminal application that browsers don't have to accommodate.
In the end, the clipboard is meant for transferring data, like text and pictures, between applications. This is what most users use it for and this should work as flawlessly as possible. This includes copying Unicode characters, newlines and control characters, because users might and occasionally do want to copy those.
The clipboard is not intended to be some kind of surrogate shell scripting interface, and neither the clipboard, nor other applications which use it, can be expected to be limited or broken just to allow that use case, for which it wasn't intended and which doesn't even matter to the vast majority of users. If terminals want to allow you to paste commands, it's their job to make sure there are no unintended consequences.

Re:Misfeature

[Anonymous Coward]

If you look at all your examples, and the article, it's clear that in each instance it's a different thing that makes the clipboard content potentially dangerous. In a command prompt, it might be a newline, in VI an escape, in a word processor a malicious embedded object. From this it also follows that it's the receiving applications that need to make sure they cannot be induced into malicious behaviour from a paste.
Command prompts shouldn't execute commands when you paste a newline.
VI shouldn't go to command mode when you paste an escape.
Office software shouldn't have data execution vulnerabilities triggered by corrupt images.
And so on and so forth. This is similar to how it's up to the operating system to validate the parameters passed to system calls, and not up to the application. Letting the copying application second-guess where the text is likely to be pasted and break copying subtly, or not-so-subtly? That way lies madness. To get that to work reliably you'd have to make every application that copies stuff play their part, otherwise e.g. your e-mail client could betray you when someone sends you malicious e-mail. And every application would need to have a time-machine to figure out where the copied text will end up, and know about all potentially vulnerable applications, in order to filter stuff where it's dangerous, but not filter it when it isn't and it's expected to be copied.

Re:Misfeature

[skids]

In answer to GGP, you may not have been born early enough to have reason to know that "escape sequences" also is used to refer to in-band signalling on TTYs (which, yes, there are some in the other direction than what is covered in that article). As far as this post I mean specifically ascii character 0x1b (U+001B), which browsers will happily allow to be stuffed in the clipboard and which is what makes exploits of pastes into certain text editors possible. A strong argument could be made for certain of the other control characters which are generally only used as hotkeys on terminal apps. Of course you don't want to mess with things actually commonly used as whitespace like tabs.

To your point, it could also be handled by the desktop clipboard services. Getting sundry terminals and apps to ignore 0x1b from clipboards (we'll call this plan C) is probably harder than (plan A) not putting it in there in the first place or (plan B) banning their presence in the OS/desktop clipboard services. The terminal-based ecosystem does not have this problem internally, because they chose plan A by making certain dangerous characters generate harmless representations on output, which prevents them from getting cut into clipboards (U+001B shows up as two characters "^[" and if you cut and paste it, you paste those two characters, even if the terminal app knows they are just one escape character). It is likely the best choice -- no garbage allowed in, hence no garbage out.

There is probably little good use for having an 0x1b or several other control characters stored in the desktop clipboard, but there may be some obscure places where that might be handy, and choosing B or C would interfere with that. Plan C also involves going into lots of forks of lots of very old code and making changes, unless you try to use only new shiny terminal applications. Personally I cannot, because all the new shiny ones broke or just failed to implement important must-have features when they were implemented (I'm glaring at you, libvte.)

Re:Misfeature

[vux984]

Read your post again.

Your argument fails for the same reason ActiveX was an atrocity. As long as everybody ELSE does their job properly activeX was fine. But reality doesn't work like that and ActiveX was a horrible security mess as a result.

The operating system and the browser need to take ownership of the problem and ensure the clipboard is safe.

The web should be assumed hostile by default. The browser runs in a sandbox by default, and everything coming out of it needs to be carefully screened and sanitized at the point it comes out of the browser. That means the copy from the browser INTO the clipboard needs to be as sane as possible.

Yes, it can't catch everything; but it should be designed to minimize the possibility of anything unwanted coming out of the browser.

Yes you are right, that every application that accepts input should sanitize it. But its not realistic, and its not responsible.

Re:Misfeature

[Anonymous Coward]

Your ‘solution’ is actually closer to the ActiveX scenario than mine. The role of the ActiveX controls in your scenario is taken up by the various applications with a copy function and the operating system. But contrary to the ActiveX scenario, where the ActiveX controls could in principle ‘do their job properly’, if written by people who aren't incompetent or malicious (which in practice they were of course), in this case the applications and the operating system cannot do their job properly. For one thing, they'd need a time machine to travel into the future to the moment when the text is pasted to see which application is on the receiving end so the copying application and the operating can do their filtering job, and secondly there is no way that any application writer can foresee all possible troublesome situations. Since time machines don't in fact exist, there are basically two scenarios: 1) the application filters out all possible bad input or 2) the operating system contains a filter routine for every possible receiving application, including those which haven't been written yet.

Scenario 1) would make it impossible to put the following characters on the clipboard: newlines, tabs, escapes, colons, forward slashes and possibly many more. All these are used my one application or other. It would also make it impossible to put images on the clipboard since it's in this scenario the copying application's job to ensure the clipboard is safe for programs with arbitrary image handling bugs. This would make the clipboard useless to the vast majority of users. Incidentally, that same vast majority is not in fact impacted by this issue at all.

Scenario 2) makes even less sense. If every target application needs a special routine, that routine should be part of the target application. The writers of the application know better what needs to be done to parse the clipboard data safely than the writers of the operating system, who may not even know that the pasting application exists and who certainly aren't well-versed in the internal workings of the application.

Whatever way you are going to try to solve this, even if you think of something more arcane, you will always break some functionality somewhere. For example, filtering out newlines before they reach the terminal, instead of using bracketed paste mode for example, makes it impossible to paste multiple lines into the console. There is no magic wand that you can wave to make an arbitrary piece of text ‘safe’. It is not possible to write a routine that does this without possibly damaging the text in such a way as to make the clipboard useless.

You say that it is not realistic for applications to paste arbitrary clipboard contents safely. Yet the vast majority of users are using applications that aren't impacted by this issue at all. (This is mostly because most applications don't treat clipboard contents as a string of key presses.) Meanwhile, in your world, we would greatly diminish the usefulness and robustness of the clipboard for everybody while only a very tiny minority (those savvy enough to use a console, a tiny minority in and of itself, but who aren't savvy enough to paste via a text buffer or use a terminal which supports bracketed paste) is going to actually benefit from it. That is unrealistic, and irresponsible.

I also note that so far you have given no concrete suggestions on how to go about your solution. You fantasise a lot about how things would be better in your world, but the whole notion seems to me doomed from the get-go. Perhaps this discussion could go in a more constructive direction if you actually told us, concretely what applications and/or the operating system would need to do to protect a badly written terminal, which cannot tell the difference between clipboard data and keystrokes, from itself, without hampering functionality for the vast majority of normal users, who use the clipboard to copy text on a page to Notepad, Word, their e-mail client, or their instant messenger.

Re: Misfeature

[Anonymous Coward]

Worse: what is visible or not on a website is undecidable, because it's up to the user agent to decide what content it renders and in which way. Using CSS to visually hide stuff is legitimate, for example when you want extra content/hints that are only for screen readers, or when text is replaced by an image. Selecting the image and doing ^C still copies the underlying hidden text, and any suggestion it somehow shouldn't is idiotic.

Re: Misfeature

[Anonymous Coward]

What? You're directly contradicting itself. Should copy to [text-only] clipboard try to guess what part of the text is hidden by CSS, or should it ignore CSS? Currently it is ignoring CSS, and I think that's the only sensible way to implement it. Render as text is a different medium than render as rich text, deal with it.

Re: Misfeature

[Anonymous Coward]

if i use my mouse to select text, the browser helpfully gives me a visual hint of what's selected
in the pastejacking attack it also copies shit that isn't visually marked as selected

That's definately something that violates my expectations as a user, and hence a UI-bug

Re: Misfeature

[Anonymous Coward]

Please read the other comments before chiming in with you ill-thought out brainfart. There are lots of scenarios where text isn't visually selected but needs to be copied anyway, for example the alt-text of images, or text which is selected but outside of the currently visible client area, like in a Ctrl+A, Ctrl+C scenario.

Re:Misfeature

[vux984]

For one thing, they'd need a time machine to travel into the future to the moment when the text is pasted to see which application is on the receiving end so the copying application and the operating can do their filtering job, and secondly there is no way that any application writer can foresee all possible troublesome situations

I don't care that it can't foresee all possible troublesome situations, you are raising the bar to absurd levels.

The browser should be responsible for sanitizing what goes into the clipboard to the best of its ability.

I also note that so far you have given no concrete suggestions on how to go about your solution.

Except I did exactly that. Numerous times in numerous posts now.

1) Plaintext only from the browser to the clipboard by default. If the destination app can be tripped up by plaintext that's on the destination app - we can't solve everything unless we unplug the computer and take the battery out. But we can eliminate a lot of attack vectors by only supporting plaintext by default.

2) What is selected by the user only to the clipboard, to within its best ability -- so no firing a copy event to allow javascript to append shit to the selection. And make a browser best effort to exclude that which cannot be seen -- if the 'selection' can't be scrolled to and isn't visibly rendered, then it doesn't go. There are some issues. By default -- err on the side of caution.

3) If the user wants to copy and image, they have to use the copy image right click menu or a 'snipping tool' by default.

Scenario 1... Scenario 2...

4) At the OS level when pasting things FROM an the browser, a preview should be displayed that has to be approved before it's passed to the destination app. So the user can see and even edit the plaintext they are about to paste regardless of what app it goes to.

Make this customizable; make it intelligent. I've got a dozen ideas-- whitelisting apps, greylisting apps -- pasting plaintext to Word is safe... to cmd.com; terminal.app; RStudio.exe etc ... is not safe. etc. Yes you won't know about every app ... etc. But defaulting to 'unsafe - requires preview' and whitelisting the 1000 most common apps that are safe out of the box would make it pretty innocuous. Users could whitelist apps as needed... it could be managed online "antivirus style" where the default clipboard handler for apps are subscribed to...

I read your post, and i see a defeatist attitude. IF you can't easily do it perfectly then throw your hands up and walk away. Mitigated in nearly all cases is easily achievable. There simply aren't THAT many command/terminal applications in common usage. Get the most common 100 and its probably mitigated to the point of being worthless to even try to exploit.

Perfect is the enemy of good.

Re:Misfeature

[Anonymous Coward]

I am not raising the bar, I'm just trying to give you an idea of what would be necessary for your ideas to work. I won't comment on the concreteness of your suggestions so far, let's just look at your current post.

1) This is an unacceptable reduction of functionality for most users, and almost nobody would benefit from it. If people select an image, or text with cursive or other mark-up, it must paste correctly in their word processor. Breaking that just for the benefit of a few special snowflakes who aren't using the clipboard for its intended purpose is unacceptable.

2a) Although maybe it would be better to turn the copy event off, the least unlikely click-jacking scenario is where someone copies a line of text and that scenario needs no JavaScript at all. And JavaScript still has to be able to get (and change) the selection for things like rich text editors, forums and web-mail to work. Combine with a timer and presto, you have all the functionality from the copy event that you needed. (Note: if you're using Firefox, you can go to about:config and set dom.event.clipboardevents.enabled = false. But doing so does actually cause breakage in some web editors, like the Orion source editor and the Firefox scratch pad.)

2b) I have already showed you some reasons why that's a lot more complicated than you think it is and there are many more. A click-jacker will not care for all the avenues that you blocked on a best effort basis, he'll only care about the ones you don't block. Combine this with the non-triviality of determining whether something can or cannot be scrolled to, or is or isn't visibly rendered, this doesn't even come close to a concrete suggestion. It's a vague idea at best.

3) See 1. ‘Why the fuck didn't it copy my images? Oh, it does work in Internet Explorer? Fine, I'll use that then.’ The user will likely never know he should have right-clicked. If he finds out before uninstalling the browser, he'll just right-click every time he needs to copy something. This idea degrades the browsing experience, while not helping anyone.

4) So every time I'd copy something from the browser I'd get an annoying pop-up? This will make users want to switch to a different operating system. Implement this in Linux and your users will flock to BSD. Get it to work in BSD as well and even the most raving GNU fan will switch to Windows. At the same time, this will just start an arms race between browser developers and OS developers, because the browser that doesn't show the pop-ups is the one that the remaining people on the platform will want to use.

"Make this customizable; make it intelligent", blah blah blah. None of this even comes close to being concrete, while already requiring way too much effort and causing way to much harm and annoyance to be acceptable to the vast majority of users. All to fight something that almost nobody is affected by.

"i see a defeatist attitude" I don't know what you've been reading, but certainly not my posts. There is nothing to be defeated by in the first place, the current situation is just peachy compared to your dystopian clipboard future.
"Mitigated in nearly all cases is easily achievable." By not directly pasting commands into prompts if you don't know if they support bracketed paste. Mitigation in the browser or the operating system is not easy, as you yourself have shown already.

"Perfect is the enemy of good." The situation is already good. As it stands, the current situation works out quite nicely for all users who don't use the console, which is almost everybody, and those who do but who do so sensibly. Your desire to combat this issue, which only affects a tiny minority of users, and which has no real history of exploitation, and your desire to do so in the least practical way possible, would take this situation and make it significantly worse for everybody. And this is why no major browser or OS vendor is going to bother with your fantasies. For the most part you haven't even touched the concreteness you need in order

Ok?

[Anonymous Coward]

If people are running shit without checking to see what's actually input first, then I dont feel bad.

Re:Ok?

[Anonymous Coward]

Are you an antivaxer? Just asking.

It's not all about what stupid/drunk people do to themselves when they use their computer/car. It's also about the damage they can cause to all of us.

We expect better effort next time.

[downright]

Millennial hackers just don't try very hard.

Bracketed Paste Mode

[Anonymous Coward]

Terminals/shells that support bracketed paste mode don't have this problem.

When you paste something, it won't execute until you press enter. This helps avoid issues with mistake pastes, and also issues wherein one accidentally copies a newline with the desired text (in this case, you can hit backspace to delete the newline, continue editing the command, and hit enter only when you're done).

There's a ZSH plugin that adds this functionality:

https://cirw.in/blog/bracketed-paste

I love zsh.

Re:Bracketed Paste Mode

[peragrin]

wait which shell automatically executes pasted commands?

I know bash and powershell(yes I use MSFT powershell) do not.

Re:Bracketed Paste Mode

[Anonymous Coward]

They do if the paste contains a newline at the end (or in the middle).

Re:Bracketed Paste Mode

[Anonymous Coward]

Most shells CAN execute pasted code automatically, because they don't distinguish between user input (i.e. from the keyboard) and the pasted contents. So if the pasted contents have a newline in them, generally the shell will execute the pasted command immediately. For example, if the copied string was "ls\n", the shell would just think the user typed: [l] [s] [enter]

Most modern terminals will surround the pasted text with escape sequences, which can signal a supporting app (i.e. a shell or an editor) that the input is from a paste, and not directly from the user. However, the shell has to support these escape sequences, and bash does not. ZSH can, with the plugin I mentioned in the OP.

It's worth noting that this attack has been thoroughly explored (even in a web context, using css and no javascript) at least as far back as 2008 -- probably earlier.

Re:Bracketed Paste Mode

[Anonymous Coward]

Try again with a newline at the end of the command. That will automatically execute the command as part os pasting it. A malicious script would put a newline at the end so it would run before you had a chance to catch the error.

Terminal + bash on Mac will execute. As will both Powershell and cmd.exe on Win.

Re:Bracketed Paste Mode

[DarkOx]

are you sure, what happens if you have a \n character embed in the paste text. bash sure executes it in my terminal emulator.

Re:Bracketed Paste Mode

[jouassou]

Now *that* is cool. Definitely gonna check out the vim-bracketed-paste plugin linked at the same page too, I'm also one of those who always forget to :set paste before copy-pasting stuff in, and the autoindent is then really annoying...

Re:Bracketed Paste Mode

[Anonymous Coward]

Highlighting the text and using middle button paste also doesn't trigger the problem. You get just what you highlighted. Thank you X11.

Re:Bracketed Paste Mode

[Jahta]

Terminals/shells that support bracketed paste mode don't have this problem.

When you paste something, it won't execute until you press enter. This helps avoid issues with mistake pastes, and also issues wherein one accidentally copies a newline with the desired text (in this case, you can hit backspace to delete the newline, continue editing the command, and hit enter only when you're done).

There's a ZSH plugin that adds this functionality:

https://cirw.in/blog/bracketed-paste

I love zsh.

On Windows, if you use ConEmu to manage your shell sessions it will block execution of pastes that contain a Return character (regardless of which shell you are running; works with both cmd.exe and bash) and will warn you about the embedded Return.

Re:Bracketed Paste Mode

[Anonymous Coward]

For over a decade I've been annoyed that CTRL+C copies both plaintext -AND- HTML from web browsers, so if I plan to paste into anything that suppports HTML clipboard, I always CTRL+V into notepad (or gedit, or equivalent) to remove HTML formatting, and then immediately CTRL+C the plaintext from the text editor, so I can CTRL+V it into a web browser or office document editor (word / excel / powerpoint, or writer / calc / impress).

After learning of this attack, I'll definitely plan to use the "notepad" trick for anything that's going to go into the terminal.

Re:Bracketed Paste Mode

[Anonymous Coward]

In Word/Excel/Powerpoint you can choose to paste as text only after you paste it in. Just click the drop-down on the icon that appears after the pasted text and choose the paste option you want.

I'm wishing for help from terminal programs

[John Marter]

I know I shouldn't copy and paste into a terminal, but it is so convenient. I don't even need a malicious website to get myself into trouble. I just forget that I copied hundreds of lines right after I copied that filename that I wanted to use. And then boom!, lots of commands entered that who knows what will happen with.

I've occasionally looked, but never found a terminal to help with this. Probably because they shouldn't encourage my bad habit. But if it would just give me a pop up showing what I am about to paste that would help a bunch.

Re:I'm wishing for help from terminal programs

[Fwipp]

On Mac, iTerm2 will warn you "You're about to paste [1] lines ending in a newline. Are you sure?" Or sometimes "408 lines."

document.execCommand

[Chmarr]

So, this hack uses document.execCommand('copy')

It doesn't work in Safari nor Chrome. What browser DOES it work in?

Re:document.execCommand

[Anonymous Coward]

It does work in Chrome on Linux.

Re:document.execCommand

[viperidaenz]

According to https://developer.mozilla.org/... document.execCommand('copy') works on Chrome 42+, Firefox 41+, IE9+ and Opera 29+

Re:document.execCommand

[Anonymous Coward]

And the bug here is that they copy to the OS clipboard instead of a browser-only clipboard.

This is why I like iTerm on the Mac

[Anonymous Coward]

It warns of commands containing newlines which seems to be the obvious solution to this. Having to confirm it when you actually want pasted commands to automatically execute is annoying, but better than the alternative.

Open source unix virus

[140Mandak262Jamuna]

Clip board and command line? Wasn't there already a unix virus like that?

Subject: Unix virus

You have been attacked by the unix virus. Please forward this mail to everyone in your .mailrc and delete a bunch of files from $home

Re:Open source unix virus

[BlackPignouf]

My favorite is still writing

echo "sleep 1" >> ~/.profile

inside the .profile of my colleagues when they leave their terminal open.
A few weeks after, I complain that my Windows desktop seems to be always booting slower and slower, but that hopefully, it's never been a problem with Linux.

Re:Open source unix virus

[Anonymous Coward]

You madman

Ye old unix hacks

[sg_oneill]

Reminds me a bit of a hack we used to do in the late 80s/early 90s on the old terminals at uni. For a few seconds during login on the old unix machines, your terminal was world writable. There was an escape sequence that let you bind key sequences to keys (like macros I guess). So we'd sit there watching for that login and blap the terminal with macros, and then take control from there.

Fortunately it was a more innocent time, so we'd just use it to spam academics with frank zappa lyrics and stupid shit like that, although one guy did write a sort of shell virus that got out of hand *very* quickly.

Pastejacking?

[Ol Olsoc]

I remember a kid in second grade who was caught pastejacking in second grade. Sent him away, and never came back. The school had to buy all new paste too.

Re:Pastejacking?

[orledrat]

I stole a spaghetti once because I was low on dough. Yep. Thank god I didn't grab one of those RFID tagliatelli, like my mate did.. the coroner report says he simply pastaway but he was covered in boils and had that terrible strained look in his eyes :-(

Re:Pastejacking?

[Anonymous Coward]

a spaghetto.

Re:Pastejacking?

[Anonymous Coward]

What?

An exploit for your text editor

[tepples]

If I ever paste anything into terminal I always paste it into a text editor first.

Then gosh help you if what you paste contains an exploit for your text editor. There's a vi exploit in one of the examples.

Re:An exploit for your text editor

[Anonymous Coward]

Good thing the text editor I use doesn't execute the content I paste as if it were keyboard input.

Re:An exploit for your text editor

[Anonymous Coward]

A vim exploit that only works if you paste while inside insert mode. Personally, I didn't realize that was a thing until reading that example.

Re:An exploit for your text editor

[Anonymous Coward]

Vim doesn't either. The commands for pasting system clipboards ("*p or "+p) do not interpret the pasted text as keystrokes. Nor does pasting any of the Vim internal clipboards.
If by paste you mean tell the terminal emulator to paste and give it to vim the same way it gets keyboard input then yes vim will treat it as keyboard input.

Re:An exploit for your text editor

[Anonymous Coward]

Seems you're correct, this isn't a problem with Vim but more of a problem with users bad habits.

So users need to use the appropriate way to paste in Vim or they should look into seeing if their terminal emulator supports bracketed paste mode to disallow pasted input from getting interrupted as keyboard input.

Re:An exploit for your text editor

[Anonymous Coward]

*interpreted

Re:An exploit for your text editor

[Anonymous Coward]

A vim exploit that only works if you paste while inside insert mode. Personally, I didn't realize that was a thing until reading that example.

How do you write text in vim without going to insert mode? Painfully?

Re:An exploit for your text editor

[AmiMoJo]

That's more of an argument against using vi for handling unsanitized input. Most editors require you to press un-pasteable modifier keys to do anything dangerous or irreversible, but vi's modal design makes it vulnerable.

Re:An exploit for your text editor

[tepples]

I think the idea is to leave insert mode to paste using a dedicated paste command rather than using your terminal's keypress simulation.

Re:An exploit for your text editor

[Anonymous Coward]

All terminal-based editors accept commands "in-band", because that's the way terminals work. vi isn't any worse than others in that regard - you need to type an escape (^[) before any other commands.

Probably terminals should not accept pasted control characters by default. (Whether browsers should permit web pages to include control characters in the clipboard is another question.)

Re:An exploit for your text editor

[Anonymous Coward]

In the off chance this is serious, I didn't realize that pasting in insert mode was a thing (not counting C-o)

Copy all commands into a file first

[Anonymous Coward]

Copy and paste into an empty file first. Then chmod to allow running.

Re:Copy all commands into a file first

[Anonymous Coward]

Copy and paste into an empty file first. Then chmod to allow running.

And how do you paste into an empty file? With a text editor?

Re:Copy all commands into a file first

[mugurel]

cat - > /tmp/emptyfile.txt (then do the paste, and then Ctrl-D)

This is robust at least against the demo attacks given in the article.

Re:Copy all commands into a file first

[Anonymous Coward]

I always paste into a text editor first with any text I'm copying from the web, primarily to get rid of any formatting that comes with it. When I'm copying text, I want only the text, not font, size, emphasis, or whatever.

Re:Copy all commands into a file first

[mattventura]

That could be foiled by putting a ^D in the copied text. The most effective way is to paste the text via the editor itself rather than the terminal ("+p in vim) or via a program like xclip.

IE4 relic

[Anonymous Coward]

Allowing Javascript access to the clipboard was known to be a stupid idea back in the days of Internet Explorer 4, along with allowing Javascript to create bookmarks and other such functionality for overriding the user.

Which moronic browser has still not fixed this gaping security hole?

Insecure Terminals are the problem.

[Qbertino]

Terminals/shells that support bracketed paste mode don't have this problem.

Which should be the default behaviour for all Terminals.

FUD

[Anonymous Coward]

"It has been possible for a long time

"The attack can be deadly

Fucking A. Fuddot.

Why not a story about how to post a comment you have to enable your browser to access...
www.googletagservices.com
trackerapi.truste.com
tag.crsspxl.com
sourceforgemedia-computing.t.domdex.com
s.ntv.io
rpxnow.com
partner.googleadservices.com
consent.truste.com
consent-st.truste.com
cdn.taboola.com
cdn-social.janrain.com
api.stacksocial.com
analytics.slashdotmedia.com
ads.pro-market.net
a.fsdn.com

I mean everybody trusts all that shit of course. Obviously. Dicks.

If you have common sense enough to use a console you have common sense enough to read what you paste before you press Enter. Humoring the FUD story though, you can paste shady links into a text file first THEN read them in case you paste a ^M.

Dicks.

Re:FUD

[Anonymous Coward]

You don't have to enable access to all of those domains to post a comment.

Re:FUD

[Anonymous Coward]

You don't have to enable access to all of those domains to post a comment.

If slashdot were the ONLY site you went to.... sure you might manually select the necessary ones only to allow. you may even whitelist them because fuck it. When you surf many sites you just may glance at them and temporarily allow the list. Then the next list. Then the next list. Then the next one and sometimes after 5-6 temporarily allows of subdomains... you say fuck it. What the fuck is this bullshit site anyway.

So technically no you don't have to enable ads.pro-market.net for example to post. But your counter-point is disingenuous enough that either you are pedantic or a dickhead or both.

Silent but 'Deadly'

[Anonymous Coward]

Did I miss something about making this attack 'deadly?' Is my pacemaker vulnerable to this? Just in case, I have disconnected my mouse from my pacemaker just to be sure. No right-click pasting for me!

Seen this in FB?

[ULTROS]

I have noticed that every sometimes I will see a copy or paste text when I am on FB on my android phone. Ever see this happen to you?