On 09/26/2014 10:58 AM, Alan Wild wrote: > I've been searching for some clarification on these two "fixes" and I'm > utterly confused. I've been lead to believe RedHat's first patch (6271) is
[Red Hat is two words.] > based on code from Chet that just causes bash to reject functions where > code appears outside of the function body. You are correct. Patch 25 for 6271 stops the parser from reading variables that contain more than a single function definition. But it does NOT stop the fact that the parser ran at all, so anything else buggy in the parser is still triggered. However, these subsequent bugs are MUCH harder to turn into exploits; so if you have a choice between patching 6271 now and waiting for the 7169 fix later at the cost of two updates, vs. doing only a single update to both CVEs at once, I _highly_ recommend patching 6271 now because of how bad it is. > > However, this patch was labeled as "insufficient" and 7169 now appears to > completely remove the ability to receive function definitions from the > environment. Not quite true. The proposed patch 26 for 7169 is here: http://www.openwall.com/lists/oss-security/2014/09/26/1 and it does NOT prevent the import of function definitions. All it does is fix one (out of three) known parser bugs; the parser will STILL parse the input, but will no longer misbehave because of that particular parse. I'm actually a bit more worried about CVE-2014-7186 being used as a denial of service attack (it's a parser bug where it is fairly easy to cause bash to segfault, and what I worry is that someone smart enough can come up with a complex string that turns the segfault into an arbitrary execution exploit - at least with CVE-2014-7169, the worst an attacker can do is create a file, but not execute arbitrary code). Furthermore, Red Hat's latest patch for 7169 does NOT prevent importing of functions, it only changes the WAY in which functions are imported, by sticking functions in a different namespace that no longer collides with normal shell variables. Remember, the vulnerability of 6271 is that a user with the ability to inject arbitrary contents into an ordinary shell variable has triggered arbitrary code; but if shell functions no longer use ordinary shell variables, the user is now just passing an odd string. Here's Red Hat's patch: http://www.openwall.com/lists/oss-security/2014/09/25/13 I'm hoping that Chet will take Red Hat's stance, or do something similar, and post a patch 27 that keeps function imports, but by implementing them in a way that no longer collides with normal variables. > > I have production code that requires function exporting that's going to be > broken by 7169. Is this some knee-jerk reaction by just RedHat or is this > a revised patch from Chet marking a change in bash functionality? Again, the goal is to NOT break function importing. Yes, we know that right now there is a regression where function importing of functions whose name is not a valid shell variable name is broken (see https://lists.gnu.org/archive/html/bug-bash/2014-09/msg00186.html), but I'm hoping that Chet will resolve that regression in the near future. > > My company's cybersecurity folks are pushing to install 7169 as soon as > possible and while I'm trying to push back I need to know if this a > strategic change in direction for bash, RHEL, or what, exactly. (Because I > need to know how extensively I need to reachitect my application). If you have questions about RHEL in particular, I suggest asking your contact at Red Hat rather than trying to get free advice on this list. (Although my mail address is from redhat.com, I am only an interested engineer, and NOT an official Red Hat policy maker). -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
