I like so many others have been messing around with the shellshock issue now for a few days. Having seen some very creative ways of attempting to exploit this issue, I decided to look at a few things beyond the modcgi stuff, which you would typically find in appliance type servers, where sane developers don't use modcgi.

In my own testing of an unnamed appliance, I came across something rather interesting.

Consider the following using expect:

spawn scp -P $portnum -o NumberOfPasswordPrompts=1 $localfile $remotefile

This seems innocuous at first, given the nature of tcl and scp, after all we have some kind of credential here right?

Now consider that the source of $remotefile is from a web app, with a non privileged user, who doesn't actually have access to the password/keyfile on the target location.

You can see where this is going I'm sure, in attempting to exploit the source of $remote in this case, I found that using scp in that fashion, led to the exploit firing off on the target of the scp upload, via input from a unprivileged user, where I was able secure myself root login credentials via ssh without issue.

This kind of use of expect is most commonly used to handle remote storage of things like backups and the like in appliance type servers, that have some type of web interface. If you are unfamiliar with expect have a look. The nuts and bolts of it, is that it automates things that are normally interactive with tcl scripting.

This is just another example of just how bad this bug actually is, it creates holes that were otherwise not even there, and don't get me started on the shell command being passed on to the next server, which is not how that syntax should work at all with scp (who's bright idea was that, bug?).

Sanitize your inputs if you're developing web applications of any kind, I can't stress it enough...