4 ms·

The top reply to that comment rightfully points out that this applies to your shell specifically. This isn't a concern for formats that don't have executable co

The top reply to that comment rightfully points out that this applies to your shell specifically. This isn't a concern for formats that don't have executable code (and I assume roff doesn't, right?) You might say, yes, but it's still a good idea to review the file before you open it. OK sure, but that isn't going to work for binary files anyway, so "Friends don't let friends pipe streams into commands" should not be the general rule. "Friends don't let friends pipe streams into shells" is certainly a good enough general rule.

scorpicam 3y ago
You execute arbitrary commands with troff. I used this feature a lot for getting output from code samples, but it's definitely a security issue if you don't trust the source. Or, if you think shelling out is too boring, the troff macro language is actually turing complete and is a disturbingly usable for scripting.
- rezonant 3y ago
  Oof, I kind of suspected this might be the case.
- jwilk 3y ago
  > You execute arbitrary commands with troff. This should be disabled by default since groff v1.17 (released in 2001): https://git.savannah.gnu.org/cgit/groff.git/commit/?id=7b3f578e9296c528 https://git.savannah.gnu.org/cgit/groff.git/commit/?id=7b3f5...
  - cyberpunk 3y ago
    I'm not convinced there's not some clever way to get roff to make $PAGER run commands; echo <esc>:!cat /etc/passwd etc
godelski 3y ago
1. Regardless, it is bad practice. It isn't a good idea to teach people to pipe downloaded content into any command. Regardless of how naive and safe the command seems. You may not know. Especially considering how you aren't guaranteed to run the full contents and may even run partial lines. Just don't get in the habit of streaming anything into a command. Because you'll be more tempted to stream into a different one which might have issues. Running two commands (or &&) just isn't a big deal. Low cost for high reward. 2. The person replying to me mentioned ffmpeg and well... see the reply to them. Parsers may not seem like a big deal, but see this about `cat`[0] or this about `less`[1] (a quick search shows a lot of pipe and pager type of vulnerabilities, including privilege escalation). Programs that look simple and a non-risk are probably actually prime targets for hackers because it can lull someone into a false sense of security. 3. You can detect bash piping server side. There's been a bunch of HN and reddit posts, several have been shared already so I won't repeat. I'm sticking to: Friends don't let friends pipe streams into commands It's just safer. Risk is pretty low, but does using `&&` or a `;` instead really create a lot more work? How about curl -sL -H "Accept: text/roff" https://jamesg.blog/2024/02/28/programming-projects/ > post.page && man ./post.page && rm post.page This at least guarantees you don't get a truncated execution.You'll delete the file after you close man. This at least guarantees you don't get a truncated execution. Better if we send to /tmp/post.page and not delete, in case something is fuzzy. Both of these also prevent server side detection and possible tomfoolery. /tmp will be cleared on reboot anyways and it's better to have the file in case something DOES happen. curl -sL -H "Accept: text/roff" https://jamesg.blog/2024/02/28/programming-projects/ > /tmp/post.page && man /tmp/post.page [0] https://security.stackexchange.com/questions/56307/can-cat-ing-a-file-be-a-potential-security-risk https://security.stackexchange.com/questions/56307/can-cat-i... [1] https://ubuntu.com/security/notices/USN-6664-1 https://ubuntu.com/security/notices/USN-6664-1 Edit: groff vulns: https://www.cvedetails.com/vulnerability-list/vendor_id-72/product_id-1066/GNU-Groff.html?page=1&order=3&trc=10&sha=6e4cc7f500802f814752fc1a27a3314fdc0dd07b https://www.cvedetails.com/vulnerability-list/vendor_id-72/p...
- deleted 3y ago
  [deleted]
- Crestwave 3y ago
  > curl -sL -H "Accept: text/roff" https://jamesg.blog/2024/02/28/programming-projects/ https://jamesg.blog/2024/02/28/programming-projects/ > post.page && man ./post.page && rm post.page What if I have a post.page in my current directory? > curl -sL -H "Accept: text/roff" https://jamesg.blog/2024/02/28/programming-projects/ https://jamesg.blog/2024/02/28/programming-projects/ > /tmp/post.page && man /tmp/post.page What if another user runs the command at the same time, then? Or what if a malicious user creates a 666 mode /tmp/post.page file beforehand, detects when you finish writing to it, then attaches a payload right before `man` reads it? Unfortunately, there is no perfect solution for this problem; I run arbitrary html, css, and javascript every day by browsing the web. It's debatable whether switching to command chains instead of piping results in overall benefits. Of course, the same goes for vice versa as well.
  - godelski 3y ago
    Sure, but aren't you being pedantic at this point? If you're that concerned, add a small random number. But of course there's no perfect solution. But we still are mitigating the main concerns.

scorpicam 3y ago

You execute arbitrary commands with troff. I used this feature a lot for getting output from code samples, but it's definitely a security issue if you don't trust the source. Or, if you think shelling out is too boring, the troff macro language is actually turing complete and is a disturbingly usable for scripting.

rezonant 3y ago
Oof, I kind of suspected this might be the case.
jwilk 3y ago
> You execute arbitrary commands with troff. This should be disabled by default since groff v1.17 (released in 2001): https://git.savannah.gnu.org/cgit/groff.git/commit/?id=7b3f578e9296c528 https://git.savannah.gnu.org/cgit/groff.git/commit/?id=7b3f5...
- cyberpunk 3y ago
  I'm not convinced there's not some clever way to get roff to make $PAGER run commands; echo <esc>:!cat /etc/passwd etc

godelski 3y ago

1. Regardless, it is bad practice. It isn't a good idea to teach people to pipe downloaded content into any command. Regardless of how naive and safe the command seems. You may not know. Especially considering how you aren't guaranteed to run the full contents and may even run partial lines. Just don't get in the habit of streaming anything into a command. Because you'll be more tempted to stream into a different one which might have issues. Running two commands (or &&) just isn't a big deal. Low cost for high reward. 2. The person replying to me mentioned ffmpeg and well... see the reply to them. Parsers may not seem like a big deal, but see this about `cat`[0] or this about `less`[1] (a quick search shows a lot of pipe and pager type of vulnerabilities, including privilege escalation). Programs that look simple and a non-risk are probably actually prime targets for hackers because it can lull someone into a false sense of security. 3. You can detect bash piping server side. There's been a bunch of HN and reddit posts, several have been shared already so I won't repeat. I'm sticking to: Friends don't let friends pipe streams into commands It's just safer. Risk is pretty low, but does using `&&` or a `;` instead really create a lot more work? How about curl -sL -H "Accept: text/roff" https://jamesg.blog/2024/02/28/programming-projects/ > post.page && man ./post.page && rm post.page This at least guarantees you don't get a truncated execution.You'll delete the file after you close man. This at least guarantees you don't get a truncated execution. Better if we send to /tmp/post.page and not delete, in case something is fuzzy. Both of these also prevent server side detection and possible tomfoolery. /tmp will be cleared on reboot anyways and it's better to have the file in case something DOES happen. curl -sL -H "Accept: text/roff" https://jamesg.blog/2024/02/28/programming-projects/ > /tmp/post.page && man /tmp/post.page [0] https://security.stackexchange.com/questions/56307/can-cat-ing-a-file-be-a-potential-security-risk https://security.stackexchange.com/questions/56307/can-cat-i... [1] https://ubuntu.com/security/notices/USN-6664-1 https://ubuntu.com/security/notices/USN-6664-1 Edit: groff vulns: https://www.cvedetails.com/vulnerability-list/vendor_id-72/product_id-1066/GNU-Groff.html?page=1&order=3&trc=10&sha=6e4cc7f500802f814752fc1a27a3314fdc0dd07b https://www.cvedetails.com/vulnerability-list/vendor_id-72/p...

deleted 3y ago
[deleted]
Crestwave 3y ago
> curl -sL -H "Accept: text/roff" https://jamesg.blog/2024/02/28/programming-projects/ https://jamesg.blog/2024/02/28/programming-projects/ > post.page && man ./post.page && rm post.page What if I have a post.page in my current directory? > curl -sL -H "Accept: text/roff" https://jamesg.blog/2024/02/28/programming-projects/ https://jamesg.blog/2024/02/28/programming-projects/ > /tmp/post.page && man /tmp/post.page What if another user runs the command at the same time, then? Or what if a malicious user creates a 666 mode /tmp/post.page file beforehand, detects when you finish writing to it, then attaches a payload right before `man` reads it? Unfortunately, there is no perfect solution for this problem; I run arbitrary html, css, and javascript every day by browsing the web. It's debatable whether switching to command chains instead of piping results in overall benefits. Of course, the same goes for vice versa as well.
- godelski 3y ago
  Sure, but aren't you being pedantic at this point? If you're that concerned, add a small random number. But of course there's no perfect solution. But we still are mitigating the main concerns.