This 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…
No one expects command execution
21–30 of 88 posts
Re: No one expects command execution
#22What 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.
Re: No one expects command execution
#23Earlier 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}
Perl has a special "taint" mode (Ruby does, too, I think, but I don't know about the differences or similarties), where any data coming from outside the program - environment variables, network connections, files, etc. - is considered "tainted", i.e. treated as bad , until you validate it using regular expressions (or something along those lines). I have to admit I never tried it, but it sounds like a good idea, assu…
Re: No one expects command execution
#24I 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?
Re: No one expects command execution
#25What 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.
Re: No one expects command execution
#26What 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.
a) 70s culture was a brief moment where geek culture was also pop culture, e.g. Monty Python. So geeks will forever adore that moment
b) mass culture underwent a big shift when TV emerged, so that people after TV cannot easily understand culture before TV
c) the disillusionment and paranoia of the 70s is especially relevant today
Re: No one expects command execution
#27This 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…
Re: No one expects command execution
#28https://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 colon, then the remote tape drive behavior can be inhibited by using the `--force-local' option."
On many systems, rsh is aliased to ssh, so if you don't properly sanitize your archive names, GNU tar will make network connections.
Re: No one expects command execution
#29What 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 don't know, Hawkeye Pierce did a pretty good impression of Groucho Marx.
I think it's down to numbers: There are a Hell of a lot more people born who know about the 1970s alive now compared to people who knew about the 1930s alive in the 1970s. It was a Baby Boom, after all.
Re: No one expects command execution
#30I 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?
Yes, it's unexpected and less commands should do that. Did you read the manpage of every utility on your computers to know that they won't execute a user supplied program? If you didn't you are up to nasty surprises. That $HOME trick alone would give privilege escalation to anybody that gets a user-level access to a server of mine. Gota change it.