Bug 1557758

Summary: Terminal Emulators Control Characters Pasting Vulnerability
Product: Red Hat Enterprise Linux 7 Reporter: Federico Manuel Bento <up201407890>
Component: konsoleAssignee: Jan Grulich <jgrulich>
Status: CLOSED ERRATA QA Contact: Desktop QE <desktop-qa-list>
Severity: high Docs Contact:
Priority: unspecified    
Version: 7.7-AltCC: bsanford, mboisver, tpelka, up201407890
Target Milestone: rc   
Target Release: 7.9   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: konsole-4.10.5-5.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-09-29 19:26:06 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Federico Manuel Bento 2018-03-18 12:24:56 UTC 
Hi,

I selected the component Konsole, but this applies to all Terminal emulators that are vulnerable to this dangerous design. How is this being dealt with?

http://www.openwall.com/lists/oss-security/2018/03/05/2

"Hello,

When pasting characters into several terminal emulators, 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., remote code execution is possible.

This is supposed to be fixed in recent versions of VTE [3], which  
means VTE-based terminal emulators should be safe, but the problem is  
that most distros are shipping older versions and remain vulnerable.

Here's a list of terminal emulators I tested this where it worked.  
Some came by default in my distro (debian), others were installed via  
apt-get. This should also work on other distros:

LXTerminal
rxvt
urxvt
putty
gnome-terminal
Konsole
Guake
Yakuake
tilda
Terminator
xfce4-terminal
Terminology
ROXTerm
sakura
lilyterm
Eterm
aterm
mrxvt
pterm


Please, update VTE and check if the below still works. For the others  
that aren't based on VTE, CVEs should be assigned to each of them. Can  
someone help me figure out which ones are based on VTE and those that  
aren't?

To reproduce using vi/vim, create an html with the following command:

$ printf '<html>something;&#27;:!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 "&#27;" 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;&#27;!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 "&#27;" 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.

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."
Comment 2 Jan Grulich 2020-02-17 11:03:06 UTC 
Can be fixed with https://cgit.kde.org/konsole.git/commit/?id=0b482990279d6684089a404df7473f0354c284c3.
Comment 7 Bill Sanford 2020-05-15 14:35:33 UTC 
The escape characters are no longer displayed in browser of the HTML file, thus not being able to be copied.
Comment 9 errata-xmlrpc 2020-09-29 19:26:06 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (fltk bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:3872