2 ms·

One thing that'd be somewhat useful, with respect to #2 ("It must invoke bash"), is to separate it into those which specifically invoke bash, versus those that

One thing that'd be somewhat useful, with respect to #2 ("It must invoke bash"), is to separate it into those which specifically invoke bash, versus those that invoke /bin/sh. If bash is not installed as /bin/sh, as is the case on Debian and Ubuntu, do any of these (inetd, exim, etc.) still explicitly call it? Put differently, is this mainly an issue for distributions that ship bash as /bin/sh? Or do users of distributions like Debian also need to worry about common system services setting bash shell variables? Maybe I'll try to answer that by pulling a bunch of Debian source packages and grepping for explicit calls to bash...

lambda 12y ago
The one major one I found was the DHCP vulnerability; if you use ifupdown and configure and interface via DHCP, that uses dhclient, which invokes dhclient-script with attacker controlled variables. dhclient-script is explicitly written in bash, so is vulnerable. I've tried doing explicit grepping for bash throughout various source code, but it's a lot of work to then trace back if that particular script is ever executed by some chain of commands that ultimately originated from something networked which sets environment variables to attacker controlled values.
pja 12y ago
Even if they don't explicitly invoke bash, it's possible that they call a program which calls a program which invokes a bash script somewhere. Debian switched /bin/sh to link to dash a while back, but some maintainers decided to simply change the #!/bin/sh at the top of the shell scripts in their packages to #!/bin/bash rather than remove the bashisms. dhclient is the worst offender in the current kerfuffle, but I'm sure there are others.
- tokenizerrr 12y ago
  They did switch /bin/sh to dash, which is why it seems to me that grepping for "bash" would be quite effective.

2 ms·

One thing that'd be somewhat useful, with respect to #2 ("It must invoke bash"), is to separate it into those which specifically invoke bash, versus those that

by _delirium 12y ago

lambda 12y ago
The one major one I found was the DHCP vulnerability; if you use ifupdown and configure and interface via DHCP, that uses dhclient, which invokes dhclient-script with attacker controlled variables. dhclient-script is explicitly written in bash, so is vulnerable. I've tried doing explicit grepping for bash throughout various source code, but it's a lot of work to then trace back if that particular script is ever executed by some chain of commands that ultimately originated from something networked which sets environment variables to attacker controlled values.
pja 12y ago
Even if they don't explicitly invoke bash, it's possible that they call a program which calls a program which invokes a bash script somewhere. Debian switched /bin/sh to link to dash a while back, but some maintainers decided to simply change the #!/bin/sh at the top of the shell scripts in their packages to #!/bin/bash rather than remove the bashisms. dhclient is the worst offender in the current kerfuffle, but I'm sure there are others.
- tokenizerrr 12y ago
  They did switch /bin/sh to dash, which is why it seems to me that grepping for "bash" would be quite effective.