Bash "shellshock" CVE-2014-6271 CVE-2014-7169 - rated 10 !

ilesterg · 09-26-2014, 08:31 AM

Quote:

Originally Posted by Toofle

I'm on debian: SID atm. And when i try the command:

Code:

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

If your system is compromised you should be able to see "vulnerable" and "this is a test".
However. I can only see the part where it echo's "this is a test".

If the bash shell is patched it should give this error.

bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test

But it doesn't!

I have updated bash to latest version. Anyone have a clue?

Are you lost, my friend?

Toofle · 09-26-2014, 08:31 AM

ilesterg · 09-26-2014, 08:33 AM

Quote:

Originally Posted by Toofle

Yes

http://www.linuxquestions.org/questi...k-4175519998/?

ilesterg · 09-26-2014, 08:35 AM

Hi all, I just want to clarify, only bash is affected, right? and not ksh, tcsh and zsh?

Toofle · 09-26-2014, 08:36 AM

Quote:

Originally Posted by suicidaleggroll

That's what it's supposed to do. A broken system would print

Code:

vulnerable
this is a test

That

Code:

bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'

is it catching the vulnerability.

What if it only prints

Code:

this is a test

I updated and upgraded. And dist-upgraded. But none of these methods seem to help me. Any clues ?

Btw: I'm using debian: Sid

Linux_Kidd · 09-26-2014, 09:19 AM

the fixes i tried (.1 and .2 ver of latest bash on CentOS 6final)
both did not behave like this

Code:

The patch used to fix this flaw, ensures that no code is allowed after the end of a bash function. So if you run the above example with the patched version of bash, you should get an output similar to:

 $ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
 bash: warning: x: ignoring function definition attempt
 bash: error importing function definition for `x'
 this is a test

all i got back was/is "this is a test"

so, it looks like what was compiled and released was not what they used when they posted at https://securityblog.redhat.com/2014...ection-attack/

ntubski · 09-26-2014, 09:22 AM

Quote:

Originally Posted by BartMan__X

Code:

root@BWS-NET:~# env X='() { :;}; echo' /bin/cat /etc/passwd; echo 'Welcome to he Simple ShellShock Tester By Svieg';echo 'Your infos are at risk';

That's not a vulnerability, it's really the same as just

Code:

/bin/cat /etc/passwd
echo 'Welcome to he Simple ShellShock Tester By Svieg'
echo 'Your infos are at risk'

Obviously /bin/cat /etc/passwd should only work as root.

suicidaleggroll · 09-26-2014, 09:55 AM

The only time I saw that is when I was running on a system where "bash" wasn't really bash, it was a symlink to busybox or sh or something else.

edit: I just installed x.2 of the CentOS bash fix, now I just get "this is a test" on the first one, and

Code:

date
Thu Sep 25 15:22:19 MDT 2014

For the second.

I was under the impression that if you received a date on the second test it was still vulnerable, so is this not yet fixed? I understand the first test fully, but I don't really "get" the second test, so I can't say what the proper behavior should be.

corbis_demon · 09-26-2014, 11:25 AM

CVE-2014-7169, the additional vulnerability has been fixed. You can find the patch here. This is the result of a test exploit I ran on a patched and recompiled version of bash:

Code:

user@host:~$ env X='() { (a)=>\' bash -c "file echo vulnerable; cat file"

bash: X: line 1: syntax error near unexpected token `='
bash: X: line 1: `'
bash: error importing function definition for `X'
echo: ERROR: cannot open `echo' (No such file or directory)
vulnerable: ERROR: cannot open `vulnerable' (No such file or directory)
cat: file: No such file or directory

suicidaleggroll · 09-26-2014, 11:50 AM

So my CentOS and Debian system seem good now:

Code:

$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
this is a test
$ env X='() { (a)=>\' sh -c "echo date"; cat echo
date
cat: echo: No such file or directory

However I'm not seeing the patch to fix the second problem on the bash software page:
http://ftp.gnu.org/gnu/bash/bash-4.3-patches/

025 only fixes the first vulnerability.

Linux_Kidd · 09-26-2014, 11:54 AM

Quote:

Originally Posted by suicidaleggroll

So my CentOS and Debian system seem good now:

Code:

$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
this is a test
$ env X='() { (a)=>\' sh -c "echo date"; cat echo
date
cat: echo: No such file or directory

However I'm not seeing the patch to fix the second problem on the bash software page:
http://ftp.gnu.org/gnu/bash/bash-4.3-patches/

025 only fixes the first vulnerability.

as example, release 15.el6_5.2 for bash 4.1.2 fixes both issues from what i see.

this page http://ftp.gnu.org/gnu/bash/bash-4.3-patches/ doesnt seem to list the files they used on 25Sep2014. i suspect if the build date is not 25Sep2014 or later than you dont have the latest fixed version. i guess you are looking for -026

ntubski · 09-26-2014, 11:57 AM

Quote:

Originally Posted by suicidaleggroll

So my CentOS and Debian system seem good now:

Code:

$ env X='() { (a)=>\' sh -c "echo date"; cat echo
date
cat: echo: No such file or directory

You should use bash instead of sh on Debian (derived) systems, otherwise you aren't testing bash.

Quote:

Originally Posted by Postmodern

a better test

Code:

env X='() { (a)=>\' bash -c "echo echo vuln"; [[ "$(cat echo)" == "vuln" ]] && echo "still vulnerable :("

From https://twitter.com/taviso/status/514887394294652929

suicidaleggroll · 09-26-2014, 12:05 PM

Oops, I just copied and pasted, didn't notice it was running sh instead of bash. Either way, on both my CentOS and Debian systems sh is symlinked to bash, so the result is the same.

For the better test:

Code:

$ env X='() { (a)=>\' bash -c "echo echo vuln"; [[ "$(cat echo)" == "vuln" ]] && echo "still vulnerable :("
echo vuln
cat: echo: No such file or directory

Linux_Kidd · 09-26-2014, 12:44 PM

and i am baffled as to why "yum check-update --security" didnt return _5.1 or _5.2 to me.
was the package not flagged with security in the repo?

many of my patching programs do regular security patching (package installs). thus a "yum update --security" would not have worked here.

anyone ??

unSpawn · 09-26-2014, 12:54 PM

I've merged the two main threads on the subject and stickied it.
Please keep the general discussion here, thanks.