Oh for explicity typed IO. (Sadly command-line programs have yet to pass the threshold of even having a types system at all.)
Or, you know, a proper capability-based security model.
No one expects command execution
31–40 of 88 posts
Re: No one expects command execution
#32Earlier quoted context omitted.
> UNIX got battle-hardened during its college years Is that when it finally gave up making shar archives? For the unitiated: A shar is a "shell archive", or a shell script which (typically) makes heavy use of 'here documents' to do what tarballs do, only they're shell scripts so you have to execute them and then they can potentially execute arbitrary code unless you read through them very closely and actually underst…
I don't really understand how a shar is more dangerous than the still-incredibly-common "./configure; make".
You really don't need the "./configure" there. make alone can obviously run arbitrary commands - but then again, so can the program whose source code you probably downloaded in order to run it.
In general, all the hype about not executing stuff from the web has a point but is largely confused about where the risks are and aren't (e.g. the "don't pipe wget into the shell" meme).
Re: No one expects command execution
#33What I find interesting is the thread title being a pun from a 40 year old movie. Back in the 70s, there wasn't any interest in movies, music, etc. from the 30s. And there still isn't interest in 30s culture, but plenty in the 70s. I wonder why.
I think you're in a bubble. Lots of people have interest in the 30s given it was the golden age of Hollywood: Gone with the Wind references have entered the cultural lexicon, so have The Wizard of Oz references.
Re: No one expects command execution
#34I don't get it, it's not really unexpected if you pass the name of the executable (which just happens to be a script) via a flag... used explicitly for passing an executable to run. I mean, is it unexpected if `./my_command --execute-this-right-now=somescript.sh` executes somescript.sh?
I guess the author's point is don't ever, ever, ever mix shells and unsanitized user inputs, even if you think it can't possibly be harmful. In other words, even if it's not obvious, doing this creates a security vulnerability: tar bla bla ${user input}
But if you're plugging in input like that, couldn't the malicious user just pass in something like
&& sudo rm -rf /
Re: No one expects command execution
#35Earlier quoted context omitted.
I guess the author's point is don't ever, ever, ever mix shells and unsanitized user inputs, even if you think it can't possibly be harmful. In other words, even if it's not obvious, doing this creates a security vulnerability: tar bla bla ${user input}
But if you're plugging in input like that, couldn't the malicious user just pass in something like && sudo rm -rf / anyway? Which would render the whole point of the article moot.
Not every command gets run through the shell, and not using the shell was one of the prerequisites in the article.
Re: No one expects command execution
#36Oh for explicity typed IO. (Sadly command-line programs have yet to pass the threshold of even having a types system at all.)
Powershell!
Seriously, MS doesn't do everything great, but Powershell has typed pipes (typed everything, actually, it's not just stringly like *sh) which are seriously awesome.
Re: No one expects command execution
#37Earlier quoted context omitted.
I guess the author's point is don't ever, ever, ever mix shells and unsanitized user inputs, even if you think it can't possibly be harmful. In other words, even if it's not obvious, doing this creates a security vulnerability: tar bla bla ${user input}
But if you're plugging in input like that, couldn't the malicious user just pass in something like && sudo rm -rf / anyway? Which would render the whole point of the article moot.
There's simple ways to "escape" user input (as in, ensure the whole input string is interpreted as a single argument to this program) in ways that ensure you can't do simple &&'s or ;'s and execute a totally different command. But the point of the article is even if it's properly escaped, users can still do malicious things when input is passed to lots of standard UNIX utilities.
Re: No one expects command execution
#38And yet another interesting GNU tar "feature", also noteworthy is remote tar: https://www.gnu.org/software/tar/manual/html_section/tar_46.... > "If the archive file name includes a colon (`:'), then it is assumed to be a file on another machine. If the archive file is `user@host:file', then file is used on the host host. The remote host is accessed using [rsh]." and > "If you need to use a file whose name includes a…
Wow... I'm starting to get really scared of the shell, and how much hidden complexity there is waiting to trap the unwary. Feels like best practice for shellscripts is to only ever use them for one-offs. And that tar and friends should never be used as "helpers" by other programs.
Re: No one expects command execution
#39This might be related to another article about OLE execution, to cast a shadow of doubt that it is not an isolated habit. Having outside stuff executed when not meaning to is always bad. I for one would be badly disappointed, if tar xvf unexpectedly run some code. Luckily, that is not the case. UNIX got battle-hardened during its college years, the cases of unexpected execution are few and far between. One of them is…
> UNIX got battle-hardened during its college years Is that when it finally gave up making shar archives? For the unitiated: A shar is a "shell archive", or a shell script which (typically) makes heavy use of 'here documents' to do what tarballs do, only they're shell scripts so you have to execute them and then they can potentially execute arbitrary code unless you read through them very closely and actually underst…
Yes, that is one of the things that turned out to be a bad idea. That's why it was dropped.
Look, it's all about trust management. If you trust everyone's good will, like in an academic community, it's fine. If not, you need to manage trust. There are three models for it AFAIK: initial trust, as in SSH; trust to the authorities, as in X.509; and the web of trust, as in PGP/GPG.
They all have their use cases. I like the opportunity to choose.
Re: No one expects command execution
#40And yet another interesting GNU tar "feature", also noteworthy is remote tar: https://www.gnu.org/software/tar/manual/html_section/tar_46.... > "If the archive file name includes a colon (`:'), then it is assumed to be a file on another machine. If the archive file is `user@host:file', then file is used on the host host. The remote host is accessed using [rsh]." and > "If you need to use a file whose name includes a…
Wow... I'm starting to get really scared of the shell, and how much hidden complexity there is waiting to trap the unwary. Feels like best practice for shellscripts is to only ever use them for one-offs. And that tar and friends should never be used as "helpers" by other programs.
Welcome to life.