Christoph Anton Mitterer writes: > On Fri, 2022-04-29 at 12:53 +0200, Ingo Schwarze wrote: >> [...] >> > 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? The closest one I know about: https://unparalleled.eu/blog/2021/20210518-using-xterm-to-navigate-the-huge-color-space/ In the end it exploited an integer overflow in libx11, most likely introduced in _1986_! The POC injects X11 protocol commands to gain full control over your local desktop (injecting keystrokes, key logging). But in the end you do not even need that to compromise the client. Terminals seem to be more designed with usability in mind than security. That is understandable as 1) they are the main user interface for text based communication and 2) terminals usually are used to access local applications, so malicious input or output most likely means, that it is game over already. So their attack surface may be huge, not only the terminal code itself, but also those functions invoked by it, e.g. UTF-8-decoding, terminal control sequences and clipboard interacting with the graphics system, window manager, other applications again listening to those, ... If I may voice an opinion, instead of having a complicated "LANG LC_*" negotiation algorithm, I would more like to see an integrated SSH data filter to run all unencrypted data through before reaching the other side (both directions). -o "TerminalDataFilter [some program]" On a trusted server, the "LANG LC_*" usecase would be easy to implement, as the filter could (hiddenly) negotiate whatever it wants before doing plain input/output forwarding. Paranoid users may use the filter instead for full data sanitation, e.g. replacing all non-whitelisted control sequences, all parts of UTF specification, they will not use anyway, ... with some escape code (thus messing up the display, but I would rather like to know when someone is trying to hit me than have a nice display). Insanely paranoid user may even think of implementing an application layer firewalling for terming-data, e.g. blocking unexpected (e.g. very large) copy&paste inputs, whitelist the commands allowed to be sent to the server, warn on known dangerous commands (tail -f /var/log/syslog), ... Kind regards, hd _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
