[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2ECE9D9EEF1F524185270138AE23265955AA31F1@S0MSMAIL111.arc.local>
Date: Wed, 17 May 2017 14:28:57 +0000
From: Fiedler Roman <Roman.Fiedler@....ac.at>
To: "oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com>
CC: "Jason@...c4.com" <Jason@...c4.com>,
"rxvt-unicode@...ts.schmorp.de"
<rxvt-unicode@...ts.schmorp.de>,
"rxvt@...morp.de" <rxvt@...morp.de>
Subject: AW: terminal emulators' processing of escape
sequences
> From: Robert Święcki [mailto:robert@...ecki.net]
>
> Hi,
>
> >> > On Tue, May 02, 2017 at 12:05:27AM +0200, Robert ??wi??cki wrote:
> >> >> A harmless example from rxvt - pushing back the new-line
> character:
> >> >>
> >> >> $ echo -ne "\eGQ;"
> >> >> ;$ 0
> >> >> bash: 0: command not found
> >> >
> >> > Does this also affect rxvt-unicode?
> >>
> >> It does, actually. I've CCd rxvt-unicode upstream on this in order to
> >> hear their assessment.
> >
> > There can't be an assessment without knowledge of what to assess -
> there
> > is little to no information in your mail. I can only guess that
> somebody
> > for the hundredth time found out that terminals are more than dumb
> > display devices and got excited that, somehow, this might be a
> security
> > issue. Without knowing details, I can't say for sure, but most likely,
> > this is a security issue the same way blindly feeding unknown commands
> to
> > your shell is,
>
> Given that arbitrary data can be pushed to terminal emulators via
> seemingly harmless commands (like ping, whois) that people rather
> trust to be robust enough to intetract with arbitrary whois or DNS
> servers, this might be some problem.
>
> Please consider the following example:
>
> $ tail -n1 /etc/hosts | xxd
> 00000000: 3132 372e 302e 302e 3309 1b47 513b 205a 127.0.0.3..GQ; Z
> 00000010: 5a5a 0a ZZ.
> $ ping ZZZ
> PING ; (127.0.0.3) 56(84) bytes of data.
> ^[G0
> 64 bytes from ; (127.0.0.3): icmp_seq=1 ttl=64 time=0.039 ms
> ^[G0
> 64 bytes from ; (127.0.0.3): icmp_seq=2 ttl=64 time=0.032 ms
> ^[G0
> ^C
> --- ; ping statistics ---
> 2 packets transmitted, 2 received, 0% packet loss, time 1014ms
> rtt min/avg/max/mdev = 0.032/0.035/0.039/0.006 ms
> ^[G0
> $ 0
> bash: 0: command not found
>
> I'm not sure if this works with real reverse DNS look-ups, but with
> /etc/hosts it seems so.
It might, same as many other programs might produce quite unexpected results. For example take "apt-get update": DNS and HTTP transfer is not trusted, so arbitrary terminal commands can executed in the terminal. (If you do not have a MitM-framework at hand, just try the update using a standard Apache server with this rewrite rule and see the title of your terminal change: "RewriteRule ^/.* http://somehostename/xx\%41\%1b\%5d\%3btest\%07xxx [NE,B,R,L]" - another good reason to run your own mirrors on a network you can try to prevent MitM, perhaps over SSL.)
In my opinion, the user of the terminal might somehow also be at fault in those examples. Anyone performing an action should have an estimation, what probability of negative outcome of an action is acceptable. The probability is affected by two things: probability the user does not behave well (mistypes, forgets something, did not read all the manuals thus misusing the tools) or the software misbehaves (according to manual, it should do something else but it does not).
So if I do not really care about quality of my work, I do not fully read the manuals, I do not care about tool qualification and risk assessment, ..., so probability for such an unexpected software feature or bug (is it a bug? therefore the manual needs to state the correct behavior and I did not completely read it) should not be higher or near than my probability of failing. The probability of failing of course includes also the probability of presence of a malicious actor and his ability to raise the probability of failure due to attack surface of tools.
When trying to do things to be safe and secure, then you will care about your own quality of work (SOPs, automation, 4 eyes, ..) but also care about the risk of software failure and try to reduce it. On the terminal topic:
* Where relevant (remote maintenance, working with user supplied data, forensics of compromised equipment, ...) most likely everything is done within system virtualization with something sanitizing away unexpected data. Something like "screen sh -c 'exec bash | strings'" might come in handy or viewing files only with xxd (how likely is a 18kb binary linked to libc only to fail?). I guess it should be common sense, not to trust a some terminal being 10x the size and additionally linking 5 large libraries when it comes to work on something really valuable.
* As you are slowed down by those measures (controlsequences for highlighting, colors, try reading "man ls" that way), enabling some control sequences might also improve your quality of work. So you need to "trust" some program to do that for you, and probably you will trust some more than others. E.g. "screen" purpose is mostly screen multiplexing with control sequence sanitation, while in GUI-terminals it is only half of the program requirements.
Just for testing to see how hard it is to use all software correctly for the paranoid/malicious use case, use xterm to see the different outcomes of data sanitation measures. Try to avoid the crash from python -c 'print "\x1b]4;4;"+"A"*(1<<20)+"\x07"' . Your measures will themselves get quite annoying when working over SSH connections as local control stripping does not work nicely with remote connections and interactive terminals. With "ssh -T" you can at least read output of "ls" quite normal. It is really a pity, that SSH client does not provide control character stripping. As such a program with "secure" in the name, expectation is that there exists an appropriate development process for security and hence the program is more likely to do it right than all the various terms out there.
Conclusio: terminal escape sequence processing is way too complex, to accept it on important systems, so just do not do it. You would not read mail or open a text document on your administration machine also.
LG Roman
PS: To find out, which terminal is less dumb than others, I used the following bziped program to see if terminal crashes, writes data to stdin or otherwise misbehaves to get an estimation of the probability of software failure.
QlpoOTFBWSZTWckOfMMAAEffgFQQae/wmr////4////0MAFbTQhqSaGjRk0DEDIAMRoyGRpk0BoB
6g1T1Tymamg0DRkNADIaBkAAA0ABJIKep6hpiFP1NpGpo9JoAxBo9TQDyTZT01PUVREfq9tosGe5
mTHx8EIXYPwLbeEk4QTnmRsQ/M9KcEjg4QIkMblRAgd0HBcEwSggUTBiDBLa1jVpewypU2WEKGTQ
KSviMlg0h6tjMXFICMCGjMlbfwZ5ynd5QID98S3xjlcYgTdou4WZsbirIXAv4XjxhrOHlpyKEy5j
WGWs+hvTcINTjuvZtexP7t8HCGLkW2GMcZgQE101MADuR1GvVLs956jtwpLcbK6tkuxu2SPosUkG
1aaaNdKKeBVTTTYrw/HiS86K6tzFakd7O3gMrIre8dB+YAy/1RSuKgCqc8uXcUMMxpUcBZHxEMHh
ZBdfa7PiRqSmjlYM/7mLSxj3lUmZvzO21Ec9eUrZ4yThkxH/ObMRInOPPFUqxK6kiBf4u5IpwoSG
SHPmGA==
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
