AcceptEnv LANG LC_* vs available locales

Christoph Anton Mitterer calestyo at scientia.org
Fri Apr 29 11:57:51 AEST 2022


On Thu, 2022-04-28 at 20:29 -0400, Demi Marie Obenour wrote:
> > That said, on non-OpenBSD systems, if the locale used by a program
> > does
> > not match watch the user thinks, the *semantics* of the program may
> > still
> > screw up horribly, even if the character encoding matches.  For
> > example,
> > consider user input of floating point numbers with LC_NUMERIC set
> > to a
> > cultural convention the user isn't aware of.  But such issues are
> > only loose related to ssh(1) and to terminal security.
> 
> When it comes to terminal security, another approach is to use
> a transient tmux(1) pane or terminal window that is closed once
> the session is complete.  This assumes that the mismatch cannot be
> exploited for code execution, but I would be highly surprised if it
> could be, especially with the client in UTF-8 mode.

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


With or with any locale/character encoding differences, the (possibly
evil) remote side can send any arbitrary bytes to the terminal.

But how could it use this to for code execution on the local machine?


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.


What should be the attack with e.g. LC_NUMERIC? 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?

Similar, if a evil remote side could swap yesexpr and noexpr in
LC_MESSAGES?
So what?
Tricking a user in to rm -ri / and then using 'n' which would then mean
'y'?
If the remote side can do this, it can again just delete those (remote)
files?


Cheers,
Chris.


More information about the openssh-unix-dev mailing list