I know that the routers technically use ash (not full bash) implementation thru Busybox. But are they still vulnerable to the latest "Shellshock" vulnerability?
Topic: Shellshock?
The content of this topic has been archived on 20 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.
Thanks. I would like to know too.
As best as I can tell, it doesn't appear to work on the Busybox implementation of ash:
http://www.theregister.co.uk/2014/09/24 … hell_vuln/
When I try to run:
env X="() { :;} ; echo busted" /bin/sh -c "echo completed"
env X="() { :;} ; echo busted" `which bash` -c "echo completed"
The first comes back "completed" which is the safe output. And the 2nd errors out cuz there isn't even a symlink reference to bash. So .... I **think** what I can tell the OpenWRT implementations are safe. But I hate feeling complacent with the scope of this.
Busybox ash, which is OpenWrts default shell, is not vulnerable to this exploit. Even if you have bash installed on your OpenWrt device it might be only exploitable from the outside if it is also the /bin/sh on your system.
Script languages like PHP, Perl, Lua that invoke system commands usually use "/bin/sh -c 'command'" internally, so if /bin/sh points to /bin/ash or /bin/busybox, the bash vulnerability does not apply to them.
That is what I thought, but wanted to be sure. Looks like we are going to be one of the few distros not vulnerable to this.
Even if you have bash installed on your OpenWrt device it might be only exploitable from the outside if it is also the /bin/sh on your system.
How do noobs like me can check if our installed bash "is also the /bin/sh on their system"?
Script languages like PHP, Perl, Lua that invoke system commands usually use "/bin/sh -c 'command'" internally, so if /bin/sh points to /bin/ash or /bin/busybox, the bash vulnerability does not apply to them.
Again, how do we (noobs) make sure "if /bin/sh points to /bin/ash or /bin/busybox".
Thanks in advance.
(Last edited by oneaty on 25 Sep 2014, 19:16)
ls /bin/sh -l
ls /bin/sh -l
For the noob's records, ssh into your openwrt device and issue the command nebbia88 showed.
In my case, it returns:
root@OpenWrt:~# ls /bin/sh -l
lrwxrwxrwx 1 root root 7 Mar 23 2013 /bin/sh -> busybox
which is exactly what Jow refers to.
Thank you guys
Hey, a load off my mind.
Found all the answers even before I fully understood the problem
Thanks all.
bash is available for OpenWRT and I did have it installed:
root@OpenWrt:~# env X='() { :;} ; echo busted' /bin/bash -c "echo completed"
busted
completed
root@OpenWrt:~#
Will OpenWRT's BASH package get an update to patch this flaw?
It already has: https://github.com/openwrt/packages/com … 4eee5441e3
I was checking on site:
https://shellshocker.net
On #5 it seems like openwrt is vulnerable:
Exploit 5 (CVE-2014-7187)
I ran the following check and replaced "bash" with "ash":
(for x in {1..200} ; do echo "for x$x in ; do :"; done; for x in {1..200} ; do echo done ; done) | bash ||
echo "CVE-2014-7187 vulnerable, word_lineno"
Here is the output:
root@OpenWrt:~# (for x in {1..200} ; do echo "for x$x in ; do :"; done; for x in {1
..200} ; do echo done ; done) | ash ||
> echo "CVE-2014-7187 vulnerable, word_lineno"
ash: syntax error: bad for loop variable
CVE-2014-7187 vulnerable, word_lineno
root@OpenWrt:~#
root@OpenWrt:~# uname -a
Linux OpenWrt 3.3.8 #1 Sat Mar 23 16:49:30 UTC 2013 mips GNU/Linux
root@OpenWrt:~#
I am running:
ATTITUDE ADJUSTMENT (12.09, r36088)
I know it doesn't reference the "ash" shell directly, but scripts using "ash" seems to be vulnerable. Someone might crasft some special code to attack this. What do you all think?
You probably didn't fully understand the scripting syntax of #5. Your output confirms busybox's ash is *not* vulnerable.
Can someone please run the one-liner shellshock_test.sh from https://shellshocker.net/#systemtest and post the results here?
Thanks
-Shellshocker Team
This is from my TP-Link Archer C7 running self compiled trunk. At the risk of stating the obvious, I've got bash installed on my system, although it's not the default shell. The one liner was failing for me last night, but I've repeated the tests again with no issues, although I need to use the -k (insecure) option with curl
The first 4.3.26 bash is untouched by me, but has the RH patches applied while the second is 4.3.27 with just the published gnu patches. Both fail CVE-2014-7186 and I've seen similar on other systems running what should be the same versions of bash (I've upgraded quite a few this week). On my Mac, CVE-2014-7186 with your test, however fails a similar test using the bashcheck script - it seems to depend on the number of EOF used in the test
minounet:> bash --version
GNU bash, version 4.3.26(1)-release (mips-openwrt-linux-gnu)
minounet:> curl -k https://shellshocker.net/shellshock_test.sh| bash
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 2008 100 2008 0 0 4332 0 --:--:-- --:--:-- --:--:-- 4374
CVE-2014-6271 (original shellshock): not vulnerable
CVE-2014-7169 (taviso bug): not vulnerable
CVE-2014-//// (exploit 3 on http://shellshocker.net/): not vulnerable
Segmentation fault
CVE-2014-7186 (redir_stack bug): VULNERABLE
CVE-2014-7187 (nested loops off by one): not vulnerable
bash: shellshocker: command not found
CVE-2014-6278 (Florian's patch): not vulnerable
minounet:> bash --version
GNU bash, version 4.3.27(1)-release (mips-openwrt-linux-gnu)
~
minounet:> curl -k https://shellshocker.net/shellshock_test.sh | bash
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 2008 100 2008 0 0 3788 0 --:--:-- --:--:-- --:--:-- 3810
CVE-2014-6271 (original shellshock): not vulnerable
CVE-2014-7169 (taviso bug): not vulnerable
CVE-2014-//// (exploit 3 on http://shellshocker.net/): not vulnerable
Segmentation fault
CVE-2014-7186 (redir_stack bug): VULNERABLE
CVE-2014-7187 (nested loops off by one): not vulnerable
bash: shellshocker: command not found
CVE-2014-6278 (Florian's patch): not vulnerable
(Last edited by noblem on 1 Oct 2014, 19:31)
Bash from the current github feed, installed from snapshots:
root@jj:~# bash --version
GNU bash, version 4.3.26(1)-release (mips-openwrt-linux-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
root@jj:~# curl -k https://shellshocker.net/shellshock_test.sh | bash
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 2008 100 2008 0 0 3203 0 --:--:-- --:--:-- --:--:-- 3212
CVE-2014-6271 (original shellshock): not vulnerable
CVE-2014-7169 (taviso bug): not vulnerable
CVE-2014-//// (exploit 3 on http://shellshocker.net/): not vulnerable
CVE-2014-7186 (redir_stack bug): not vulnerable
CVE-2014-7187 (nested loops off by one): not vulnerable
bash: shellshocker: command not found
CVE-2014-6278 (Florian's patch): not vulnerable
root@jj:~#
Retested with the latest -28 patch for bash;
minounet:> curl -k https://shellshocker.net/shellshock_test.sh | bash
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 2008 100 2008 0 0 4260 0 --:--:-- --:--:-- --:--:-- 4309
CVE-2014-6271 (original shellshock): not vulnerable
CVE-2014-7169 (taviso bug): not vulnerable
CVE-2014-//// (exploit 3 on http://shellshocker.net/): not vulnerable
CVE-2014-7186 (redir_stack bug): not vulnerable
CVE-2014-7187 (nested loops off by one): not vulnerable
bash: shellshocker: command not found
CVE-2014-6278 (Florian's patch): not vulnerable
All checks are now passed on my system
(Last edited by noblem on 1 Oct 2014, 19:31)
The discussion might have continued from here.