There are also a couple of threads going on the oss-security mailing list regarding this and it looks like there are still a number of additional vulnerabilities that are still being addressed. Here is a summary someone recently posted to one of the threads.
Originally posted to OSS-Security(http://www.openwall.com/lists/oss-security/2014/09/30/35): On Tue, Sep 30, 2014 at 5:19 PM, David A. Wheeler <[email protected]> wrote: > On Tue, 30 Sep 2014 17:35:21 +0000, Zach Wikholm <[email protected]> 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 On Wed, Oct 1, 2014 at 8:10 AM, Thad Van Ry <[email protected]> wrote: > I really like Red Hat's security blog. You can find it at > securityblog.redhat.com. The two posts that deal with shellshock are: > https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/ > https://securityblog.redhat.com/2014/09/26/frequently-asked-questions-about-the-shellshock-bash-flaws/ > > > On Wed, Oct 1, 2014 at 3:26 AM, Dan Egli <[email protected]> wrote: > >> Speaking of this vulnerability, is there a web site somewhere (like >> trustedsec or similar) where this vulnerability is covered in more detail? >> I'd really like to learn up on it, see how it is being used and how it's >> being treated (besides by patching/updating your bash and/or php programs). >> >> Thanks! >> --- Dan >> >> /* >> PLUG: http://plug.org, #utah on irc.freenode.net >> Unsubscribe: http://plug.org/mailman/options/plug >> Don't fear the penguin. >> */ >> > > /* > PLUG: http://plug.org, #utah on irc.freenode.net > Unsubscribe: http://plug.org/mailman/options/plug > Don't fear the penguin. > */ /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
