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

[Savya]

On Sat, Sep 27, 2014, at 01:30 AM, Benjamin A. Shelton wrote:
> 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

I guess the bug report I opened has a pretty damning reason:

https://bugs.archlinux.org/task/42134#comment128011

Given by Dave with a source, so... If there's a reason it doesn't
matter, be a dear and comment on the bug, will you?

-- 
Cheers!
Savya