hterm control characters pasting vulnerability
Reported by
starfall...@gmail.com,
Mar 21 2018
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36 Steps to reproduce the problem: Hello, When pasting characters into hterm (https://github.com/chromium/hterm), control characters are allowed. This turns to be a security problem, due to the fact that when pasting these characters into terminal text editors, such as vi/vim, emacs, nano, etc., when using Secure Shell for example, remote command execution is possible. Please note that if google has other terminal emulators this might also work there. To reproduce using vi/vim, create an html with the following command: $ printf '<html>something;:!id<br>a</html>' > poc.html Open the poc.html in a browser, select and copy the text that is presented, and paste it into vi/vim in insert mode. The command "id" should then be executed. This works because pasting "" is allowed, wich is the "escape". By pressing "escape" in insert mode, it is possible to go back to default mode, and by using the exclamation mark (!) it is possible to execute arbitrary commands. To reproduce using nano, create an html with the following command: $ printf '<html>something<br>something\x18y\b\b\b\bfile<br>y<br>a</html>' > poc.html Open the poc.html in a browser, select and copy the text that is presented, start nano with "nano test", and paste the contents in nano. This should quit you from nano, but instead of saving the contents into the file "test", it saves them into "file". This works because '\x18' is ^X (Control-X), which exits nano. On exit, it asks if you want to "Save modified buffer", so you press 'y'. This is why there's an 'y' after '\x18'. Once you press 'y', it asks the "File Name to Write". If you started nano with an argument, such as "nano test", then it will appear as the default "File Name to Write". In order to specify an arbitrary file name, and overwriting an existing one, we can use multiple '\b' to delete this file name, and then specify our target file name. To get remote command execution, an interesting target would be ".bashrc". However, as a PoC I used "file" as can be seen after the 4 '\b'. Since "test" is 4 characters, I used 4 \b. You should use "nano test" to try the above. As a remote attacker, you don't know how many characters your target used for the file name, but you can input an arbitrary number of \b. We could use 255 \b since that's the file name limit in most filesystems. To reproduce using emacs, create an html with the following command: $ printf '<html>something;!id<br>a</html>' > poc.html Open the poc.html in a browser, select and copy the text that is presented, startemacs with "emacs -nw file", and paste the contents into it. This should execute the command "id". This works because pasting "" is allowed, wich is the "escape". By pressing "escape" and then "!" (M-!) it is possible to execute arbitrary commands in emacs. The command "id" will be executed, but you may not see the output in emacs. Use something like "touch file" and see that "file" was created. One could argue that an user could see that what is being copied from the browser is malicious, but it is easy fool the user. [1] The correct solution would be to disallow the pasting of certain control characters. One could argue that an user could see that what is being copied from the browser is malicious, but it is easy fool the user. [1] The correct solution would be to disallow the pasting of certain control characters. See: [1] https://thejh.net/misc/website-terminal-copy-paste [2] http://invisible-island.net/xterm/xterm.log.html#xterm_292 [3] https://bugzilla.gnome.org/show_bug.cgi?id=753197 Thanks, Federico Bento. What is the expected behavior? What went wrong? Included in "Steps to reproduce the problem" Did this work before? N/A Chrome version: 62.0.3202.94 Channel: n/a OS Version: Flash Version:
,
Mar 21 2018
Not necessarily. Issue 228966 does not mention the use of control characters, which should be dropped when pasting.
,
Mar 21 2018
One thing is pasting directly into the terminal's shell like Issue 228966 , but pasting into a text editor and being able to execute arbitrary commands is another, in my opinion.
,
Mar 22 2018
Adding the hterm component because this seems likely better handled on the terminal emulator side of things (that seems to be roughly what the consensus was on Issue 228966 , particularly comment #9). vapier@ I saw you have handled some hterm input bugs in the past. Would you be able to take this or help find an owner? Not 100% sure on OS labels for this. hterm/nassh would be more commonly used on ChromeOS, but available on all (and there are downstream projects too I believe). I'll mark this for all OSes with extensions for now. Marking this as Severity-Medium (because it requires a user to copy+paste input) and Impact-None (because I believe we don't ship hterm by default anywhere).
,
Mar 22 2018
I am not familiar with ChromeOS, but isn't hterm shipped by default there? Isn't hterm related to crosh? Thanks.
,
Mar 22 2018
from the pov of hterm/terminal emulators, this isn't a bug, this is WAI. you can make the same claim against pretty much every other terminal emulator out there too ... you can paste lots of escape chars directly to the remote side and let them run. this is [basically] why the bracketed-paste sequence was implemented: https://cirw.in/blog/bracketed-paste hterm supports that as do newer shells/programs/libs. whether the Blink guys want to change processing of data in some way is up to them, but hterm doesn't need any changes. if the Blink guys are happy with their state of things, then we can simply punt this bug.
,
Mar 22 2018
It's WAI, but it's a dangerous "feature" that should be fixed. Just because other terminals also behave this way, doesn't mean they're doing it right. Because of that xterm fixed this as seen in [2] above and also libvte (gnome-terminal and others use it) as seen in [3] by swallowing control characters. From https://groups.google.com/forum/#!topic/vim_dev/RkOo2EjSYOk "Bram, There was a problem about pasting special terminal chars reported at http://seclists.org/oss-sec/2018/q1/213 Initially I thought that bracketed-paste mode will prevent such things, but it seems this still works. Is there anything Vim can do to prevent such things (at least when pasting in bracketed paste mode)? " I don't also buy it when people say "Well, maybe you shouldn't be pasting directly into a Terminal". 1) Not everyone is a security professional; 2) Even the majority of security professions don't know about this; 3) It can be simply fixed. I'm reaching out to the devs of the most commonly used terminal emulators out there, and they are agreeing that there's a problem and are fixing it.
,
Mar 23 2018
i don't agree it's a bug in hterm or terminal emulators in general. i understand that some people might find it surprising, and some people might not like it. but there's a lot of things people find surprising in the *nix world. if you don't like this behavior, we already provide a way to control it via bracketed paste support.
,
Mar 23 2018
The problem isn't me, I'm well aware of this issue. I'm concerned about other people since many of them don't know about it and bracketed paste support isn't on by default.
,
Mar 23 2018
i totally understand that at this point, this isn't a security issue for hterm. if you want to discuss things further, feel free to use the user/dev mailing list: https://groups.google.com/a/chromium.org/forum/#!forum/chromium-hterm i'll close this out. if the blink guys want to re-open or track elsewhere, feel free.
,
Jun 30 2018
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by elawrence@chromium.org
, Mar 21 2018