4 ms·
You say dhclient should take into account all possible contexts before passing data to bash, but it's not easy to know what data shells will parse as code and w
by anon1385 12y ago
You say dhclient should take into account all possible contexts before passing data to bash, but it's not easy to know what data shells will parse as code and what they won't[1]. If we have to sanitise data before passing it to shells then the only sane conclusion is to never pass untrusted data to shell scripts. I certainly don't trust myself to know the full range of features in all shells that might suddenly turn a plain text string into executed code. I can't think of any other people that I would trust to know that either.
Is that really what you are advocating here? Don't ever use shell scripts with untrusted data? That has been my philosophy for a long time, but up till now that position has been viewed as extreme by most people I've shared it with.
[1] there are still exploitable bash parser issues to be revealed http://seclists.org/oss-sec/2014/q3/777 http://seclists.org/oss-sec/2014/q3/777
- nitrogen 12y agoUnfortunately the specs for system() and popen() require the use of shells. It was known that you had to escape arguments and control the names of environment variables, but it's entirely bizarre to expect people to know before shellshock that the values of otherwise completely safe and sanitized variables might still be interpreted by bash as code. We shouldn't have to give up popen() just because bash was designed insecurely; we should fix or replace bash.