[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <E1XZ6i3-0007Rc-1M@rmm6prod02.runbox.com>
Date: Tue, 30 Sep 2014 19:19:55 -0400 (EDT)
From: "David A. Wheeler" <dwheeler@...eeler.com>
To: "oss-security" <oss-security@...ts.openwall.com>
Subject: Re: Healing the bash fork
On Tue, 30 Sep 2014 17:35:21 +0000, Zach Wikholm <zwikholm@...i.net> wrote:
> I don't think I've ever actually written to the list, but we also haven't ever encountered a bug like this.
>
> Personally, I think a bullet point list (or whatever people use these days) is needed of what all is actually wrong, what is broken and how we as a community can assist is desperately needed. Last time I checked there are a total of 6 CVEs currently assigned to bash related vulnerabilities and I'm sure there are more to come.
Here's my attempt to summarize the "situation so far". As always, this is just my opinion.
1. What was actually wrong with Shellshock?
The bash shell, until recently, specially interpreted ANY environment variable beginning with '() {' as a function definition to be imported. Unfortunately, there are many cases where environment variables contain data from attackers, e.g., web applications invoked using CGI, ssh in some cases, and dhcp clients in some cases. Bash originally ran code after a closing "}", and that was quickly fixed. But that solution was not enough; after the first bash patch any error in the bash parser suddenly became a security vulnerability (and bash's parser was NOT designed to be security-relevant). That's why there are so many publicly-available vulnerabilities; there are lots of ways to break the parser.
2. What's the solution/what is broken?
Two approaches that resolve the problem have been created:
* Approach 1: Florian Weimer's approach. Bash functions to be exported have a prefix ("BASH_FUNC_") and suffix added. Then, ONLY environment variables with that prefix and suffix are interpreted specially. This approach is used by Red Hat, CentOS, Debian, Ubuntu, and Cygwin (at least), and was later accepted into bash upstream. The original approach used "()" as the suffix; bash upstream took this but switched to the "%%" suffix instead, which is a nice improvement (since "%" is not a shell metacharacter this is less likely to trigger OTHER problems). I know Cygwin is using the bash upstream '%%' suffix. This breaks programs that directly set environment variables and expected bash to interpret them as imported functions, but these are rare (I've only heard about them in test harnesses). The funny characters interfere with a few other programs (e.g., "at"), but programs are *supposed* to be able to handle such cases, so this is arguably revealing defects in *other* programs.
* Approach 2: Christos Zoulas's approach. This disables automatic import entirely, and requires an explicit request for function import. This has been applied in FreeBSD and NetBSD. This breaks any bash script that was expecting automatic import, and there are such things. Since bash is *documented* to support this functionality, this is a more obvious functionality break.
Either of these approaches completely solves the shellshock problem as currently revealed publicly. (Some of the CVE information is still not public, so it's *possible* there is another big reveal, but I have no indication of one.) Approach #1 is a little more backwards-compatible; approach #2 is arguably stronger. It's my preference that both be applied eventually, as a layered defense, but applying approach #2 *does* reduce functionality, which is why so many organizations are currently just applying approach #1 (Florian Weimer's).
3. How can I help?
Here are a few thoughts.
First, of course, update your systems, make sure it uses at least approach 1 or 2. (Unless someone has another full solution!)
Second, if you manage a distro, make sure it includes the patch and fix problems like "at" which may now have problems. I would suggest switching to upstream's '%%' suffix if you use Florian Weimer's approach.
Third, help see if there are other variations of this attack, or ways to more strongly defend against them with limited problems.
Fourth, consider tipping poor Chet Ramey (and the other bash developers). He's been doing this for over 20 years, unpaid to my knowledge.
Finally: *PLEASE* let me know if you have any good ideas on how to find vulnerabilities like this ahead-of-time. My article "How to Prevent the Next Hearbleed" (http://www.dwheeler.com/essays/heartbleed.html) lists a number of ways that Heartbleed-like vulnerabilities could have been detected ahead-of-time, in ways that are general enough to be useful. I'd like to do the same with Shellshock, so we can quickly eliminate a whole class of problems.
--- David A. Wheeler
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
