11–20 of 88 posts
UNIX got battle-hardened during its college years, the cases of unexpected execution are few and far between. One of them is post-install, never run dpkg -i unless you trust the packager.
I 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?
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.
Command execution is overrated. How about having tar download an arbitrary tar file over the network, from a server you control? http://bugs.debian.org/290435
Are there any real examples of how this could be used to do something malicious?
They had an x86 box running RHEL as their firewall/router and I was hired to resolve an (IPSec) issue they were having. I asked for a capture of some specific traffic but their I.T. guys (small company w/ only two technical staff) weren't "fluent" with bpf filters, so they created a user account for me, provided me with access via SSH, and granted me the ability to run tcpdump via sudo.
From the example given, I could have used the "-z" flag to run arbitrary commands and escalate to root (although, in this case, I likely could have gained root simply by asking nicely).
I 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?
For those sysadmins, yeah, it's unexpected.
I 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?
(Sadly command-line programs have yet to pass the threshold of even having a types system at all.)
I wonder why.
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…
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 understand them.
Yes, people actually made these. Yes, people actually ran these. Yes, they still exist on some old archive FTP servers and so on.
It's amazing how clever you can be when you don't think you'll ever have to care about security or The Sufficiently Stupid User (because sufficiently advanced stupidity is indistinguishable from malice).
I 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}