It was found the patch applied to fix CVE-2014-6271 was incomplete and could still allow some characters to be injected into another environment. An attacker could use this flaw to bypass some security restrictions, such as access files which he previously does not have access to etc (Standard file system permissions and selinux if enabled prevail though). There is no proof that this flaw could be used to execute arbitrary code, if it does it should be very difficult to exploit and depend on the specific configuration of the service. Reference: http://www.openwall.com/lists/oss-security/2014/09/24/40 https://bugzilla.redhat.com/show_bug.cgi?id=1141597#c23
Created bash tracking bugs for this issue: Affects: fedora-all [bug 1146326]
The case of system("foo") would depend on service configuration and what foo does. However, the case of system("foo" + shellescape(bar)), which seems like it must be common, is trivially exploitable, no?
(In reply to Tavis Ormandy from comment #3) > The case of system("foo") would depend on service configuration and what foo > does. However, the case of system("foo" + shellescape(bar)), which seems > like it must be common, is trivially exploitable, no? In what use case? ssh+ForceCommand/mod_cgi?
MITRE has assigned CVE-2014-7169 and rejected CVE-2014-3659. We shall be using CVE-2014-7169 for this issue now. http://www.openwall.com/lists/oss-security/2014/09/25/8
cgi, even the example in the PHP manual looks vulnerable http://php.net/manual/en/function.escapeshellarg.php (Ignoring that system("foo") could still be exploitable, depending on configuration)
(In reply to Tavis Ormandy from comment #6) > cgi, even the example in the PHP manual looks vulnerable > > http://php.net/manual/en/function.escapeshellarg.php > > (Ignoring that system("foo") could still be exploitable, depending on > configuration) Yeah. Upstream just posted a patch, now to see if it can be bypassed :) http://www.openwall.com/lists/oss-security/2014/09/25/10
It's a small thing, but people do tend to rely on the CVE number being in the bash changelog. Can you make sure it's there this time please?
+1 Please provide CVE ID number in bash package changelog. Thank you very much for your hard work and diligence.
This issue has been addressed in the following products: Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 Red Hat Enterprise Linux 5 Via RHSA-2014:1306 https://rhn.redhat.com/errata/RHSA-2014-1306.html
Can some one upload/attach the patches just like rhbz:1141597 here please?
IssueDescription: It was found that the fix for CVE-2014-6271 was incomplete, and Bash still allowed certain characters to be injected into other environments via specially crafted environment variables. An attacker could potentially use this flaw to override or bypass environment restrictions to execute shell commands. Certain services and applications allow remote unauthenticated attackers to provide environment variables, allowing them to exploit this issue.
bash-4.2.48-2.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
bash-4.2.48-2.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
I am able to see here (https://access.redhat.com/articles/1200223) that the fix for CVE-2014-6271 is provided for RHEL 4,5,6 and 7. Whereas on below link (https://access.redhat.com/security/cve/CVE-2014-7169) the fix for CVE-2014-7169 is only available for RHEL 5,6 and 7. May I know why? I am looking for the fix of CVE-2014-7169 for RHEL 4 as well. Please reply.
This issue has been addressed in the following products: Red Hat Enterprise Linux 6.4 EUS - Server and Compute Node Only Red Hat Enterprise Linux 6.2 AUS Red Hat Enterprise Linux 5.6 Long Life Red Hat Enterprise Linux 5.9 EUS - Server Only Red Hat Enterprise Linux 4 Extended Lifecycle Support Via RHSA-2014:1311 https://rhn.redhat.com/errata/RHSA-2014-1311.html
This patch breaks atd if functions are in your environment. atd will generate an invalid bash script. bash-4.1$ function hi() { echo 'hello'; } bash-4.1$ hi hello bash-4.1$ export -f hi bash-4.1$ echo "echo 'ha'" | at now job 65 at 2014-09-26 14:57 email comes in: sh: line 32: syntax error near unexpected token `=\(\)\ {\ \ echo\ \'hello\'" "}' sh: line 32: `"}; export BASH_FUNC_hi()'
(In reply to Mike from comment #42) > This patch breaks atd if functions are in your environment. atd will > generate an invalid bash script. > > bash-4.1$ function hi() { echo 'hello'; } > bash-4.1$ hi > hello > bash-4.1$ export -f hi > bash-4.1$ echo "echo 'ha'" | at now > job 65 at 2014-09-26 14:57 > > email comes in: > sh: line 32: syntax error near unexpected token `=\(\)\ {\ \ echo\ \'hello\'" > "}' > sh: line 32: `"}; export BASH_FUNC_hi()' Someone posted a fix here: https://access.redhat.com/articles/1200223#comment-824453 [quote] The latest rpm from this morning, broke at jobs on RHEL 6, with environment-modules rpm installed. sh: line 32: syntax error near unexpected token =\(\)\ {\ \ eval\ \/usr/bin/modulecmd\ bash\ \$*`" "}' sh: line 32: `"}; export BASH_FUNC_module()' You can fix the issue by commenting out the following lines. head -3 /usr/share/Modules/init/bash module()()()() { eval /usr/bin/modulecmd bash $*; } export -f module [/quote]
I'm not sure if I'd call that a "fix." It might be a workaround, maybe, but it very well could break things.
(In reply to Akemi Yagi from comment #43) > (In reply to Mike from comment #42) > > This patch breaks atd if functions are in your environment. atd will > > generate an invalid bash script. > > > > bash-4.1$ function hi() { echo 'hello'; } > > bash-4.1$ hi > > hello > > bash-4.1$ export -f hi > > bash-4.1$ echo "echo 'ha'" | at now > > job 65 at 2014-09-26 14:57 > > > > email comes in: > > sh: line 32: syntax error near unexpected token `=\(\)\ {\ \ echo\ \'hello\'" > > "}' > > sh: line 32: `"}; export BASH_FUNC_hi()' > > Someone posted a fix here: > > https://access.redhat.com/articles/1200223#comment-824453 > > [quote] > The latest rpm from this morning, broke at jobs on RHEL 6, with > environment-modules rpm installed. > > sh: line 32: syntax error near unexpected token =\(\)\ {\ \ eval\ > \/usr/bin/modulecmd\ bash\ \$*`" > "}' > sh: line 32: `"}; export BASH_FUNC_module()' > > You can fix the issue by commenting out the following lines. > head -3 /usr/share/Modules/init/bash > module()()()() { eval /usr/bin/modulecmd bash $*; } > export -f module > > [/quote] If you avoid having the function set, then yes this would fix it. However, in our case we actually have functions set that we need.
Actually, I meant to put a " " around the 'fix'.
This issue has been addressed in the following products: S-JIS for Red Hat Enteprise Linux 6 S-JIS for Red Hat Enteprise Linux 5 Via RHSA-2014:1312 https://rhn.redhat.com/errata/RHSA-2014-1312.html
Can someone please update https://securityblog.redhat.com/2014/09/26/frequently-asked-questions-about-the-shellshock-bash-flaws/ and/or https://access.redhat.com/articles/1200223 to mention that: Red Hat/Fedora builds that include the fix for CVE-2014-7169 are also immune to CVE-2014-7186/CVE-2014-7187, but people building upstream bash are not yet immune (because Red Hat has added patches that are not yet officially upstream) and give pointers of how to test whether bash is still vulnerable to shellshock attacks, such as using some of the test scripts in this mail for exposing whether a shell is vulnerable to CVE-2014-7186: https://lists.gnu.org/archive/html/bug-bash/2014-09/msg00238.html I'm worried that people will be lulled into a false sense of security ("I've applied both upstream bash patches, therefore I must be secure") when in reality they are still vulnerable to ShellShock until either the entire bash parser is audited to be bug-free (difficult) or until bash is fixed to avoid ever calling the bash parser on arbitrary contents of normal environment variables (easy, as done in the Red Hat patch).
bash-4.3.25-2.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
Created attachment 941826 [details] variables-affix-4.2.patch This is the hardening patch which adds function name mangling. It does not fix this bug (CVE-2014-7169), but it makes exploitation over the network impossible via the known vectors. The latter also applies to function parser bugs which may be discovered in the future. Erratas released by Red Hat which fix CVE-2014-7169 (using the upstream patch) also contain this hardening. Other vendors may have only applied the upstream fix for CVE-2014-7169, without this hardening patch.
Created attachment 941827 [details] bash42-049 Upstream fix from <ftp://ftp.gnu.org/pub/gnu/bash/bash-4.2-patches/bash42-049>, and included in our packages. Note: Some versions of patch have bugs in the offset detection for context diffs such as this one, and may misapply the patch in a way the resulting source code still compiles, but without actually fixing the vulnerability.
(In reply to Mike from comment #42) > This patch breaks atd if functions are in your environment. atd will > generate an invalid bash script. This is tracked here: https://bugzilla.redhat.com/show_bug.cgi?id=1147043
Florian, Does your patch fixes the parsing issue which Michal Zalewski found (CVE-2014-6277) beforehand?
Statement: (none)
This issue has been addressed in the following products: RHEV Manager version 3.4 Via RHSA-2014:1354 https://rhn.redhat.com/errata/RHSA-2014-1354.html
@BGROSLIER, please do not change the status of this bug.
This issue has been addressed in the following products: S-JIS for RHEL 5.9.Z Via RHSA-2014:1865 https://rhn.redhat.com/errata/RHSA-2014-1865.html