EFW Support

All bash versions are vulnerable. To test for the problem try:
env x='() { :;}; echo vulnerable' bash -c 'echo hello'

My EFW 2.2 rc3 fails this test...but the problem was only discovered yesterday (Sept 24, 2014) so I expect all EFWs are in trouble.

My web server in running on ubuntu 12.04 and there is a Debian patch out already. My guess is Redhat has a patch but someone has to migrate that into the EFW upgrade.

I'll move to 3.0 when the patch is available.

I just checked...the bash version in the endian 3.0.0 (January 28, 2014) release is bash-3.0-20.endian

My old 2.2.rc3 is using 3.00.14 ... so it's close to the "endian current" version.

Since the current Redhat release appears to be 4.3.24-2 there may be a bunch of testing required to get from 3.0 to 4.3(patched) before an upgrade can be provided.

Is there any way we can get a quick patch into bash-3.0 so our firewalls don't get owned?

I am not positive, but I believe the "hacker" would have to all ready have a SSH user account. So if your like me and don't leave SSH open to the web, I am restively certain that there isn't a threat. But again, I am not positive at this point, and intend to do some research to verify the specific's of the vulnerability.

Does anybody here have any details of the vulnerability?

Google "bash ‘Shellshock’"

and check out CVE-2014-6271 and CVE-2014-7169

...it sounds like it's all over the place...here is a short list:

httpd    CGI scripts are likely affected by this issue: when a CGI script is run by the web server, it uses environment variables to pass data to the script. These environment variables can be controlled by the attacker. If the CGI script calls Bash, the script could execute arbitrary code as the httpd user. mod_php, mod_perl, and mod_python do not use environment variables and we believe they are not affected.

Secure Shell (SSH)    It is not uncommon to restrict remote commands that a user can run via SSH, such as rsync or git. In these instances, this issue can be used to execute any command, not just the restricted command.
dhclient    The Dynamic Host Configuration Protocol Client (dhclient) is used to automatically obtain network configuration information via DHCP. This client uses various environment variables and runs Bash to configure the network interface. Connecting to a malicious DHCP server could allow an attacker to run arbitrary code on the client machine.

CUPS    It is believed that CUPS is affected by this issue. Various user supplied values are stored in environment variables when cups filters are executed.
sudo    Commands run via sudo are not affected by this issue. Sudo specifically looks for environment variables that are also functions. It could still be possible for the running command to set an environment variable that could cause a Bash child process to execute arbitrary code.

Firefox    We do not believe Firefox can be forced to set an environment variable in a manner that would allow Bash to run arbitrary commands. It is still advisable to upgrade Bash as it is common to install various plug-ins and extensions that could allow this behavior.

Postfix    The Postfix server will replace various characters with a ?. While the Postfix server does call Bash in a variety of ways, we do not believe an arbitrary environment variable can be set by the server. It is however possible that a filter could set environment variables.

...my guess is that it's not something that can be ignored.

There is an active discussion on reddit:
/r/netsec/comments/2hehgk/cve20147169_bash_fix_incomplete_still_exploitable/


Apparently the partial fix is a change to parse.y
...............................................................................................................

*** ../bash-20140912/parse.y   2014-08-26 15:09:42.000000000 -0400
--- parse.y   2014-09-24 22:47:28.000000000 -0400
***************
*** 2959,2962 ****
--- 2959,2964 ----
    word_desc_to_read = (WORD_DESC *)NULL;
  
+   eol_ungetc_lookahead = 0;
+
    current_token = '\n';      /*  */
    last_read_token = '\n';
......................................................................................................................

This allows a pass on the first test but has other problems...some of which EFW will not have because it lives in a very constrained environment (my ubuntu webserver however is still not secure). It might be worth starting the patch admin process with the change to parse.y and back fill when more understanding of the problem evolves.

I've not understood, patch isn't available so what I have to do? block ssh?

It is not just SSH that's affected.

Bash provides a library that is used widely in linux for anything that needs parsing/scripting. For example if your EFW server is doing DHCP (a basic routing function) that may be compromised. I'm just guessing but anything automated (like updates, antivirus, emailing logs, CUPS printing of alerts, snort traffic monitoring) uses parsing/scripting provided by the bash library and may be compromised.

As I said before bash is everywhere and the number of things affected is not clearly understood.

This is a bit alarmist but: if you have mission critical applications you may need to turn off your EFW. To stay in business replace your linux router with a non-linux router until this thing is fixed (i.e. for SOHO swap-in a Dlink from Bestbuy...for corporate networks ask Cisco to give you a solution).

This is not heartbleed...this is worse.

I just ran the test against a 2.5.1 and it reported that it is vulnerable, while 2.5.2 reports that it is not. So I'm wondering - would this only be an issue in cases where either A) I have remote administration enabled; or B) only a threat from inside my green zone can initiate an attack? If I understand this correctly, a publicly accessible web server exhibits this vulnerability whereas one that is behind a firewall does not. Am I understanding this correctly?

What version of bash (bash --version) is running on EFW-2.5.2?

2.2.rc3 reports "version 3.00.14(1)-release" and if you unpack the SRPM from EFW-3.0.0 the bash version is 3.0.20
so 14 < "2.5.2 version" < 20 and it should run fine on all EFWen.

*** Please: those in charge of upgrades can you make the 2.5.2 version of bash available as an upgrade for all EFWen? ***
(given that it is confirmed the stock 2.5.2 passes the vulnerability test)

On the "what do I have to turn off to be safe" the answer is anything that uses bash scripts or anything that embeds the bash parsing algorithm - which is pretty much everything. Every feature you turn on expands the attack surface.

As for where the threats come from - anything connected to the internet is at risk until the hackers get into your network - after that every every 'nix inside is at risk (including your Apple laptop).

I'm not waiting any longer - I've pulled the green link from both my EFW-2.2.rc3 and I'm running on my two Dlink's (I have 4 IP addresses) until there is a patch available.

I have serial (COM1) consoles so when a patch is available I'll upgrade to 3.0.0-patched before I reconnect my EFWen to my network.

I don't see how they could compromise our Endian boxes.

I have a 2.5.2 box and the test shows it's vulnerable.

root@gw1:~ # bash --version
bash --version
GNU bash, version 3.00.14(1)-release (i686-redhat-linux-gnu)
Copyright (C) 2004 Free Software Foundation, Inc.
root@gw1:~ # env x='() { :;}; echo vulnerable' bash -c 'echo hello'
vulnerable
hello




Gotta be a rpm we can install to upgrade, right?

What's version of Red Hat is 2.5.2. based on?  God, the support for this community version is pathetic.

same here mate i too have the same version 2.52  with bash 3.00.14 . i just came  to know that the paid support team have fixed  the issue
with some security update.

Same here with Endian Community 3.0:

# bash --version
GNU bash, version 3.00.14(1)-release (i686-redhat-linux-gnu)
Copyright (C) 2004 Free Software Foundation, Inc.

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


Jack

# cat /etc/VERSION
3.0.devel

Hello to everyone.

I can confirm that my 2.5.2 are vulnerable, as someone said.

I need a confirmation proposing this as temporary solution.

If I don't open any service on my firewall on the net, all the requests will be rejected and the firewall won't suffer any weakness.

Does this sentence make any sense?

If the weakness affected the bash and I don't open any service to it (CGI and something like that), the security attacks can happen only from my green interface, where usually the SSH is enabled.

Thanks in advance for your support.

Marco

Marco, i don't know if are you (or we) safe: since the bug can be exploited by any process that uses environment variables, even postgrey or spamassassin could set one of the email headers into an env variable, or squid could set one of the http headers like cache control into the variable. I don't know why would them, but they can.

Jack

The Shellshock attack starts on the internet (Red side) and allows the attacker to punch through the EFW into your network (Green side).

I have left my Red side connected because I want my ISP to continue to update my IP address.

I disconnected my Green side because I don't want the bad guys to get into my servers. I hope that since my EFW "connects to nothing" it will be uninteresting to the bad guys and they will pass me by...but hope is a very bad security policy.

I have a COM1 console so I can watch for unusual activity and upgrade my EFW once a patch is available. My servers are now connecting to the internet via Dlink which is not unix based.

If we don't see a patch soon I will disconnect my Red side and wipe my EFW box to sterilize any infection it might have acquired. I'll start over with a fresh EFW load once the Community has a fix...or perhaps find an alternative to EFW that has a fix.

...more on alternatives to EFW:

pfSense is based on FreeBSD and does not install Bash so is NOT vulnerable.
...if you add some product that depends on bash you may be in trouble - so don't


Not so comforting for:

Smoothwall (popular IPcop variant) based on RedHat uses bash and does not have a patch (EFW situation).

Untangle based on RedHat uses bash and promises that bash is not exposed on Red but will be patching (in the future).

Astaro Security Gateway (now Sophos) based on SUSE uses bash and promises that bash is not exposed on Red but will include the SUSE patch when is comes available.

I have 12 EFW boxes at various locations, no issues.  Been keeping an eye on them.

Tried pfsense for a few months just recently, went back to EFW.  EFW is just easy to deploy and configure.  Pfsense is definitely more powerful and way more people using it and supported from the community.

I haven't patched the system yet, but the best way to fix this should be:

-Make a "devel box" of the same Endian version you use on production. I was able to compile a lot of things with Endian ISO + Devel ISO, without really knowing what exact CentOS version Endian is. A virtual machine for example.
-Install devel ISO rpms on that box.
-Check your bash version: bash --version
   "GNU bash, version 3.00.14(1)-release (i686-redhat-linux-gnu)"
-Search the patches for that bash version (3.00, the last number is the patch level).
-Go to: https://ftp.gnu.org/pub/gnu/bash/bash-3.0-patches/ and download the patches the system need.
-Apply the patches to bash source rpm.
-Recompile and rpmbuild the patched .rpm package for bash.
-Install that .rpm on every Endian box. You don't need development tools for that, you just install the plain rpm on your endians.

You can blame about community and Endian team, but at least you are able to recompile many things.
I know this procedure is too general, but this is the normal way to update a system without any paid support.

If I have time I'll try to make the new .rpm some some versions.

Just a note, when patching bash, if endian bash is patch level 14, apply patches from 15 to the latest.

I don't think a thousand EFW enthusiasts putting a thousand different "found" patches into their own firewall is a good thing.

Many of us are able to rebuild from SRPMs but if something goes wrong with 2.2-rc3-dean I no longer have a community that can support me...and Eric is on his own with 2.2.5-eric...and Mr. Kroket is on his own with 3.0.0-mrkroket.

I would really like whoever does "EFW version control" to pick a fix and make it available to the update process.

That way all of us with 3.0.0-offical-bash-patch can figure out if it works...and bitch if it doesn't...but bitch as a "community".

...by the way I'm not volunteering...I'm a leecher not a seeder.   

I'm pretty sure there would be like 2 patches, top!

If you want a centralized update support pay for it.
http://.endian.com/2014/09/26/endian-s-systems-protected-from-shellshock/
They already sent the patch out. If you don't want to pay it then you only have community support.

And this means two options:
  -Recompile the sources with patches by yourself.
  -Trust some bash.rpm some other user release.

It's the beauty of opensource stuff, you can fix it... if you know how to. On a closed source env. you won't be able to fix it.

By the way, Endian is a fork from IPCop. So forking is very usual on Linux environment.
If you don't like it, good, if you like it, good too.

I'm sure someone will figure this out soon.  I'll play with it tomorrow when I get some time.  Just need to find the correct RPM and it should be fairly simple.

Okay this sort of works:
=================

What are we running?:
-----------------------------
# bash --version
GNU bash, version 3.00.14(1)-release (i686-redhat-linux-gnu)

Funky install
----------------
# smart install http://public-yum.oracle.com/repo/EnterpriseLinux/EL4/latest/i386/getPackage/bash-3.0-27.0.2.el4.i386.rpm
# rpm -Uhv bash-3.0-27.0.2.el4.i386.rpm

Did we upgrade it? (Yes)
-------------------------------
# bash --version
GNU bash, version 3.00.15(1)-release (i686-redhat-linux-gnu)

Does it pass the test? (Yes. It's fixed)
------------------------------------------------
#env x='() { :;}; echo vulnerable' bash -c 'echo hello'
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
hello

Notes:
--------
1. The "smart install" fails because there is no DSA key stored in EFW for the Oracle repository ...but it fetched the RPM

2. The "rpm -U" cannot fetch the file from Oracle (you get an "import read failed(-1).")

3. "rpm -U" will however install from the local copy retrieved from the "smart install"

4. bash 3.0 aligns with RedHat Version 4. (3.2 is RH5, 4.1 is RH6, 4.2 is RH7)
   https://access.redhat.com/articles/1200223
   ...but that RH4 is no longer supported by RH so that's why we have to get it from Oracle.

5. The downloaded bash is for "Red Hat Enterprise Linux 4" (EL4) but it should be the same for all RH4 variants (??).

6. Review the source at https://oss.oracle.com/el4/SRPMS-updates/bash-3.0-27.0.2.el4.src.rpm

7. This was tested on 2.2.rc3 only - your experience may vary

...so I volunteered...now you can bitch at me...someone please check my work before it corrupts all of your EFWen.

Great work!

It works on 2.5.2 and 2.4.1!

Just tried it on 2.5.1. Seems working like charm! :)
Thank you!

Great, it works like a charm in Endian community 3.0 too!

Thank you!

Jack

Great Dean , thanks   installed and tested on  2.52 .

me too, thanks

I saw that Oracle patch, but I don't like to add rpm's from vanilla redhat. To fetch things you can also use curl -O <URL>
The thing is sometimes endian uses strange paths for many files, they tweaked many rpm sources to point to different paths.
But if you don't see anything wrong it's ok. Good work finding it, now we have bash-3.0-deanstyles version.

Just an added thing. Shellshock bug it's more than this line, there are at least 4 tests you must pass (see http://en.wikipedia.org/wiki/Shellshock_(software_bug) ):
CVE-2014-6271 Test 1: Expected result: Do not see vulnerable on screen.
CVE-2014-7169 Test 2: Expected result: Do not see the current date on screen. No such file or directory.
CVE-2014-7186 Test 3: Expected result: empty output.
CVE-2014-7187 Test 4: Expected result:
If bash fails on one of them, you are still vulnerable to Shellshock

There is also an script around there to bashcheck:
https://github.com/hannob/bashcheck/blob/master/bashcheck (https://github.com/hannob/bashcheck/blob/master/bashcheck)

I'm rebuilding the RPM's for bash, using the original Endian bash package, just adding the patches.
I'm on Endian 2.4.0, and it succesfully passed the 4 tests. Once I finished packaging and reviewing, I'll rebuild it on 2.5.2 and 3.0.0, probably is the very same package on all 3.
I attached a screen of the actual result on my compiled bash:
http://imgur.com/S9xp2OH (http://imgur.com/S9xp2OH)

Now that I saw your Oracle SRC package, I'll try to add another patches that I saw on your package but I didn't see on endian's bash. Maybe they are other patches not related to Shellshock but useful.

Regards.

I can confirm too that Oracle bash update 27.0.3 fixes the 4 bugs.

Steps to install Oracle bash:
To all, please note that if you install Oracle bash, there is a new update (27.0.3), deanstyles pointed out the prior version (.2).
It's dated 26-Sep-2014 15:42

Test results:
Tested en Endian 2.4.0 and Endian 2.5.1

I reviewed Oracle bash sources versus Endian bash sources, and the only noticeable change between their SPEC files are those symlinks files:
ln -sf bash ./bin/csh
ln -sf bash ./bin/tcsh
The good news is that they are already created on Endian, so there is no problem of missing files.

Anyways I'll be rebuilding the endian's bash package, just in case. I know everybody trusts Oracle more than a single person.

Sorry folks the white hatters are finding more problems with bash:
https://shellshocker.net/

From what I can tell the new problems are harder to exploit and not as valuable to the "for profit" black hats.

The economics may keep us safe but there will be one last patch (in weeks?) when the dust clears. At that time I'll post a "how-to". If anything really nasty appears I'll post immediately.

Watch for the signs,
    Dean Styles, CISSP

But actual patch passes all these tests, so there aren't more public vulnerabilities for now:

root@Firewall:~ # ./shellshock_test.sh
CVE-2014-6271 (original shellshock): not vulnerable
bash: shellshocker: command not found
CVE-2014-6278 (Florian's patch): 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

Seems like they've upgraded the tester, now it looks like:

root@Firewall:~ # ./shellshock_test.sh
CVE-2014-6271 (original shellshock): not vulnerable
bash: line 16: 30605 Segmentation fault      bash -c "f() { x() { _;}; x() { _;} <<a; }" 2>/dev/null
CVE-2014-6277 (segfault): VULNERABLE
CVE-2014-6278 (Florian's patch): not vulnerable
CVE-2014-7169 (taviso bug): not vulnerable
CVE-2014-7186 (redir_stack bug): not vulnerable
CVE-2014-7187 (nested loops off by one): not vulnerable
CVE-2014-//// (exploit 3 on htp://shellshocker.net/): not vulnerable

I tried:


why "command not found" ?

another error:

Anyway to uninstall this patch? Ever since i installed it I can not create any new GW2GW OpenVPN connections.

TAP interfaces got mixed up somehow, had to delete all the tunnels and re-create them. Thanks JohnBoy!