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, assuming it works as advertised, when dealing with potentially malicious input or paranoia.

Rails has ActiveSupport::SafeBuffer for doing XSS protection, but ruby doesn't track external strings as dirty like that.

> but ruby doesn't track external strings as dirty like that.

Yes, it does. E.g:

    x = STDIN.gets
    puts x.tainted?
    y = "hello "+x
    puts y.tainted?
    z = "foo"
    puts z.tainted?

The two first will return "true", and the last will print "false". If you set the safe-level appropriately some methods will be disallowed for x and y above (e.g. eval()), though I would not trust that as comprehensive, but it's a lot better than nothing.

> but ruby doesn't track external strings as dirty like that.

It does:

  irb(main):001:0> gets.tainted?
  foo
  => true

You can even set $SAFE to 1 or higher to disallow the use of tainted strings in potentially dangerous commands:

  freya:~ flgr$ ruby -e '$SAFE = 1; system "tar bla bla #{gets}"'
  foo
  -e:1:in `system': Insecure operation: -r (SecurityError)
	  from -e:1:in `<main>'

See http://phrogz.net/programmingruby/taint.html for more information.

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.

With the GNU tools you can generally use the `--` option to signal that no more options. That combined with quotes is usually enough:

    tar c -- "$directory_to_tar"

What I wish, I wish there was a flag in unicode to declare characters as 'unsafe user input' so that system utilizes and databases can recognize unsafe user input and barf on it.

It would be a very rare case where a vulnerability related to in-band signalling can be fixed with more in-band signalling.

You can if your encoding is explicit about what's in band and out of band. I get the feeling you've never written a protocol ever.

I don't think you even understand the concept of in-band and out-of-band, that's not a function of the encoding. And I've written protocols aplenty in the days when not everything ran on top of HTTP, high speed serial links, with and without virtual circuits (so mux-demux) and a whole slew of others.

Just to make sure you are on the same page as the rest of us here: in-band and out-of-band is a way to distinguish sending meta information about the data stream through the same channel as the original data. You need an escape mechanism for that, so control characters and such.

Out-of-band signalling indicates that all meta information about the data stream travels through a different (virtual) circuit, in which case there can never be confusion about whether a given chunk is data or meta info.

I now understand that your point here is to be insulting.

Not every command gets run through the shell, and not using the shell was one of the prerequisites in the article.

This is a point that should have been made in the author's article. As it is, it presents a poorly defined problem without offering solutions (other than "be afraid").

I think he wants to bring to peoples attention that if you give someone sudo rights for a specific program chances are that they will be able to elevate their privilegies.

There's been a bit of attention recently on these things. The big issue is people using " * " on the command line without prefixing with an "--" argument or simply "./*". If someone has managed to sneak in particularly evil filenames (that look like -options), then the unsuspecting user may be in for a surprise, for example tar'ing up a public upload directory.

I've seen a lot of novice sysadmins do silly things like rely on sudo's command restrictions, expecting this to actually contain a user.

For those sysadmins, yeah, it's unexpected.

All security is a matter of degree, be it computing or physical.

the most determined of attackers will always find a way in.

I agree. Every single example in this article makes perfect sense to me.

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.

How so? I might be missing something but as far as I can tell it's just executing the runme.sh as the user who ran the bash command. It would be virtually identical to ./runme.sh

This way around is perfectly obvious. But assume that you are writing a website that prints a man page, for example by piping the output of man $URLPARAMETER to the user. In that case it is only obvious to check if man can execute arbitrary commands if you already know that man is not just a cat for man pages.

It isn't much different from something like

    echo `somescript.sh`