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

[Doug Newgard]

On 2014-09-26 15:00, 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.

Yes, it's this paranoia that I've been trying to cut through in this 
thread to get people to start discussing things rationally.

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

POSIX generally says "it must do this", not "it can only do this and 
nothing more". As long as you can take any POSIX compliant sh script and 
run it on bash, it's compliant. You're wanting it to hide functionality 
in certain circumstances, which isn't wrong, but it isn't required. One 
way is not more correct than the other.

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

Smaller code bases can have the potential to be more secure, but that 
doesn't mean that they are. The shear amount of testing Bash gets run 
through being the default shell for so many things would suggest that 
it's likely more secure than a code base that doesn't get this testing.

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

Let's look at security through obscurity. When Apple started making 
their comeback, one of the big reasons non-technical people gave over 
and over for switching is that OSX didn't have any viruses. As it became 
more popular, guess what happened? Simply put, the smaller the install 
base, the less motivation there is to break it. Dash has a far smaller 
install/user base than Bash, so Bash is a much larger target.

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

My technical reason is simple, I don't think the base install should 
have to include another shell implementation when one is already 
available. If you want to switch /bin/sh on your machine, go for it. I 
just don't think having it as the default is a good way to go.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pubkey.asc
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20140926/d860af0e/attachment.ksh>