

“Shellshock” - bronson
http://www.dwheeler.com/essays/shellshock.html

======
danielweber
On my Debian/Ubuntu systems (that weren't in production and that I was free to
play with), I had a lot of luck pointing /bin/bash at /bin/dash and making a
separate /bin/bash-really. The default scripts weren't using /bin/bash at all.
Of the third-party scripts that did call /bin/bash, most of them were just
lazily using /bin/bash when they could have used /bin/sh just as well. (A few
that were actually using some bash-ism that it took me 5 minutes to fix, and
only 1 was left that was using some very very weird bash syntax that I
couldn't understand.)

Redhat apparently uses /bin/bash almost universally. That would be a nightmare
to try to fix under pressure.

One lesson I've learned (and I didn't always follow it) is to write POSIX-
compatible scripts whenever possible and point them at /bin/sh, which is
allowed to point to any POSIX-compatible shell. If we get word that, say, a
/bin/dash or /bin/ksh attack is coming, you can at least switch your default
"runtime" to another shell.

~~~
Zancarius
> One lesson I've learned (and I didn't always follow it) is to write POSIX-
> compatible scripts whenever possible and point them at /bin/sh, which is
> allowed to point to any POSIX-compatible shell. If we get word that, say, a
> /bin/dash or /bin/ksh attack is coming, you can at least switch your default
> "runtime" to another shell.

I don't understand why more people did not accept this as a viable solution
(with the exception of systems that are replete with bashisms). I had a
curious discussion on the Arch general mailing list with someone who seemed to
1) have his head in the sand regarding the severity of this exploit, 2)
believed bash's POSIX-compliant mode when invoked as /bin/sh was sufficient
for nearly all use cases, and 3) was content with the first patch that came
out as having resolved the problem even though it became obvious fairly early
on that the patch wasn't sufficient but made unreasonable demands for more and
more evidence to the contrary.

(Admittedly: The other side of the coin is that Arch has several scripts that
rely heavily on bashisms, so I guess I can at least partially understand where
he was coming from--but they all correctly use /bin/bash. The other argument I
observed, that adding a dependency on dash somehow inflates the default
install too much, seems absurd when dash is about 1/7th the size of bash.)

My solution so far has been to follow the advice you share (more or less)
where possible: Replace the /bin/sh symlink to point to /bin/dash and fix
those things that need fixing, patching bash in the process. It works well.
For everything else, I really rather wish they'd stick as closely to bare
POSIX-compatibility for system scripts (I'm guilty of using bash extensions,
too, so it would seem hypocritical to point fingers).

~~~
masklinn
> I don't understand why more people did not accept this as a viable solution

Mostly because it's a pain in the ass, I've tried doing it and not only do you
have to be careful to stick to POSIX, you also have to avoid shell and binary
extensions (e.g. `echo -e` would print `-e` with a POSIX echo, it won't with
GNU echo or most shell builtins). Even testing it multiple posix-compatible
and userland environments, you never really know whether your script actually
is cross-platform.

It'd be nice to have an environment (shell and binaries) which implements only
POSIX _and_ warns/errors when triggering common extensions.

~~~
reirob
That's a great idea to have a minimal POSIX distribution/environment, which
contains only POSIX commands and functions (as well for portable C program
testing). Is there something like this around?

~~~
lmm
You can get most of the value by keeping a VM with a minimal install of e.g.
OpenBSD. SourceForge used to offer a cluster of various OSes where you could
test your releases, I don't know if that's still running.

------
jpwgarrison
I read a few lines, and then for some reason right clicked into "View Source"
intending to take a quick peek and read the rest. WOW. That is commenting your
code done right.

------
aaron-lebo
Mr. Wheeler is also the person behind the loved and hated sweet-expressions,
which provide a way of writing lisp using Python-style indentation [1].

1\.
[http://www.dwheeler.com/readable/index.html](http://www.dwheeler.com/readable/index.html)

~~~
moyix
I'm not sure that's the thing he's most known for. I know his work mainly from
SLOCCount [1] and his clever solution for Ken Thompson's "Reflections on
Trusting Trust" hack [2].

1\. [http://www.dwheeler.com/sloccount/](http://www.dwheeler.com/sloccount/)
2\. [http://www.dwheeler.com/trusting-
trust/](http://www.dwheeler.com/trusting-trust/)

