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 _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
