5 ms·

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, ev

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}

krylon 11y ago
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.
- JonnieCache 11y ago
  Rails has ActiveSupport::SafeBuffer for doing XSS protection, but ruby doesn't track external strings as dirty like that.
  - flgr 11y ago
    > 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 http://phrogz.net/programmingruby/taint.html for more information.
  - vidarh 11y ago
    > 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.
andrey-p 11y ago
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.
- andrewaylett 11y ago
  Not every command gets run through the shell, and not using the shell was one of the prerequisites in the article.
- ninkendo 11y ago
  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.
  - Gibbon1 11y ago
    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.
    - jacquesm 11y ago
      It would be a very rare case where a vulnerability related to in-band signalling can be fixed with more in-band signalling.
      - Gibbon1 11y ago
        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.
        11y ago
enno 11y ago
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").

krylon 11y ago

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.

JonnieCache 11y ago
Rails has ActiveSupport::SafeBuffer for doing XSS protection, but ruby doesn't track external strings as dirty like that.
- flgr 11y ago
  > 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 http://phrogz.net/programmingruby/taint.html for more information.
- vidarh 11y ago
  > 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.

andrey-p 11y ago

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.

andrewaylett 11y ago
Not every command gets run through the shell, and not using the shell was one of the prerequisites in the article.
ninkendo 11y ago
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.
- Gibbon1 11y ago
  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.
  - jacquesm 11y ago
    It would be a very rare case where a vulnerability related to in-band signalling can be fixed with more in-band signalling.
    - Gibbon1 11y ago
      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.
      - 11y ago

enno 11y ago

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").