-- Leo's gemini proxy
-- Connecting to thrig.me:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini
Shellshock or "bashdoor" is about ten years old now (September, 2014), and folks on a mailing list were confusing it with heartbleed (of similar vintage and severity but for OpenSSL), so now might be a good time for a trip down the old memory lane… rowhammer time! Can't touch this. bash had for a long while a feature that allowed passing code to child processes via environment variables. Now features are known to some as bloat and to others as "attack surface". Bloat is a matter of opinion, but attack surface can be quite tangible (for an abstraction) especially when a high severity bug exists in bash but not in other shells that also have a lot of features and lines of code, ZSH for example. There was a parade of users coming into the #zsh IRC channel claiming that zsh was also vulnerable; they were executing bash from zsh, so (eventually—the routine got old, quick) I advised them to uninstall bash and try the exploit code, again.
$ env x='() { :;}; echo vulnerable' bash -c "echo test"
env: bash: No such file or directory
Wait, you cannot uninstall bash? Oh, well, now that might be a problem, especially if /bin/sh points to bash—some consider this problematic for various reasons (speed of execution, attack surface, portability) and have since reworked /bin/sh to point to the much smaller dash shell. (And then had to fix a bunch of shell scripts to remove various bashisms.) Apple's security policy forbade fixing the vulnerable bash, so that was a case of "hope that no attacker can figure out how to get to the shell until Apple pushes an update, or maybe reboot into single user mode and… Really depends on the system, who can access it, what services it offers.
What uses bash? This depends on the system, and varies from "nothing" to "lots of things that run maybe as root and accept user-supplied environment variables, possibly from remote systems on the internet". Worse, shellshock happened prior to sudo being patched for duplicate environment variables (November, 2015) and lots of other software did not (or still does not) audit for or clean out such duplicates. bash uses the last of the duplicates, while a security system or program may only cleanup the first duplicate, if at all. Whoops?
Why do code sharing via environment variables? At a guess it relates to shell scripts forking a lot, and then half your program is on the left side of a pipe, and the other half is on the right side (and shells vary as to whether the parent process is on the left or the right) as can be observed with something like:
$ i=3 j=3 ; while (( i-- )); do sleep 33; done |
while (( j-- )); do sleep 44; done
...
And then meanwhile a tool like pstree will show the two halves:
| |-+= 85744 jhqdoe -ksh (ksh)
| | |-+= 74877 jhqdoe -ksh (ksh)
| | | \--- 42208 jhqdoe sleep 33
| | \-+- 14371 jhqdoe -ksh (ksh)
| | \--- 42642 jhqdoe sleep 44
And so you might want a feature where code could be passed from parent to child via the environment, provided that one does not create a catastrophic security vulnerability in the process. There's the rub. I'm instead using a ksh these days, as it mostly meets my needs, has about an order of magnitude less code than bash does, and is maintained by the vendor so that's one less port to install, of which there are way too many already. Attack surface…
-- Response ended
-- Page fetched on Tue May 21 20:31:01 2024