5 ms·

> If you want to compare MGR to the X Window System, you might consider the MGR server as something like a combination of an X server + window manager + xterm

> If you want to compare MGR to the X Window System, you might consider the MGR server as something like a combination of an X server + window manager + xterm Sounds like a nightmare of in band signalling vulnerabilities. Edit: your downvote is invalid. you literally just did it because i wrote something negative about the topic of the thread. it's still true and a good point. this is similar to how youtube downvotes worked. i still upvoted the article because it was useful to me. i am rational you are not.

kragen 4y ago
I always wondered about this, but I never dug into MGR enough to find out if they defended against it. Maybe the multiplexers rmgr and mtx were perfectly secure, and restricted the programs they ran to only manipulating their own window (which X11 doesn't succeed at, or even attempt), but it seems like some kinds of compositions of programs might not play well with this. Also there were plenty of terminals that had escape-sequence vulnerabilities of the flavor "sending escape sequence X to the terminal will cause it to (immediately or later) send character sequence Y back to the host [which the host will interpret as a command]", like cross-site scripting. As I understand it, this kind of send-escape-sequence-X-to-bind-an-event-to-character-sequence-Y is exactly how MGR worked, and I wonder if it also had this vulnerability. This is usually, but not always, a matter of running one program after another; for example, write(1) (and I think wall(8) if enabled) would allow you to send arbitrary escape sequences to anybody's terminal at any time. Trusted path issues also seem like they could be a problem, though it's kind of a problem with Unix shells in terminals in general: when you hit ^Z to suspend a process and it drops you back to your shell, how do you know that it really suspended and that what you're typing to is really your shell? This could matter if you use "sudo". (It doesn't matter that much because by virtue of running the program in the first place you are giving all your authority to that program, unlike in capability-based systems.) You might want to remove your complaints about downvotes and boasts of rationality so people don't downvote you for them.
- pabs3 4y ago
  X had various security extensions like XACE to restrict what clients can do. https://www.x.org/archive/X11R7.5/doc/security/XACE-Spec.html https://www.x.org/archive/X11R7.5/doc/security/XACE-Spec.htm...
- 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 ago
    I 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.
Bancakes 4y ago
>Edit: your downvote is invalid. you literally just did it because i wrote something negative about the topic of the thread. it's still true and a good point. this is similar to how youtube downvotes worked. i still upvoted the article because it was useful to me. i am rational you are not. Oh grow up. Your edit is longer than the post.
- unixbane 4y ago
  It was a blog post, which I will link to pretty much every time someone downvotes me from now on, as it's a pattern I've noticed here.
  - Bancakes 4y ago
    Yes and I'm calling that neurotic, illogical behavior. If someone down votes you, they don't care what you have to say. So posting that edit will get you more downvotes.
    - unixbane 4y ago

kragen 4y ago

I always wondered about this, but I never dug into MGR enough to find out if they defended against it. Maybe the multiplexers rmgr and mtx were perfectly secure, and restricted the programs they ran to only manipulating their own window (which X11 doesn't succeed at, or even attempt), but it seems like some kinds of compositions of programs might not play well with this. Also there were plenty of terminals that had escape-sequence vulnerabilities of the flavor "sending escape sequence X to the terminal will cause it to (immediately or later) send character sequence Y back to the host [which the host will interpret as a command]", like cross-site scripting. As I understand it, this kind of send-escape-sequence-X-to-bind-an-event-to-character-sequence-Y is exactly how MGR worked, and I wonder if it also had this vulnerability. This is usually, but not always, a matter of running one program after another; for example, write(1) (and I think wall(8) if enabled) would allow you to send arbitrary escape sequences to anybody's terminal at any time. Trusted path issues also seem like they could be a problem, though it's kind of a problem with Unix shells in terminals in general: when you hit ^Z to suspend a process and it drops you back to your shell, how do you know that it really suspended and that what you're typing to is really your shell? This could matter if you use "sudo". (It doesn't matter that much because by virtue of running the program in the first place you are giving all your authority to that program, unlike in capability-based systems.) You might want to remove your complaints about downvotes and boasts of rationality so people don't downvote you for them.

pabs3 4y ago
X had various security extensions like XACE to restrict what clients can do. https://www.x.org/archive/X11R7.5/doc/security/XACE-Spec.html https://www.x.org/archive/X11R7.5/doc/security/XACE-Spec.htm...
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 ago
  I 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.

Bancakes 4y ago

>Edit: your downvote is invalid. you literally just did it because i wrote something negative about the topic of the thread. it's still true and a good point. this is similar to how youtube downvotes worked. i still upvoted the article because it was useful to me. i am rational you are not. Oh grow up. Your edit is longer than the post.

unixbane 4y ago
It was a blog post, which I will link to pretty much every time someone downvotes me from now on, as it's a pattern I've noticed here.
- Bancakes 4y ago
  Yes and I'm calling that neurotic, illogical behavior. If someone down votes you, they don't care what you have to say. So posting that edit will get you more downvotes.
  - unixbane 4y ago