On Mon, 2022-05-02 at 08:25 +0000, halfdog wrote: > > Any concrete example which allows *local* (i.e. client side) > > execution of code/commands? > > https://unparalleled.eu/blog/2021/20210518-using-xterm-to-navigate-the-huge-color-space/ Interesting one... > 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). ... such a simple feature... where no one would have imagined that it could lead to such big compromise. > 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]" I've also had that in mind... thus specifically CCing Damien and Darren so that they see this. Can you guys imagine to extend ssh, so that when output is connected to a terminal, it filters escape sequence (to a varying degree, depending on some configuration setting)? The default could be just as is, i.e. no filtering. But there could be an option that allows to specify escape sequence filtering on a per host basis. The more the host is trusted, the more one could allow it. E.g. Host absolutely-untrusted.example.org TerminalEscapeSequences !all Host semi-trusted.example.org TerminalEscapeSequences !all default Host fully-trusted.example.org TerminalEscapeSequences !all default clipboard starting from the default ("all"), "!all" would first filtering really all escape sequences (thereby probably breaking everyhing), "default" would again allow some sequences that are generally considered safe... and e.g. "clipboard" would specifically allow OSC52... or "links" which would enable the OSC that makes hyperlinks, "!colours" could disable any colour escape sequences, and so on. There could be one "minimal", which is like "default" but without and fancy stuff (e.g. no colours) just the bare minimum. Any one could maybe another option, which controls when that filter kicks in, e.g. never, when connected to a terminal, always (even if no terminal is detected). That would make sanitisation available out of the box for SSH users, not requiring any thing else that cleans possibly problematic sequences from untrusted remote nodes. Terminal authors continue to add such features, that may have a legitimate use case for local terminals, but could be dangerous when these are controller by remote machines. So such filtering on SSH level could be a further guard. Cheers, Chris. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
