5 ms·

I’m curious: how do people verify the security of such low-level pieces of infrastructure?

by pama 5y ago

Seirdy 5y ago
Imperfect, incomplete, yet useful measures I take including building with some of Clang's sanitizers and running the program through a bubblewrap wrapper for filesystem sandboxing paired with a seccomp filter that allows a limited list of safer syscalls (including some W^X enforcement).
- leetrout 5y ago
  Is there a blog or webpage that summarizes all of this in one place?
- vidarh 5y ago
  With the caveat this may be useful to guard against exploitation of bugs, not against a malicious terminal (which can e.g. quietly wait for a user to ssh or su and intercept the password, and then execute code on the background). Not to dissuade people from hardening them as I'm all for that. (I'm sure you're aware since you pointed out these measures are incomplete. Just spelling it out.)
  - Seirdy 5y ago
    bubblewrap and/or selinux can prevent the terminal from making network connections. but yeah, this is better for bugs.
    - vidarh 5y ago
      You can stop it doing all kinds, but if you do, then it's not usable as a general purpose terminal. That's the problem. A terminal needs to be able to spawn an unconstrained shell or other process linked to a pty that it controls the IO with. That ability can equally be used for malicious purposes. E.g. if the user can use the terminal to ssh anywhere, then the terminal itself can too. There certainly can be situations were a constrained terminal could be useful too, though
      - Seirdy 5y ago
        Not necessarily; it could simply connect to a tmux session.
        vidarh 5y ago
        In which case the terminal can use the tmux session to carry out its evil deeds. Keep in mind that the terminal app is what reads keyboard events and passes them on to what it runs, and the terminal app reads the output back from the attached application (or tmux session) to render them to the screen. It has full control to monitor what you do, and to inject additional commands (and hide the responses) to whatever you connect it to. Anything you can do in the terminal, the terminal can also do without your permission unless you do far more complicated filtering. EDIT: I think what might not be clear here is how a terminal operates. It'll differ by operating system and winding system, but on Linux what you have is this: X server ----[keyboard events]----------> terminal ------[pty w/keyboard events]----> [app/shell/tmux session] <---[rendering instructions]----/ <----[pty w/output]------------------/ The terminal is always a middleman, and can send whatever it wants to the app/shell/tmux session or whatever else you connect to it. It could "just" send your keypresses, or it can do macro expansions, or it could just randomly take over the endpoint on the other side. You could conceivably still lock this down, but it would involve writing something that either replicates the keyboard event pipeline of the terminal to verify that what is sent over the pty matches the inbound keyboard events, or applying heuristics to what is sent to block things that seems odd, so it's potentially possible to do "something" useful here. E.g. something that blocks and pops up a warning if the pty "keyboard events" suddently contains the string "curl" when that string hasn't been seen in the keyboard events from the X server for example could be useful, but bubblewrap certainly can't do anything like that. It'd be quite interesting to write a tool that wraps an app and allows you to script monitoring and/or munging of what goes over its sockets, though...
tadfisher 5y ago
The security of a terminal emulator? Did you post on the wrong article, perhaps?
- yjftsjthsd-h 5y ago
  Display something in terminal (curl, cat a download file, whatever will display untrusted content) -> control code (https://www.xfree86.org/4.8.0/ctlseqs.html https://www.xfree86.org/4.8.0/ctlseqs.html) / escape code (https://en.m.wikipedia.org/wiki/ANSI_escape_code https://en.m.wikipedia.org/wiki/ANSI_escape_code) -> bug (or worse, feature) -> arbitrary code execution
- reilly3000 5y ago
  I suppose a bad actor could log keystrokes or terminal output and phone home. I can't think of anything more ring 0 than one's terminal. If you're especially evil you could register a domain that looks like an apt repo url and drop your payload during updates, so anybody inspecting traffic would probably miss it.
  - tadfisher 5y ago
    I feel like the shell itself would be a much more lucrative target.
    - reilly3000 5y ago
      As in being able to execute arbitrary commands (silently)?
      - tadfisher 5y ago
        Yes, and it could "keylog" over remote connections as well.
        pama 5y ago
        Very few admins would switch from bash (possibly zsh), and bash has tons of eyes looking over its codebase. Terminals are interchangeable and could direct the shell in ways that can be invisible to the user.
deleted 5y ago
[deleted]
dec0dedab0de 5y ago
Wait until it has a following, and everyone knows who the developers are. Then if something is malicious, you atleast know who to blame. It's really the same as anything else.
- pama 5y ago
  It seems like an exploitable strategy, as long as people only know the developers online. The main problem with terminals compared to other infrastructure is that they often control pretty much everything and people become superusers in them.

I’m curious: how do people verify the security of such low-level pieces of infrastructure?

by pama 5y ago

I’m curious: how do people verify the security of such low-level pieces of infrastructure?

Imperfect, incomplete, yet useful measures I take including building with some of Clang's sanitizers and running the program through a bubblewrap wrapper for filesystem sandboxing paired with a seccomp filter that allows a limited list of safer syscalls (including some W^X enforcement).

leetrout 5y ago
Is there a blog or webpage that summarizes all of this in one place?
vidarh 5y ago
With the caveat this may be useful to guard against exploitation of bugs, not against a malicious terminal (which can e.g. quietly wait for a user to ssh or su and intercept the password, and then execute code on the background). Not to dissuade people from hardening them as I'm all for that. (I'm sure you're aware since you pointed out these measures are incomplete. Just spelling it out.)
- Seirdy 5y ago
  bubblewrap and/or selinux can prevent the terminal from making network connections. but yeah, this is better for bugs.
  - vidarh 5y ago
    You can stop it doing all kinds, but if you do, then it's not usable as a general purpose terminal. That's the problem. A terminal needs to be able to spawn an unconstrained shell or other process linked to a pty that it controls the IO with. That ability can equally be used for malicious purposes. E.g. if the user can use the terminal to ssh anywhere, then the terminal itself can too. There certainly can be situations were a constrained terminal could be useful too, though
    - Seirdy 5y ago
      Not necessarily; it could simply connect to a tmux session.
      - vidarh 5y ago
        In which case the terminal can use the tmux session to carry out its evil deeds. Keep in mind that the terminal app is what reads keyboard events and passes them on to what it runs, and the terminal app reads the output back from the attached application (or tmux session) to render them to the screen. It has full control to monitor what you do, and to inject additional commands (and hide the responses) to whatever you connect it to. Anything you can do in the terminal, the terminal can also do without your permission unless you do far more complicated filtering. EDIT: I think what might not be clear here is how a terminal operates. It'll differ by operating system and winding system, but on Linux what you have is this: X server ----[keyboard events]----------> terminal ------[pty w/keyboard events]----> [app/shell/tmux session] <---[rendering instructions]----/ <----[pty w/output]------------------/ The terminal is always a middleman, and can send whatever it wants to the app/shell/tmux session or whatever else you connect to it. It could "just" send your keypresses, or it can do macro expansions, or it could just randomly take over the endpoint on the other side. You could conceivably still lock this down, but it would involve writing something that either replicates the keyboard event pipeline of the terminal to verify that what is sent over the pty matches the inbound keyboard events, or applying heuristics to what is sent to block things that seems odd, so it's potentially possible to do "something" useful here. E.g. something that blocks and pops up a warning if the pty "keyboard events" suddently contains the string "curl" when that string hasn't been seen in the keyboard events from the X server for example could be useful, but bubblewrap certainly can't do anything like that. It'd be quite interesting to write a tool that wraps an app and allows you to script monitoring and/or munging of what goes over its sockets, though...

tadfisher 5y ago

The security of a terminal emulator? Did you post on the wrong article, perhaps?

yjftsjthsd-h 5y ago
Display something in terminal (curl, cat a download file, whatever will display untrusted content) -> control code (https://www.xfree86.org/4.8.0/ctlseqs.html https://www.xfree86.org/4.8.0/ctlseqs.html) / escape code (https://en.m.wikipedia.org/wiki/ANSI_escape_code https://en.m.wikipedia.org/wiki/ANSI_escape_code) -> bug (or worse, feature) -> arbitrary code execution
reilly3000 5y ago
I suppose a bad actor could log keystrokes or terminal output and phone home. I can't think of anything more ring 0 than one's terminal. If you're especially evil you could register a domain that looks like an apt repo url and drop your payload during updates, so anybody inspecting traffic would probably miss it.
- tadfisher 5y ago
  I feel like the shell itself would be a much more lucrative target.
  - reilly3000 5y ago
    As in being able to execute arbitrary commands (silently)?
    - tadfisher 5y ago
      Yes, and it could "keylog" over remote connections as well.
      - pama 5y ago
        Very few admins would switch from bash (possibly zsh), and bash has tons of eyes looking over its codebase. Terminals are interchangeable and could direct the shell in ways that can be invisible to the user.

deleted 5y ago

[deleted]

dec0dedab0de 5y ago

Wait until it has a following, and everyone knows who the developers are. Then if something is malicious, you atleast know who to blame. It's really the same as anything else.

pama 5y ago
It seems like an exploitable strategy, as long as people only know the developers online. The main problem with terminals compared to other infrastructure is that they often control pretty much everything and people become superusers in them.