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
