AcceptEnv LANG LC_* vs available locales

[Ingo Schwarze]

Hi Christoph,

Christoph Anton Mitterer wrote on Fri, Apr 29, 2022 at 03:57:51AM +0200:

> Maybe it's too late in the night and I just miss the obvious point,...
> 
> ... but what exactly is the security problem here (if one sends
> LC_*/LANG ... or with locales in general)?

I already posted a link to an essay explaining that in this very thread:

  https://undeadly.org/cgi?action=article&sid=20160308204011

> With or with any locale/character encoding differences, the (possibly
> evil) remote side can send any arbitrary bytes to 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.  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).

> 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.

> The only attack vector I see would be:
> A remote side tricking a user into believing that he left SSH (but is
> still on the remote side)... and then tricking him into e.g. entering a
> password. But that should be independent of the locale/character
> encoding.

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?
There are certainly plenty of options to choose from.

> What should be the attack with e.g. LC_NUMERIC?

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.

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.

> 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.

> Similar, if a evil remote side could swap yesexpr and noexpr in
> LC_MESSAGES?
> So what?

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.

Note there are at least three very different levels of problems here,
but all of them are exacerbated by automatic passing of LC_* and
the implicit user expectations trained by that passing:

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

 - 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?

Yours,
  Ingo