[arch-general] A good time to switch to dash as /bin/sh?

[Benjamin A. Shelton]

On 09/26/2014 10:59 AM, Doug Newgard wrote:
 >
 > OK, we're finally getting some examples of where the sh symlink could 
be used to trigger this exploit. Thank you.

There are samples that have been available for the past 2-3 days, and 
there's a fairly steady stream of new information on various sites (HN, 
probably Slashdot, among others). It isn't difficult to find, if you're 
willing to look, but you do have to sort through the cruft and the "sky 
is falling" paranoia.

 > @Benjamin A. Shelton: What do you mean you'd support it for 
correctness? Bash is POSIX compliant, anything that uses only POSIX sh 
should run correctly on Bash. If it doens't, it should be reported 
upstream.

I should specify that by correctness (in this case), I mean to say 
POSIX-compliant *minus* the bashisms and rather "interesting" behavior 
of the bash interpreter, in the sense that I can take a script written 
for /bin/sh and plop it down on any system that expects /bin/sh, and it 
doesn't perform (or provide) any additional magic. "Simpler" might also 
be an appropriate synonym. bash has some very convenient behaviors, but 
I'm not *completely* convinced that the additional features of a user 
shell should necessarily be exposed to applications that expect /bin/sh 
to behave consistently across Unix/Unix-like OSes (e.g. Apache's APR and 
others) while providing a rather creative interpretation of envvars. 
bash is big.

I submit that the bug in question is *exactly* the sort of behavior in 
question and has, in fact, already been sent upstream (that's what these 
bug reports are for, correct?). I may be mistaken, but I don't believe 
interpreting a special string of characters in envvars as 
functions--even when invoked as /bin/sh--is considered POSIX behavior? 
Does POSIX even address this? I don't see anything that specifies such, 
and I'm inclined to believe it is bash specific [1] (please point out if 
I'm mistaken).

 > Now my question for everyone else is, what will people do *WHEN* a 
bug is found in dash? Bash is the most tested shell code base we have, 
and I don't buy into the fallacy that a smaller code base is inherently 
more secure. Or are you simply relying on security through obscurity?

I believe this "shellshock" vulnerability was discovered by a Red Hat 
auditor and has been exploitable for about one major version back. "Most 
tested" doesn't always mean "more secure." Also, dash is at least as old 
as bash [2].

Smaller code bases do in fact have the potential to be more secure 
simply by fault of their relative magnitude: Less code makes it more 
readily auditable in less time, and less code (all other things being 
equal) with fewer features will exhibit fewer bugs. It's a matter of 
probability. It's not an absolute, of course: Some software may be 
written by more skilled individuals, but as a code base grows to include 
more features, the probability that it will contain errors in its 
implementation approaches one.

Similarly, I don't see how switching /bin/sh is security through 
obscurity; if someone were advocating replacing /bin/sh with (t)csh then 
yes, I might agree with that assertion, but replacing it with another sh 
implementation is not. There are only so many sh-compatible 
implementations available (and only so many licensed in a manner that 
GPL-licensed projects find palatable), so the limited selection most 
certainly is not compatible with such a charge.

What technical reasons are there against switching out /bin/sh? Thusfar, 
I haven't encountered anything particularly noisome (the ST2's subl 
launch script being one exception, probably several others), but there's 
certainly something lurking in unseen dark corners. It seems 
(superficially, at least) that most everything else is well behaved and 
asks specifically for /bin/bash where expected. Should those 
circumstances where this isn't the case be considered bugs? I would say 
"yes," but others might emphatically say "no."

Benjamin

[1] http://pubs.opengroup.org/onlinepubs/009604599/basedefs/xbd_chap08.html
[2] http://en.wikipedia.org/wiki/Almquist_shell