Patch for bash ‘Shellshock’ Vulnerability (CVE-2014-6271,CVE-2014-7169) - when?

[Guest]

[deanstyles]

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.

[deanstyles]

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?

[juddyjacob]

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?

[deanstyles]

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.

[deanstyles]

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.

[mmiat]

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

[deanstyles]

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.

[tauntingzombies]

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?

[deanstyles]

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).

[deanstyles]

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.

[TheEricHarris]

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?

[TheEricHarris]

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

[deni1738]

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.

[jack.mauro]

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

[jack.mauro]

Same here with Endian Community 3.0:
[...]
Jack

# cat /etc/VERSION
3.0.devel