Discussion:
Terminal Control Chars
(too old to reply)
u***@alunos.dcc.fc.up.pt
2018-03-05 16:50:24 UTC
Permalink
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.

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
Jesse Hertz
2018-03-06 01:19:10 UTC
Permalink
I looked into this on OSX, and confirmed Terminal.app is vulnerable, but iTerm.app is not vulnerable.

Cheers,
-jh

*this is not an official apple email and is not representative of Apple prodsec. I just happened to be poking around*
Post by u***@alunos.dcc.fc.up.pt
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.
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?
$ 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.
$ 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.
$ 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.
[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.
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
Ian Zimmerman
2018-04-09 17:11:05 UTC
Permalink
Post by u***@alunos.dcc.fc.up.pt
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
[...]
Post by u***@alunos.dcc.fc.up.pt
urxvt
[...]
Post by u***@alunos.dcc.fc.up.pt
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?
As far as I can see, urxvt (aka rxvt-unicode) does not use vte.
--
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.
Not Real
2018-04-09 18:35:21 UTC
Permalink
This is posted here every few months. Frankly, there's a lackluster care in
fixing this in these terminals.
For terminals, here's a decent avenue (gnome-terminal as example):

https://turbochaos.blogspot.com/2014/08/journalctl-terminal-escape-injection.html
Jakub Wilk
2018-04-10 10:24:03 UTC
Permalink
Post by Not Real
This is posted here every few months.
The thread subject is not as informative as it could be. The original
post was about pasting control characters. While the problem is not
new[0], I don't recall it being ever discussed on oss-security before.
Post by Not Real
https://turbochaos.blogspot.com/2014/08/journalctl-terminal-escape-injection.html
OTOH, this is about terminal escape injection, an entirely different
problem, and a frequent topic on oss-security.


[0] The original post links to
https://thejh.net/misc/website-terminal-copy-paste (from 2013?),
which links to
http://www.ush.it/team/ascii/hack-tricks_253C_CCC2008/wysinwyc/what_you_see_is_not_what_you_copy.txt
(from 2008).
--
Jakub Wilk
Gordo Lowrey
2018-04-10 07:53:17 UTC
Permalink
Post by u***@alunos.dcc.fc.up.pt
The correct solution would be to disallow the pasting of certain
control characters.
I'm just gonna go out on a limb here, and say this is an unfounded
assertion.

Perhaps the correct solution would be to prevent the browser from
copying invisible characters.

If you're going to break some basic mechanic of human computer
interaction, at least don't break my damn terminal (not that I use VTE,
it doesn't support OSC 52, among others), but the principle stands...
Instead of worrying about sanitizing what is pasted, why not worry
about sanitizing what is copied instead?

Thanks.
Christian Brabandt
2018-04-10 11:02:27 UTC
Permalink
Post by Gordo Lowrey
Post by u***@alunos.dcc.fc.up.pt
The correct solution would be to disallow the pasting of certain control
characters.
FWIW: The vim poc has been "fixed" as of
https://github.com/vim/vim/releases/tag/v8.0.1587
Post by Gordo Lowrey
I'm just gonna go out on a limb here, and say this is an unfounded
assertion.
Perhaps the correct solution would be to prevent the browser from copying
invisible characters.
If you're going to break some basic mechanic of human computer interaction,
at least don't break my damn terminal (not that I use VTE, it doesn't
support OSC 52, among others), but the principle stands... Instead of
worrying about sanitizing what is pasted, why not worry about sanitizing
what is copied instead?
That was also the conclusion on the vim-dev list.

There is a similar Debian bug report against rxvt-unicode where the same
conclusion is drawn:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787628#15

And the corresponding mozilla/firefox bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=637895

Best,
Christian
Jakub Wilk
2018-04-12 17:13:27 UTC
Permalink
Post by Gordo Lowrey
Post by u***@alunos.dcc.fc.up.pt
The correct solution would be to disallow the pasting of certain
control characters.
I'm just gonna go out on a limb here, and say this is an unfounded
assertion.
Perhaps the correct solution would be to prevent the browser from
copying invisible characters.
Do you mean control characters, or something else?
Post by Gordo Lowrey
If you're going to break some basic mechanic of human computer
interaction,
Huh? Most users don't interact with their terminal-based software by
pasting control characters. I bet most people don't even realize that
it's even possible to do that. I've been using terminal emulators for 15
years, and the only time I willingly did such pastes was to test
exploits for this very problem.

If you have a practical use case for such interaction, please tell us
what is. I, for one, have no idea what this might be.
Post by Gordo Lowrey
Instead of worrying about sanitizing what is pasted, why not worry
about sanitizing what is copied instead?
Why? Is it the browser fault that terminal emulators interpret some
characters in a funny way?

Besides, paste consumers have much better idea what needs to be
sanitized than paste producers.

* For software that access the clipboard directly, no sanitization is
needed. Yay!

* On some systems, if terminal is a cooked mode, control characters can
be escaped, usually with ^V. (But a paste producer can't possibly know
what the terminal mode or the escape character is going to be!)

* In bracketed paste mode, the only sequence that needs to be
neutralized is the one that leaves the mode.

From egoistical point of view, I'd also prefer if this was fixed in my
terminal. On my system, I have multiple paste producers potentially
affected by this (web browser, two PDF readers, office suite, ...), but
only one terminal emulator installed. It's much easier for me to verify
that the terminal emulator behaves (it doesn't) than to check the rest
of the software involved in this mess.

BTW, a recent LWN article about terminal emulators briefly mentioned the
problem of pasting security:
https://lwn.net/Articles/749992/
(The article incorrectly states that urxvt's confirm-paste plugin
protects against this attack. Read the article comments to see why this
is not the case.)
--
Jakub Wilk
Ian Zimmerman
2018-04-12 18:07:20 UTC
Permalink
Post by Jakub Wilk
Post by Gordo Lowrey
Perhaps the correct solution would be to prevent the browser from
copying invisible characters.
Do you mean control characters, or something else?
The term "invisible character" has some obvious (if perhaps informal)
meaning. But I don't really know what "control character" means. Is a
page separator (^L) a control character, for example? Is DEL one (ASCII
127)?
--
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.
Russ Allbery
2018-04-12 19:01:06 UTC
Permalink
Post by Ian Zimmerman
The term "invisible character" has some obvious (if perhaps informal)
meaning. But I don't really know what "control character" means. Is a
page separator (^L) a control character, for example? Is DEL one (ASCII
127)?
I think a useful definition of "control character" in this context (and I
realize this doesn't exactly match the ASCII definition) is a character
that results in an action other than insertion being taken, as opposed to
a glyph (possibly invisible) being inserted (and not counting contexts
such as vi outside of insert mode where basically all characters are
interpreted as actions).

CR and LF would not be control characters in that definition, since they
insert a newline and don't cause an action. Similarly, TAB wouldn't be a
control character in that definition. DEL would be if it deleted a
character as opposed to inserting a ^? sequence. ESC would be if it
changed terminal modes or colors or did all the other things escape
sequences can do. BEL would be if it rung the terminal bell. And so
forth.

I think it's reasonable to expect that pasting something into a terminal
will cause insertion of text, including whitespace, but will not cause the
terminal to take *actions* that are not the insertion of text. Certainly,
I think there are a lot of people in the world who do have that
assumption.
--
Russ Allbery (***@eyrie.org) <http://www.eyrie.org/~eagle/>
Jakub Wilk
2018-04-13 07:43:10 UTC
Permalink
Post by Jakub Wilk
Post by Gordo Lowrey
Perhaps the correct solution would be to prevent the browser from
copying invisible characters.
Do you mean control characters, or something else?
One reason I asked because for some people knee-jerk reaction upon
learning about this issue is to insist that the browser should only copy
what the user sees. Cleverly, they never elaborate what that means
exactly.

Is a "font-size: 3pt" text visible? Should the browser consult the
user's eye exam results before deciding what to copy?

Does it mean Ctrl+A Ctrl+C would copy only text within the viewport? I
guess so, but that's not what browser users expect.

And in the PDF world: the user is often shown a scan, and there's a
hidden copyable text layer. Should the PDF browser somehow refuse to
copy text with recognition errors?
Post by Jakub Wilk
Post by Gordo Lowrey
If you're going to break some basic mechanic of human computer
interaction,
Huh? Most users don't interact with their terminal-based software by
pasting control characters.
As it was noted elsewhere in this thread, tabs and newlines are control
characters, too. People paste them all the time. But I don't think
anyone is seriously proposing to filter out these two.
--
Jakub Wilk
Jakub Wilk
2018-04-10 15:20:52 UTC
Permalink
AFAICT, these terminal emulators are VTE based:

Guake
LXTerminal
ROXTerm
Terminator
gnome-terminal
lilyterm
sakura
tilda
xfce4-terminal

These are not:

Eterm
Konsole
Terminology
Yakuake
aterm
mrxvt
pterm
putty
rxvt
urxvt
--
Jakub Wilk
David A. Wheeler
2018-04-12 21:18:45 UTC
Permalink
Post by Ian Zimmerman
The term "invisible character" has some obvious (if perhaps informal)
meaning. But I don't really know what "control character" means. Is a
page separator (^L) a control character, for example? Is DEL one (ASCII
127)?
The term "control character" has a standard definition for every encoding
I'm familiar with. ASCII defined a set of control characters, and
Unicode built on them.

The Unicode list of control characters is here:
https://www.fileformat.info/info/unicode/category/Cc/list.htm
You'll see it includes:
U+0007 BELL
U+0008 BACKSPACE
U+0009 CHARACTER TABULATION
U+000A LINE FEED (LF)
U+000C FORM FEED (FF) (aka ^L)
U+000D CARRIAGE RETURN (CR)
U+007F DELETE

According to Wikipedia <https://en.wikipedia.org/wiki/ASCII>,
the set of control characters in US-ASCII is 00..1F and 7F (hex).
Post by Ian Zimmerman
I think a useful definition of "control character" in this context (and I
realize this doesn't exactly match the ASCII definition) is a character
that results in an action other than insertion being taken...
CR and LF would not be control characters in that definition, since they
insert a newline and don't cause an action. Similarly, TAB wouldn't be a
control character in that definition.
As you noted, that definition doesn't match the ASCII definition, but
I also think it's misleading. If someone pastes a CR/LF into a shell prompt,
it certainly *DOES* cause an action, namely, execution of that line.
That's probably not what you meant by "action", but from a security
point-of-view, causing a script to execute is rather important :-).

--- David A. Wheeler
Russ Allbery
2018-04-12 22:31:19 UTC
Permalink
Post by Russ Allbery
I think a useful definition of "control character" in this context (and
I realize this doesn't exactly match the ASCII definition) is a
character that results in an action other than insertion being taken...
CR and LF would not be control characters in that definition, since
they insert a newline and don't cause an action. Similarly, TAB
wouldn't be a control character in that definition.
As you noted, that definition doesn't match the ASCII definition, but I
also think it's misleading. If someone pastes a CR/LF into a shell
prompt, it certainly *DOES* cause an action, namely, execution of that
line. That's probably not what you meant by "action", but from a
security point-of-view, causing a script to execute is rather important
:-).
That's a fair counterpoint.

That unfortunately means that the specification one wants is to deny
pasting control messages except for a particular set (since you're
certainly not going to want to stop pasting of a newline sequence, and
probably not pasting of tabs), and then you have to find the right way to
define that set of characters that you want to allow.

I have some "I know it when I see it" definition in my head, but it's hard
to be precise without listing out the specific characters that I would
allow and that I would disallow (at least as interpreted commands).
--
Russ Allbery (***@eyrie.org) <http://www.eyrie.org/~eagle/>
Simon McVittie
2018-04-12 22:54:41 UTC
Permalink
Post by David A. Wheeler
Post by Russ Allbery
I think a useful definition of "control character" in this context (and I
realize this doesn't exactly match the ASCII definition) is a character
that results in an action other than insertion being taken...
CR and LF would not be control characters in that definition
As you noted, that definition doesn't match the ASCII definition, but
I also think it's misleading. If someone pastes a CR/LF into a shell prompt,
it certainly *DOES* cause an action, namely, execution of that line.
I hope you're not proposing that, to protect users of terminal emulators,
general-purpose web browsers should not allow copying more than a
paragraph at a time? That seems like a change that is unlikely to be
accepted.

Similarly, if filtering of pastes is done at the destination side (the
terminal emulator), it would seem bad to be unable to paste more than
a line at a time into a text editor that happens to be running in a
terminal emulator (for instance the one in which I'm writing this email).

Russ's more loose definition of "control character" (in particular,
preventing copying and/or pasting ESC and the 0x80-0x9F range) would be
enough to protect users of a terminal/shell combination that supports
bracketed paste, as far as I'm aware?

smcv
Jakub Wilk
2018-04-16 08:15:00 UTC
Permalink
Post by Russ Allbery
I think a useful definition of "control character" in this context
(and I realize this doesn't exactly match the ASCII definition) is a
character that results in an action other than insertion being
taken... CR and LF would not be control characters in that definition,
since they insert a newline and don't cause an action. Similarly, TAB
wouldn't be a control character in that definition.
As you noted, that definition doesn't match the ASCII definition, but I
also think it's misleading. If someone pastes a CR/LF into a shell
prompt, it certainly *DOES* cause an action,
Similarly, tab is an "active" character in most shells.

In the worst case (the victim uses bash with bash-completion installed,
and the attacker has write access to the victim's filesystem), pasting
tab can be as bad as pasting LF.

Here's a proof of concept:

$ printf 'x := $(shell (echo; cowsay pwned)>/dev/tty)' > moo
$ make -f moo <tab>
_______
< pwned >
-------
\ ^__^
\ (oo)\_______
(__)\ )\/\
||----w |
|| ||

Credit for discovering this goes to Dan Rosenberg:
https://twitter.com/djrbliss/status/699363006946344963
--
Jakub Wilk
David A. Wheeler
2018-04-13 00:07:56 UTC
Permalink
Post by Simon McVittie
I hope you're not proposing that, to protect users of terminal emulators,
general-purpose web browsers should not allow copying more than a
paragraph at a time?
Not at all! My point is that we should be careful about terminology.
"Control characters" already has a well-known standard definition,
using the same term for a different set is confusing & could lead to misimplementation.
Just call them something else that doesn't already have a standard
definition ("dangerous bytes" or whatever).

--- David A. Wheeler
Continue reading on narkive:
Loading...