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