Bash CVE-2014-6271 Vulnerability

nikor · 2014-09-25 22:32:10

Jackson on the bug thread had a patch to disable the feature that seem to work.

To use it do the following:

sudo pacman -S abs
sudo abs
cp -r /var/abs/core/bash ~/
cd ~/bash
wget nikor.dk/PKG.patch nikor.dk/disable.patch
patch -p1 < PKG.patch
makepkg
pacman -U bash-4.3.024-[TAB]

I hope it helps

aaron.chantrill · 2014-09-26 03:37:39

I'm still seeing this:

$ sudo pacman -Syu
:: Synchronizing package databases...
core is up to date
extra is up to date
community is up to date
multilib is up to date
archlinuxfr is up to date
:: Starting full system upgrade...
warning: perl-datetime-format-mail: local (0.3001-8) is newer than community (0.401-1)
there is nothing to do
$ env pwned='() { :;} ; echo pwned' bash -c 'true'
pwned
$

so in my case, updating doesn't seem to be helping.

$ pacman -Si bash
Repository : core
Name : bash
Version : 4.3.024-2
Description : The GNU Bourne Again shell
Architecture : x86_64
URL : http://www.gnu.org/software/bash/bash.html
Licenses : GPL
Groups : base
Provides : sh
Depends On : readline>=6.3 glibc
Optional Deps : bash-completion: for tab completion
Conflicts With : None
Replaces : None
Download Size : 1240.70 KiB
Installed Size : 6655.00 KiB
Packager : Felix Yan <felixonmars@archlinux.org>
Build Date : Wed 24 Sep 2014 02:07:58 AM EDT
Validated By : MD5 Sum SHA256 Sum Signature

I tried to limit /etc/pacman.d/mirrorlist to a good mirror (as I read it) on https://www.archlinux.org/mirrors/status/, but just got
:: Synchronizing package databases...
error: failed retrieving file 'core.db' from archlinux.polymorf.fr : The requested URL returned error: 404 Not Found
error: failed to update core (download library error)
error: failed retrieving file 'extra.db' from archlinux.polymorf.fr : The requested URL returned error: 404 Not Found
error: failed to update extra (download library error)
error: failed retrieving file 'community.db' from archlinux.polymorf.fr : The requested URL returned error: 404 Not Found
error: failed to update community (download library error)
error: failed retrieving file 'multilib.db' from archlinux.polymorf.fr : The requested URL returned error: 404 Not Found
error: failed to update multilib (download library error)

I'm not sure how to get to a good mirror.

Thanks.

Scimmia · 2014-09-26 04:06:56

Should be fixed in 4.3.026-1

W.F.Cody · 2014-09-26 07:16:29

Now with the systemd init - would it be safe to replace bash completely by a "shim package" (for example, a package providing "bash" with a shell script redirecting /usr/bin/bash to sh emulated /usr/bin/zsh)? I know that "security by obscurity" is a weak argument, but I am using zsh as user shell anyway and if I could eliminate one more potential avenue for attack that would be nice. Are there any corner cases where Arch linux still depend on Bash-specific functionality not provided by other shells?

Both this Bash issue and the OpenSSL issue before shows that widespread reliance of a single tool can be catastrophic and a richer, more diverse ecosystem could be desirable.

progandy · 2014-09-26 07:33:43

W.F.Cody wrote:

would it be safe to replace bash completely by a "shim package" (for example, a package providing "bash" with a shell script redirecting /usr/bin/bash to sh emulated /usr/bin/zsh)?

It should work for most stuff, but there are still differences and you might run into problems with some things.

[zsh]$ emulate sh
[zsh]$ var=test
[zsh]$ old=#t
[zsh]$ echo ${var/$old/_}
test
[zsh]$ test -v VAR
test: unknown condition: -v
[zsh]$ 

[bash]$ var=test
[bash]$ old=#t
[bash]$ echo ${var/$old/_}
_est
[bash]$ test -v VAR
[bash]$

...

Last edited by progandy (2014-09-26 07:35:51)

vibee · 2014-09-26 08:13:24

Scimmia wrote:

Should be fixed in 4.3.026-1

WIth 4.3.026-1, this outputs 'hacked':

X='() { function a a>\' bash -c echo; [ -e echo ] && echo "hacked"

Tom B · 2014-09-26 10:38:26

That doesn't show "hacked" for me with the latest update.

MK13 · 2014-09-26 10:46:17

I can confirm Tom B's reply: On my raspberry Pi with 4.3.26-1 no output returned by the command of vibee

noctavian · 2014-09-26 13:01:10

I get "hacked" if I run vibee's code.

-- mod edit: Pasting a screesnhot of textual output is just stupid: read the Forum Etiquette and only post thumbnails http://wiki.archlinux.org/index.php/For … s_and_Code [jwr] --

capoeira · 2014-09-26 13:31:59

vibee wrote:

Scimmia wrote:
Should be fixed in 4.3.026-1
WIth 4.3.026-1, this outputs 'hacked':
X='() { function a a>\' bash -c echo; [ -e echo ] && echo "hacked"

no output here

Scimmia · 2014-09-26 14:00:30

W.F.Cody wrote:

Now with the systemd init - would it be safe to replace bash completely by a "shim package" (for example, a package providing "bash" with a shell script redirecting /usr/bin/bash to sh emulated /usr/bin/zsh)? I know that "security by obscurity" is a weak argument, but I am using zsh as user shell anyway and if I could eliminate one more potential avenue for attack that would be nice. Are there any corner cases where Arch linux still depend on Bash-specific functionality not provided by other shells?

There are many, many things that depend on bashisms, Arch's package management system being one. Getting rid of bash completely is going to be difficult.

Last edited by Scimmia (2014-09-26 14:01:05)

denaje · 2014-09-26 14:01:20

noctavian wrote:

I get "hacked" if I run vibee's code.
https://i.imgur.com/WImiRJa.png

I also get "hacked" if I run this code on my servers, but not on my laptop machine. Both bash binaries have the same md5sum, so is there something in the environment that would cause different output?

kokoko3k · 2014-09-26 14:29:34

I've compiled the arch patched source on an old debian server.
Hacked message on the debian server, no hacked message on the arch box.
the first test:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

Doesn't output "vulnerable" on both machines.

lolilolicon · 2014-09-26 14:29:35

Scimmia wrote:

There are many, many things that depend on bashisms, Arch's package management system being one. Getting rid of bash completely is going to be difficult.

Scripts which specifies #!/bin/bash are entitled to use bashism, since they're asking for it.
Scripts which specifies #!/bin/sh must not use bashism, or that's a bug.
From what I gather, nowadays #!/bin/sh scripts are mostly free of bashism -- at least they work with dash.

branch · 2014-09-26 14:30:43

denaje wrote:

I also get "hacked" if I run this code on my servers, but not on my laptop machine. Both bash binaries have the same md5sum, so is there something in the environment that would cause different output?

Try

rm echo
X='() { function a a>\' bash -c echo; [ -e echo ] && echo "hacked"

There could a file named "echo" left over from running this test on a vulnerable version.

kokoko3k · 2014-09-26 14:32:32

The last test from branch doesn't create the echo file on arch and the debian server.

Scimmia · 2014-09-26 14:42:26

lolilolicon wrote:

Scimmia wrote:
There are many, many things that depend on bashisms, Arch's package management system being one. Getting rid of bash completely is going to be difficult.
Scripts which specifies #!/bin/bash are entitled to use bashism, since they're asking for it.
Scripts which specifies #!/bin/sh must not use bashism, or that's a bug.
From what I gather, nowadays #!/bin/sh scripts are mostly free of bashism -- at least they work with dash.

Agreed, but not relevant since I was replying to a post asking about linking /usr/bin/bash to something else. Don't remove quotes to try to change the meaning of my post.

lolilolicon · 2014-09-26 14:55:01

Sorry to misunderstand you. I'm not deliberately trying to change the meaning of your post.

Why didn't you just say, "many things depend on bash"?

vibee · 2014-09-26 16:16:39

branch wrote:

denaje wrote:
I also get "hacked" if I run this code on my servers, but not on my laptop machine. Both bash binaries have the same md5sum, so is there something in the environment that would cause different output?
Try
rm echo
X='() { function a a>\' bash -c echo; [ -e echo ] && echo "hacked"
There could a file named "echo" left over from running this test on a vulnerable version.

Thanks, that was it.

aaron.chantrill · 2014-09-26 18:20:21

vibee wrote:

Scimmia wrote:
Should be fixed in 4.3.026-1
WIth 4.3.026-1, this outputs 'hacked':
X='() { function a a>\' bash -c echo; [ -e echo ] && echo "hacked"

I wish I understood exactly what is happening here.

As I understand it, the first patch looked for functions where extra stuff was trailing the function definition. Since this was written in a hurry, I assume it was counting curly brackets. This exploit appears to work because it does not actually close the function block.

It appears like when you go into the bash shell with "bash -c echo" (or in the RedHat version 'bash -c "echo date") the first word in the command, "echo", is pasted onto the end of the definition ("X () { function a a>\") , causing something (a? the parameter to the function?) to be written to a new file called "echo" (in the first case - nothing, in the second case - the current datetime). Certainly much harder to exploit than being able to get any arbitrary command to run just by passing it to a webserver, but still spooky.

However, even when this works on a totally unpatched system, I'm still getting a bunch of errors:

$ ls TEST
ls: cannot access TEST: No such file or directory
$ export X='() { function a a>\'
$ bash -c "TEST date"
bash: X: line 1: syntax error near unexpected token `a'
bash: X: line 1: `'
bash: error importing function definition for `X'
$ cat TEST
Fri Sep 26 13:53:00 EDT 2014

and when I try to run the command straight out, it just errors:
$ x () { function a a>TEST date
bash: syntax error near unexpected token `a'
$ x () { function a a>\TEST date
bash: syntax error near unexpected token `a'

and the TEST file is never created.

So is it figuring out that the function definition is foobar and just taking what's left and prepending it to the command? What is actually happening above when the TEST file is created?

Thanks

cfr · 2014-09-26 22:50:53

I would like to understand this, too. Is the point that bash is trying to execute the function a (whatever a might be) as part of the setup of the environment of the new shell? In the case of the examples, this is harmless because bash just complains about not recognising things etc. But if a was something properly designed, it would silently become part of the environment, hence creating plenty of potential for havoc?

[But this could be completely and utterly not what is going on.]

I also am a bit confused about what each patch is doing. I understand that in Arch, bash v. *.24 contained one patch and bash v. *.26 contained another. Does that leave further issues outstanding? (Are Red Hat or whoever working on a further patch?) Or does that fix the issue completely, insofar as is currently publicly know?

lolilolicon · 2014-09-26 22:58:42

Look here for what patches are applied to the Arch Linux bash package:
https://projects.archlinux.org/svntogit … kages/bash

The mechanism of bash function export / import can be inspected this way,

export function -> exported env var,

% bash -c 'wtfun() { :;}; export -f wtfun; env -0 | grep -z wtfun'
BASH_FUNC_wtfun()=() {  :
}

env var that meets particular criteria -> imported as function

env 'BASH_FUNC_wtfun()=() { :;}' bash -c 'declare -pf wtfun'
wtfun () 
{ 
    :
}
declare -fx wtfun

This is with the Red Hat patch which addes prefix BASH_FUNC_ and suffix ().

Last edited by lolilolicon (2014-09-26 23:09:01)

cfr · 2014-09-26 23:23:06

I guess Arch's bash is only partially patched.

Using the test from https://bugzilla.redhat.com/show_bug.cgi?id=1141597#c47:

cd /tmp && rm -f /tmp/echo && env 'x=() { :;}; echo vulnerable' 'f=() { (a)=>\' bash -c 'echo echo vulnerable'; cat echo

gives me

echo vulnerable
cat: echo: No such file or directory

As I understand it, a patched Red Hat patch would not return this result. However, I'm not clear from that page if those patches are upstream or Red Hat only at this point.

EDIT: I guess Red Hat are using a different patch, according to https://securityblog.redhat.com/2014/09 … ash-flaws/. Will upstream adopt that patch so that Arch will eventually get a fully patched bash in the same way? Or is there some reason upstream will not want to use Red Hat's fix and will need to develop an independent patch which works differently?

Last edited by cfr (2014-09-26 23:28:27)

lolilolicon · 2014-09-26 23:27:35

The output means your bash is not vulnerable. A vulnerable bash should have created a file ./echo with "vulnerable" in it.
EDIT: don't worry, our packager is doing a good job. We are using the Red Hat patches, not only the official ones from bash upstream.

Last edited by lolilolicon (2014-09-26 23:33:02)

nomorewindows · 2014-09-26 23:43:33

Apparently the media is trying to *bash* the *nix community with this one. Another *convenient* reason to use M$. Looks like to me the problem is already half solved.

Last edited by nomorewindows (2014-09-26 23:44:12)

Arch Linux

#26 2014-09-25 22:32:10

Re: Bash CVE-2014-6271 Vulnerability

#27 2014-09-26 03:37:39

Re: Bash CVE-2014-6271 Vulnerability

#28 2014-09-26 04:06:56

Re: Bash CVE-2014-6271 Vulnerability

#29 2014-09-26 07:16:29

Re: Bash CVE-2014-6271 Vulnerability

#30 2014-09-26 07:33:43

Re: Bash CVE-2014-6271 Vulnerability

#31 2014-09-26 08:13:24

Re: Bash CVE-2014-6271 Vulnerability

#32 2014-09-26 10:38:26

Re: Bash CVE-2014-6271 Vulnerability

#33 2014-09-26 10:46:17

Re: Bash CVE-2014-6271 Vulnerability

#34 2014-09-26 13:01:10

Re: Bash CVE-2014-6271 Vulnerability

#35 2014-09-26 13:31:59

Re: Bash CVE-2014-6271 Vulnerability

#36 2014-09-26 14:00:30

Re: Bash CVE-2014-6271 Vulnerability

#37 2014-09-26 14:01:20

Re: Bash CVE-2014-6271 Vulnerability

#38 2014-09-26 14:29:34

Re: Bash CVE-2014-6271 Vulnerability

#39 2014-09-26 14:29:35

Re: Bash CVE-2014-6271 Vulnerability

#40 2014-09-26 14:30:43

Re: Bash CVE-2014-6271 Vulnerability

#41 2014-09-26 14:32:32

Re: Bash CVE-2014-6271 Vulnerability

#42 2014-09-26 14:42:26

Re: Bash CVE-2014-6271 Vulnerability

#43 2014-09-26 14:55:01

Re: Bash CVE-2014-6271 Vulnerability

#44 2014-09-26 16:16:39

Re: Bash CVE-2014-6271 Vulnerability

#45 2014-09-26 18:20:21

Re: Bash CVE-2014-6271 Vulnerability

#46 2014-09-26 22:50:53

Re: Bash CVE-2014-6271 Vulnerability

#47 2014-09-26 22:58:42

Re: Bash CVE-2014-6271 Vulnerability

#48 2014-09-26 23:23:06

Re: Bash CVE-2014-6271 Vulnerability

#49 2014-09-26 23:27:35

Re: Bash CVE-2014-6271 Vulnerability

#50 2014-09-26 23:43:33

Re: Bash CVE-2014-6271 Vulnerability

Board footer