AcceptEnv LANG LC_* vs available locales

[Christoph Anton Mitterer]

On Fri, 2022-04-29 at 12:53 +0200, Ingo Schwarze wrote:
> I already posted a link to an essay explaining that in this very
> thread:
> 
>   https://undeadly.org/cgi?action=article&sid=20160308204011

Well I had read that but didn't understand the concrete attack from
it... other than garbling up the terminal.


> Even is the user on the client side trusts root on the server that
> the
> program /bin/ls is not malicious but does what it is designed to do,
> including proper output sanition, a locale mismatch may make it
> trivial
> for unprivileged users on the server to mount attacks by simply
> placing
> maliciously named files into the file system, such that, depending
> on your terminal settings on the client, for example "ls /tmp/" might
> result in remote code execution on the client.

On the client?! How would that work?

I mean that would either mean...

... that there needs to be some way via ssh itself, ... the only thing
I can think of is that via some tricky escape sequences ssh could be
tricked into believing ~C was pressed. But I'd hope that it only uses
the ssh client's stdin for that, which the remote shouldn't be able to
mess with?!

... or if the terminal would provide any escape sequences for local
code execution.
I couldn't find any such for xterm,... are there?

The worst thing I'm aware of are things (like OSC 52, see
e.g. https://gitlab.gnome.org/GNOME/vte/-/issues/2495#note_1176783 and
I'm still not 100% sure their safeguard is 100% save ) which would
allow an attacker to read/write to the clipboard.
Or perhaps things like creating clickable URLs in the terminal, which
the user might accidentally click on.


But for all these things I don't see the specific dependence on any
evil-local-games?

If the remote root (or hardware) is compromised, it can replace all
programs anyway, and send any terminal escape sequence via any (e.g.
ls) it likes.
Regardless of any locale settings.

If only the remote (non-root-)user was compromised, it could still do
so in many cases (by overwriting the remote PATH and have his forged
versions of standard tools being used). Similarly it could just set any
desired LC_*/LANG in .profile/etc.?
The only exception was if a command were directly executed by ssh on
the remote side... but IIRC, even if you do ssh example.org command, it
still runs the command via a shell (just not a login shell), so e.g.
.bashrc would still be executed and give a compromised remote user the
chance to do some evil.


> Mounting DOS attacks is
> even easier and typically works out of the box with the default
> xterm(1)
> configuration on most operating systems (not on OpenBSD any more,
> though).

Sure... but e.g. what you've described in the earlier link, didn't work
for me.
And if such DOS happens, then people simply close the terminal windows
and start a fresh one?

Or is there anything like terminal escape sequences being able to map
character key codes, e.g. that one types "en .ed &" but the terminal
sends "rm -rf /" to the process?


> > But how could it use this to for code execution on the local
> > machine?
> 
> By the remote attacker sending whatever of
> 
>   https://invisible-island.net/xterm/ctlseqs/ctlseqs.html
> 
> is most inconvenient for you, the user on the client?
> Good luck making sure nothing from that next to interminable list is
> inconvenient for you.  Other terminals and terminal emulations may
> have
> similar lists of in-band controls.

Any concrete example which allows *local* (i.e. client side) execution
of code/commands?

IMO any such would be grave security holes in the terminal, but still
rather unrelated to the locale.


And I'm not saying that the situation with terminals is good...
Take the aforementioned OSC52.
Or similarly OSC 7 (https://gitlab.freedesktop.org/terminal-
wg/specifications/-/issues/20#note_956242 ), which allows setting the
(local) current working directory and could IMO allow for subtle
attacks.

But I'm kinda missing the smoking gun, which allows the direct local
code execution you indicate.


> Well, attackers tend to be creative, so social engineering is
> certainly
> one among the many options.  Maybe change window titles and key
> bindings from the remote side or remap some output characters?

I'd say the changed window titles is kinda "expected"... I.e. no sane
person would assume that if the window title says "execute rm -rf / as
root now" this is some advise from the local system that one should do.

Are there really char remapping sequences? But these should still only
affect the terminal window in question, right? Not anything else.

These
https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-Mouse-Tracking
seem a bit concerning...


So perhaps the best would be if SSH had a mode where it filters any
terminal sequences that are not deemed generally safe.
Of course it would need to do so only when the output actually goes to
a terminal.


> For an attacker, LC_CTYPE is probably the more rewarding target.
> But if you type 42,95 EUR because you think you have a german
> locale and that turns out to mean 4295 EUR because the server
> actually uses a US locale (or something like that), i expect it
> might have unfortunate consequences in some situations.

Sure but if you trust the remote side to do any wire transfers for
you,... and remote is compromised, ... it doesn't need to play any
cumbersome locale games... it simply replaces the program, captures
your password/etc. (that you use to authorize the tranfer) and fills in
any number it wishes.


> Besides, it is not just attacks that you should worry about,
> but also accidental misbehaviour of application programs if the
> locale used is not the one you think.

I don't think these are the big problems. The reality is, that most
systems have the standard set of e.g. glibc locales installed, so even
if you send your LC_*/LANG to remote, you'll see there more or less the
same than what you have here (given the locales are enabled there - and
if not, you see errors right away).

Most people use nowadays UTF8 locales, so unless one uses some very
weird char encoding, that should be just fine too.


But again, even if there would be problems in that field... an attacker
could simply set another locale in the remote .bashrc/etc.?



> > A remote side tricking
> > a user into using 3,14 instead of 3.14 and that having some
> > attacking
> > effect? But if the remote side can mess with the locale (on its own
> > side)... it can anyway already do it's attack there?
> 
> One among the issues here is that if users get used to LC_* usually
> being transparently passed along, misbehaviour may take them by
> surprise when they stumble upon a server that simply doesn't have
> their locale installed - even when the character encodings match
> and even when there is no attackaer involved.

Well and if they don't pass it on (and even if the remote side *would*
have their "native" local installed),.. they might be easily confused
by a huge number of remote systems and not knowing which of them uses
e.g. which decimal symbol.

So from that PoV it would IMO actually make more sense to *do* send
these env vars so that it's likely that the user get's the same
behaviour is is expecting locally.
And again, if the remote side was evil in that case... it could be so
with or without any variable passing.


> Again, no attacker needed to come to grief, it is trivial to imagine
> all kinds of trouble.  The user wants to delete a sensitive file
> because
> it contains secret information, for example before making the
> directory
> readable for other users.  Since they have a german locale set on the
> the
> client side, they type "ja" when the program on the server asks
> whether
> they really want to delete the file.  But the server does not have a
> german locale installed, so "ja" actually means "no", the file
> remains,
> and the secret information is accidentally disclosed without the poor
> user even suspecting something might have gone wrong.

Sure... but even I wouldn't call this a real attack vector (and I call
things like the remote side being able to just *set* (not even read) my
clipboard a possible attack vector).

Similar issues can happen with or without any local games...you just
need different versions of tools, and some option wasn't supported yet.

So at best this seems like cases of accidents, but none which are
really restricted to consequences of non-matching locales. I guess
these kinds of problems are simply expected.


>  - Accidental misbehaviour, causing the user to not accomplish
>    what they think they accomplished, or receiving incorrect
>    answers to whatever questions they intended to ask.

I wouldn't call these attacks... either they're because of non-matching
locales or different software version and the like, and that's simply
something one needs to expect when one goes on a remote system.
Just as I cannot expect the remote system to be Debian and have e.g.
aptitude installed.


>  - Attacks of unprivileged users on the server against terminal
>    security on the client, even when root on the server is
>    trustworthy and utility programs on the server do proper
>    sanitation before sending data over the wire.
> 
>  - Attacks by malicious server administrators are probably the
>    least concern.  Then again, if /etc/ssh/banner did remote
>    code execution on the client, i guess that *would* surprise
>    you, wouldn't it?

I am in fact concerned about terminal implementers adding more and more
features that might at least subtly be abused... and these typically
seem to be even always-on and not opt-in.


But I still haven't seen a concrete remote code execution example here.
Changing the window title barely isn't an attack.



Cheers,
Chris.