Autoconf Digest, Vol 125, Issue 22

[David A. Wheeler]

There has been a LOT of news about bash's Shell Shock bug lately.
Document some of the ramifications it has on portable scripting.

Documenting this seems reasonable.

I'm still debating about adding a sniffer to configure scripts that
warns users if they still have a vulnerable bash on their system,

I think it'd be reasonable to add some basic detections for easy cases.

For the first 5 shellshock CVEs there's CC0-licensed code you could use here:
https://github.com/hannob/bashcheck
Fully detecting it can be complex; that author hasn't found a way to
reliably and portably detect at least one case without address sanitizer.
But detecting the first two (CVE-2014-6271 and CVE-2014-7169)
are easy, just snag from:
https://github.com/hannob/bashcheck/blob/master/bashcheck

A number of people (including me!) want to counter
attacks against development and build environments, e.g.:
https://mailman.stanford.edu/pipermail/liberationtech/2013-June/009257.html
http://www.dwheeler.com/trusting-trust
A reminder might encourage someone to harden their system before it's subverted.

--- David A. Wheeler

[Eric Blake]

Post by David A. Wheeler

There has been a LOT of news about bash's Shell Shock bug lately.
Document some of the ramifications it has on portable scripting.

Documenting this seems reasonable.

Thanks; I'll push my patch soon.

Post by David A. Wheeler

I'm still debating about adding a sniffer to configure scripts that
warns users if they still have a vulnerable bash on their system,

I think it'd be reasonable to add some basic detections for easy cases.

Here's a fairly easy test:

export x='() { :; }'
y=`bash -c 'echo "$x"'`
if test "x$x" != "x$y"; then
echo "The first bash on your \$PATH is vulnerable to Shell Shock"
fi

(of course, I'd tweak it to fit in more with Autoconf style). But the
point is that ALL we have to check for is whether the shell FAILS to
export a normal variable as a normal variable, not whether functions get
auto-instantiated.