4 ms·

would someone really run that randomly? couldnt it run a rm command?

LinuxBender 5y ago
Good question. If one piped that to `bash` or `sh` then that would certainly be a possibility. This is why I avoid curl piped to bash and instead curl to an output file, review it and then execute it. If one was unsure of the behavior of base64 they could redirect the output to a file as well. echo `something` | base64 -d > ./some.file.txt
- omegalulw 5y ago
  This is just saying "do not run untrusted code" with extra steps. If you don't trust the source the code came from you should not executed any line.
  - LinuxBender 5y ago
    I disagree about the extra steps as it pertains to the original post. The redirection of base64's output to a file is addressing the concern that the output from the program would trick the terminal into executing code. What you are describing is the risk of sending a small string of ascii into base64 would cause a buffer overflow and trick a text decoding binary into executing code. This is of course a risk with parsing data especially if it were binary. If we really wanted to go deep down a rabbit hole of theoretical risk then I would concede that if you did not force your character set of your terminal to something that could not possibly interpret extended character codes then there is a risk albeit highly unlikely that there could be hidden strings you are copy/pasting. This could occur with any executable and pasting of data to which I would partially mitigate by forcing my terminal to have a LANG/LC_ALL of C unless I specify otherwise and would probably even take care to be explicit with IFS. This is a deep rabbit hole and I would be surprised if a majority of people copy/pasting from sites like stackoverflow / stackexchange took these precautions. Further mitigations could include executing code as a AppArmor/SELinux confined user or pasting the code into a sandboxed environment. There are infinite rabbit holes we could go into here and would be happy to cover some of them. More likely when copy and pasting text especially if from a web page would be that the site is malicious and using CSS or javascript to trick your system into copying entirely different contents into your copy/paste buffer. [1] This would also benefit from running in a highly sandboxed environment. [1] - https://thejh.net/misc/website-terminal-copy-paste https://thejh.net/misc/website-terminal-copy-paste
    - omegalulw 5y ago
      Fair enough, and you seem to know more about character encoding than I do so I won't argue lol. I'm standing on a glass house anyway as I use password less sudo haha.
vgel 5y ago
no. it's not executing any user-supplied data as code; the only commands running are echo and base64: $ echo 'cm0gLXJmIC8K' | base64 -d rm -rf / $ # was echoed, but not run

Good question. If one piped that to `bash` or `sh` then that would certainly be a possibility. This is why I avoid curl piped to bash and instead curl to an output file, review it and then execute it. If one was unsure of the behavior of base64 they could redirect the output to a file as well. echo `something` | base64 -d > ./some.file.txt

omegalulw 5y ago
This is just saying "do not run untrusted code" with extra steps. If you don't trust the source the code came from you should not executed any line.
- LinuxBender 5y ago
  I disagree about the extra steps as it pertains to the original post. The redirection of base64's output to a file is addressing the concern that the output from the program would trick the terminal into executing code. What you are describing is the risk of sending a small string of ascii into base64 would cause a buffer overflow and trick a text decoding binary into executing code. This is of course a risk with parsing data especially if it were binary. If we really wanted to go deep down a rabbit hole of theoretical risk then I would concede that if you did not force your character set of your terminal to something that could not possibly interpret extended character codes then there is a risk albeit highly unlikely that there could be hidden strings you are copy/pasting. This could occur with any executable and pasting of data to which I would partially mitigate by forcing my terminal to have a LANG/LC_ALL of C unless I specify otherwise and would probably even take care to be explicit with IFS. This is a deep rabbit hole and I would be surprised if a majority of people copy/pasting from sites like stackoverflow / stackexchange took these precautions. Further mitigations could include executing code as a AppArmor/SELinux confined user or pasting the code into a sandboxed environment. There are infinite rabbit holes we could go into here and would be happy to cover some of them. More likely when copy and pasting text especially if from a web page would be that the site is malicious and using CSS or javascript to trick your system into copying entirely different contents into your copy/paste buffer. [1] This would also benefit from running in a highly sandboxed environment. [1] - https://thejh.net/misc/website-terminal-copy-paste https://thejh.net/misc/website-terminal-copy-paste
  - omegalulw 5y ago
    Fair enough, and you seem to know more about character encoding than I do so I won't argue lol. I'm standing on a glass house anyway as I use password less sudo haha.

vgel 5y ago

no. it's not executing any user-supplied data as code; the only commands running are echo and base64: $ echo 'cm0gLXJmIC8K' | base64 -d rm -rf / $ # was echoed, but not run