Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
DescriptionFederico 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;:!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.
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."
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