3 ms·
Every single concern you just listed is valid and are indeed being used in real exploits, the output into input is just one way to exploit terminals, there are
by unixbane 4y ago
Every single concern you just listed is valid and are indeed being used in real exploits, the output into input is just one way to exploit terminals, there are several more. I'm sitting here laughing because usually when we bring up these issues about doing insanely insecure bad ideas, a UN*X diehard will come over and talk about how we don't know anything and "PoC or GTFO", as opposed to putting any effort into stopping the insecure bad idea. A prime lesson every hacker ("cracker") learns quickly is that anything that looks insecure will likely actually later turn out to be extremely insecure, even if you can't immediately figure out a way to exploit it.
I discovered wall and write at some point and was amazed how stupid that was. At some point some distros started getting rid of them but I gave up trying to understand UN*X long before that point as it was clearly a joke OS.
> This could matter if you use "sudo".
The most common concerning use case I think is SSHing into something. There's no way to tell if you got out. This perhaps has limited exploitability, but still should not be a thing, and is easily solved with a real UI instead of terminal hacks. Sudo is usually only used to run stuff as root - under the pretense that requiring this will somehow stop malware from getting root - which itself is a misconception (which indeed capability based systems avoid).
>You might want to remove your complaints about downvotes and boasts of rationality so people don't downvote you for them.
Nah it's funny.
- kragen 4y agoI don't think there are several more ways to exploit terminals, although there are certainly several more ways to exploit terminal emulators. Maybe your definition of "exploit" is broader than mine, though. > I discovered wall and write at some point and was amazed how stupid that was. write(1) strips escape characters out, and wall(1) represents them as ^[; they protect your terminal against this particular vulnerability since last millennium. wall also escapes bytes above 126, which would be a pain if you weren't speaking English, and write seems to strip at least byte 0x9b, although I don't know if I have a terminal handy that responds to 0x9b. > The most common concerning use case I think is SSHing into something. There's no way to tell if you got out. The easiest way to be sure you got out is to close the terminal emulator, but an alternative is just closing ssh, using ^M~. It's possible to flub that by, say, accidentally typing ^M`. or ^M~,. I agree that better UI would help. A different problem with ssh is that it leaks your keystroke timing to passive listeners who don't have the session key. This isn't a concern for using ssh with password authentication but it is a concern if you're running sudo or gpg on the server you sshed into. I agree that unrestricted sudo isn't an effective defense against malware, just against accidentally hosing your system.