Pretty much every Unix-like system out there that comes with bash is vulnerable to the “ShellShock” bug. It appears there are actually two several distinct bugs with similar symptoms.
Here are the two announcements:
- CVE-2014-6271 announces the first vulnerability (“…processes trailing strings after function definitions in the values of environment variables, which allows remote attackers to execute arbitrary code via a crafted environment…”)
- CVE-2014-7169 says that a vulnerability remains after patching for the previous one. (“…processes trailing strings after certain malformed function definitions in the values of environment variables…”)
The first bug involves continuing to parse and execute code that follows a function definition when importing a function from the environment into a bash shell. The second bug involves incorrectly retaining one character of parser state that can affect parsing the next command, when importing a function where the function has certain kinds of parse errors.
In the newest bash 4.3, patch 025 fixes CVE-2014-6271 and patch 026 fixes CVE-2014-7169. For bash 4.1, patches 012 and 013 fix the two bugs, respectively.
Update 2014/10/06: There are more bugs being found, and probably more to come. However, patch 4.3-027 (requiring function imports to have a name prefix) has turned all of these security bugs into non-security bugs, because attackers shouldn’t be allowed to specify variable names anyway. Thus, patch 027 is the most important patch.
Patching Mandriva 2010.2 (and other versions)
I still use Mandriva 2010.2, which is no longer supported. Thus, I have to build patched versions of bash myself. Due to popular request, I’ve also built the SRPM on some older Mandriva distributions as well.
On Mandriva 2010.2, I built both bash 4.3 and 4.1 based on the bash-4.1-6mdv2010.1 SRPM. The bash 4.1 package minimizes changes from the original Mandriva 2010.2 package, for those who are averse to upgrades.
No guarantees these fix all past and future bugs. But they seem to work for me so far.
| Bash 4.1-017 | i586 | x86-64 |
|---|---|---|
| Mandriva 2010.2 |
bash-4.1-12mdv2010.2 bash-debug-4.1-12mdv2010.2 bash-doc-4.1-12mdv2010.2 |
bash-4.1-12mdv2010.2 bash-debug-4.1-12mdv2010.2 bash-doc-4.1-12mdv2010.2 |
| Source RPMs | |
|---|---|
| Mandriva 2010.2 | bash-4.1-12mdv2010.2 |
| Mandriva 2010.2 Used to build on 10.2-2011.0 |
bash-4.3-6mdv2010.2 |
Changelog
- bash-4.3-6: Apply patches up to bash 4.3-030
- bash-4.3-5: Apply patches up to bash 4.3-029
- bash-4.3-4: Apply patches up to bash 4.3-028
- bash-4.3-3:
- Apply official patches up to bash-4.3-027
- Remove man pages for true and false, which conflicted with the same files in coreutils-doc
- bash-4.3-2: Apply official patches up to bash-4.3-026
- bash-4.3-1: Apply official patches up to bash-4.3-025 and an unofficial patch equivalent to 026
Build notes
Bash 4.3 seems to require a fairly new version of the readline library. I decided to use readline bundled with bash 4.3 instead of requiring the system-wide readline to be upgraded (configure bash without --with-installed-readline). Bash 4.3 is bundled with readline 6.3, but Mandriva 2010.2 comes with readline 6.1.
During normal build, bison takes parse.y and generates y.tab.c, but both files are included in the source tarball. There are patches that modify both y.tab.c and parse.y, so y.tab.c‘s modification time can be left newer than parse.y, which causes y.tab.c to not be re-generated during build. But some patches (e.g., bash 4.1-013) only patch parse.y but not y.tab.c, which can cause an incorrect build. I chose to always delete y.tab.c after applying patches so it is always re-generated from parse.y during build.
Bash 4.3 tries to install a few more documentation files. This is not handled entirely cleanly because some files are installed (by make install) into %{_buildroot} while some use %doc. Behaviour varies depending on rpm version. Also, 2007.1 and older used versioned document directory names (/usr/share/doc/bash-4.3) instead of unversioned (/usr/share/doc/bash).
Hi,
thanks for the work but since I still run mandriva 2009 I can use your rpm that requires libc 6. Could you compile it statically with all the libs so that I could install it?
Thanks a lot
I think it might be easier for me to build a regular RPM on Mandriva 2009 (I’m no expert at RPM packaging…). Which version are you using? 2009.0 or 2009.1?
it would be great. I’m using 2009.0 but I’ve also found another web server with 2007.0 do you think you could do the work also for 2007? Thanks so much
thanks a lot for all the extra work!!!
The one for 2009 works like a charm but the one for 2007.0 fails in installation
error: Failed dependencies:
setup < 2.7.4-1mdv conflicts with bash-4.3-1mdv2007.0.i586
any idea on how to solve it?
Hmm, you’re right. It looks like the “conflict” was declared because /etc/bashrc used to be included in the setup package, but is now included in bash.
I think it’s safe to –nodeps (and then remove the old bash-3.1 package?) as long as you know /etc/bashrc will be overwritten, in case you put any system-wide edits there. I’m not sure there’s an easy way to package this, because it seems like the “proper” way to do this would be to also distribute an updated setup with the new bashrc…
Thanks for pointing it out though. Maybe I can make the 2007.0 RPM not provide /etc/bashrc, then remove the conflict.
I think the new 2007.0 RPM I just posted should fix this. It no longer includes /etc/bashrc, and I declared a conflict with setup >= 2.7.4-1mdv to discourage using this on a newer system where the bash package is supposed to provide /etc/bashrc.
it would be great. I’m using 2009.0 but I’ve also found another web server with 2007.0 do you think you could do the work also for 2007? Thanks so much
Thanks a lot! we have a 2010.1 here (bash-4.1-6mdv2010.1), but I tried your version and it works!
Thanks!
Muito obrigado. A própria Mandriva agradece 🙂
bash-4.3-1mdv2010.2.x86_64.rpm works on Mandriva 2011.0 too.
Gracias. Funciona bien para mandriva 2010.1
As much as I hate to admit it we have a critical app the is running Mandrake 2006, Winter edition I think. Any hope for this version?
Thank you for your time.
Done. And I thought I was upgrade-averse… 😉
I don’t know why but the system is not letting me reply in the thread.
I’ve just install the last version of the 2007.0 package. I’ve to –force its installation due to due to conflict with usr/share/man/man1/false.1.bz2 and usr/share/man/man1/true.1.bz2 in coreutils-doc. But apart from this it works like a charm. Thanks a lot.
I think there’s a limit to the depth of the tree (4 or 5 levels?).
That’s strange. My fresh install of Mandriva 2007.0 didn’t complain about the conflicting files. But I do see that both bash and coreutils-doc both provide the same files, which is also true in the original packages for 2010.0 and 2010.2 (but not the other versions). I wonder why most of them didn’t complain about conflicting files… (only 2011 complained for me)
Ok, I see what happened. Bash 4.x included
trueandfalse as built-in commands, which caused man pages to be generated for them. I suppose nobody noticed this in the 2010.x series, but in 2011, the man pages for true and false were explicitly removed.hi Henry. thanks for all your work!
a question: is it safe to use the rpms for 2010.2 in mandriva 2010.1?
You tried it and it works, right?
I don’t imagine there would be a problem. Mandriva 2010.2 was only a minor update, so I doubt there’s anything incompatible with it.
right.
ok, many thanks!
So just rpm -i on all three rpms? Does it matter what order I install them?
I would use urpmi to work out the dependencies, or rpm -U (upgrade). Normally you’d list all of the packages at the same time and let rpm/urpmi figure out what order to install them. You probably won’t need all of the packages. You could check which of these packages you already have and only upgrade those.
(bash-doc is man pages, and bash-debug is debugging symbols which most people wouldn’t need)
As pointed out by Walter’s comment above, there could be a conflict with two of the man page files, which rpm might complain about. I’ll fix those soon.
I usually do:
rpm -Uvh *.rpm
(upgrade + verbose + show hashbar)
Thanks for the replies. I inherited responsibility for several “old” server that have Mandriva 2007, 2008, 2009 on them, so this page is a godsend for me. I have no Mandriva/Mandrake experience. Many thanks.
I have applied the patches, but they do not fully pass the tests on this page:
http://www.zdnet.com/shellshock-better-bash-patches-now-available-7000034115/
That is, the shell code does not get executed, but there are still error messages.
Test 1.
$ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"gives
bash: warning: x: ignoring function definition attemptbash: error importing function definition for `x'
bash: error importing function definition for `BASH_FUNC_x()'
test
instead of
bash: warning: x: ignoring function definition attemptbash: error importing function definition for `BASH_FUNC_x'
test
Test 2.
]$ cd /tmp; rm -f /tmp/echo; env 'x=() { (a)=>\' bash -c "echo date";gives
cat /tmp/echobash: x: line 1: syntax error near unexpected token `='
bash: x: line 1: `'
bash: error importing function definition for `x'
date
cat: /tmp/echo: No such file or directory
instead of
datecat: /tmp/echo: No such file or directory
Can anyone shed light on this?
That’s a very poorly-explained article… 🙁 They didn’t define “pass” or why the messages should be the way they are. Having read through part of the bash source code, I can somewhat figure out what they mean.
There have been three patches for bash released over the last few days:
It seems like the article is expecting that patches up to 027 are applied. In patch 027, only variables named BASH_FUNC_xxx are treated as functions, so fewer error messages are produced when the test case isn’t named BASH_FUNC_xyz. Error messages are expected because the test cases use malformed functions. The critical part is that extra code is not executed (i.e., the “echo vulnerable” or “date”.)
I’ve only applied patches up to 026 so far. Continually rebuilding theses takes time, so I’m planning to wait a day or two for the patches to stop coming before rebuilding all of them a third time. Patch 026 fixes all of the known bugs, but 027 makes it harder to attack the function import mechanism when future bugs are found in that mechanism.
The CVE-2014-7186/7187 issues are new to me, and as far as I know, haven’t been fixed upstream.
Thanks for the reply Henry. I since found a much better site with tests: https://shellshocker.net/
I did wonder how you were managing to build for so many different versions…
Installed a fresh copy of every version from ISO on a VM, install the packages that are required to build the bash SRPM, tinker with the SRPM if necessary, then build. 🙂
BTW, an Ubuntu server I have passes the (shellshocker.net)tests for Exploit 4 (CVE-2014-7186) and Exploit 5 (CVE-2014-7187).
Interesting. I still don’t see a patch for it on ftp://ftp.gnu.org/gnu/bash/bash-4.3-patches/. Do you know the date of the ubuntu update? Maybe they got advanced notification of the patch somewhere… Even with bash 4.3-027, it still fails the test for 7186 and 7187.
I think CVE-2014-6277 and 6278 are still outstanding too…
The ubuntu server has bash 4.2.25(1). Very strange how it passes all tests.
They could be getting advanced notice of the bugs and fixes before they become official patches, so the modification date might be a better indicator than the version number.
Not sure how to check the date of the update. I installed it yesterday afternoon(Sep.29).
Found it using:
zcat /usr/share/doc/bash/changelog.Debian.gz | lessSurely there must be an easier way to see the change log?
First part of the changelog:
bash (4.2-2ubuntu2.5) precise-security; urgency=medium* SECURITY UPDATE: out-of-bounds memory access
- debian/patches/CVE-2014-718x.diff: guard against overflow and fix
off-by-one in bash/parse.y.
- CVE-2014-7186
- CVE-2014-7187
* SECURITY IMPROVEMENT: use prefixes and suffixes for function exports
- debian/patches/variables-affix.diff: add prefixes and suffixes in
bash/variables.c.
-- Marc Deslauriers Fri, 26 Sep 2014 13:27:53 -0400
bash (4.2-2ubuntu2.3) precise-security; urgency=medium
* SECURITY UPDATE: incomplete fix for CVE-2014-6271
- debian/patches/CVE-2014-7169.diff: fix logic in bash/parse.y.
- CVE-2014-7169
-- Marc Deslauriers Thu, 25 Sep 2014 02:11:10 -0400
bash (4.2-2ubuntu2.2) precise-security; urgency=medium
* SECURITY UPDATE: incorrect function parsing
- debian/patches/CVE-2014-6271.diff: fix function parsing in
bash/builtins/common.h, bash/builtins/evalstring.c, bash/variables.c.
- CVE-2014-6271
-- Marc Deslauriers Mon, 22 Sep 2014 15:31:07 -0400
bash (4.2-2ubuntu2.1) precise-proposed; urgency=low
* Fix directory expansion. (LP: #778627)
-- Alec Warner Mon, 18 Mar 2013 22:12:54 +0000
Thanks! It does look like Ubuntu has applied patches more than just the official ones.
Fixing CVE-2014-7169 is patch 026, and the “security improvement” is patch 027.
Thank you very much for a work well done, Henry.
Blogdrake, the official spanish-speaking Mandriva/Mageia Community has his server (running MDV2010.2) with a patched bash thanks to you.
See ya!
Thanks! There are still known bugs that are unpatched though. Do update once the patches are available… And I wouldn’t be surprised if new bugs continue to be discovered in the near future. The bash code is scary…
Yeah. I’m a sysadmin and I and the rest of our IT team have been patching and re-patching over and over again. We’re bleeding from our eyes ATM 😛
Thanks again for your work. In a IT structure we’re able to apply patches as soon it’s published, but thanks to you newbies (or lazy) users from MDV can be safe easily.
Patch 028 fixing the buffer overflows just appeared on gnu. Four day lag between vendors and gnu.. 🙁
Just saw that, thanks 🙂 Another several hours lag for me! 😛
…is it just me, or does patch 028 not apply cleanly? (Lots of rejected hunks in y.tab.c) 🙁
(Patch 015 on bash 4.1 seems ok…)
Patch 028 really is broken, but not hard to work around.
The diff of y.tab.c wasn’t done against bash-4.3-027, but against the file regenerated by bison from bash-4.3-027, so comments with file names and line numbers were different.
I have not yet tried 028 with 4.3 but your comments mean I won’t bother trying. How much hand editing did you have to do to get it to work?
Very little.
During a normal build, parse.y is an input to bison, which generates y.tab.c (the parser). The bash package distributes both files, so patches also patch both files, but y.tab.c is actually redundant.
The 028 patch has a broken y.tab.c, so all I did was remove the section that changes y.tab.c. My build script deletes and regenerates y.tab.c anyway because I don’t trust the two files to be synchronized.
Update: Looks like they tinkered with the 028 patch. I haven’t tried it yet, but I’m guessing they fixed it.
Hi
I really would like to send you money for saving the day. Where is your paypal gift button?
Patch 028 now works.
A brief word of gratitude for your public-spirited work.
I had failed to patch bash on my elderly but faithful
Mdv2010.2 – until landing on your site. After that, a
breeze. My thanks, Fred Green
4.3 patch 030 available on http://ftp.gnu.org. I encountered no issues using this patch/
Hmm… Have you looked through the code in the patch? The
char* parser_remaining_input ()function looks a little suspicious to me. On the line marked “XXX” (yes, it’s marked in the patch too), the programmer’s intention seems to be returning a one-character string with a null character, but actually returns a null pointer. Looking at the way the function is used, this doesn’t matter (null char and null pointer are treated the same way), but looks like a potential for future confusion…char * parser_remaining_input () { if (shell_input_line == 0) return 0; if (shell_input_line_index < 0 || shell_input_line_index >= shell_input_line_len) return '\0'; /* XXX */ return (shell_input_line + shell_input_line_index); }I also don’t understand the motivation behind:
It seems like token_to_read is usually
'\n'when the parser is reset. Why was it set to zero only for interactive shells? And why should it now change to zero in all cases? (Edit: I can see how this likely relates to bug CVE-2014-6278, although I don’t understand how the bug works.)Great job.
Just to let you know that your RPM for 10.2 seems to work fine for 10.1 too 🙂
Yep, there’s not much point in building a 2010.1 RPM. The two releases are so similar that even the package repositories are identical between 2010.1 and 2010.2.
Thanks a lot for your job.
About the annoucement “CVE-2014-6277” => https://access.redhat.com/security/cve/CVE-2014-6277
Can you tell me if your bash package for Mandriva 2010.0 is affected (and patched) ?
Thanks again, have a good day 😉
I believe 4.3-029 fixes CVE-2014-6277, and that patch is included. But I should emphasize that the security issue is that the parser is exposed (fixed in patch 027), not so much that the parser has bugs.
Totally off topic here. Given the recent poodle scare, has anyone tried to patching openssl/ssllib for their old Mandriva distros?
I have not, and it seems like the appropriate action (whether to disable SSL 3.0) is site-dependent?