Welcome, Guest. Please login or register.
Did you miss your activation email?
Friday 15 November 2024, 05:57:58 am

Login with username, password and session length

Download the latest community FREE version  HERE
14255 Posts in 4377 Topics by 6515 Members
Latest Member: hulteends
Search:     Advanced search
+  EFW Support
|-+  Support
| |-+  General Support
| | |-+  Patch for bash ‘Shellshock’ Vulnerability (CVE-2014-6271,CVE-2014-7169) - when?
0 Members and 2 Guests are viewing this topic. « previous next »
Pages: 1 [2] 3 Go Down Print
Author Topic: Patch for bash ‘Shellshock’ Vulnerability (CVE-2014-6271,CVE-2014-7169) - when?  (Read 167372 times)
boanergos
Jr. Member
*
Offline Offline

Posts: 5


« Reply #15 on: Monday 29 September 2014, 07:31:33 pm »

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
Logged
jack.mauro
Jr. Member
*
Offline Offline

Posts: 4


« Reply #16 on: Monday 29 September 2014, 10:55:59 pm »

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
Logged
deanstyles
Full Member
***
Offline Offline

Posts: 12


« Reply #17 on: Tuesday 30 September 2014, 12:18:43 am »

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.
Logged
deanstyles
Full Member
***
Offline Offline

Posts: 12


« Reply #18 on: Tuesday 30 September 2014, 06:40:30 am »

...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.
Logged
TheEricHarris
Full Member
***
Offline Offline

Posts: 86


« Reply #19 on: Tuesday 30 September 2014, 06:45:38 am »

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.
Logged
mrkroket
Hero Member
*****
Offline Offline

Posts: 495


« Reply #20 on: Tuesday 30 September 2014, 07:38:27 am »

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.
Logged
mrkroket
Hero Member
*****
Offline Offline

Posts: 495


« Reply #21 on: Tuesday 30 September 2014, 07:43:22 am »

Just a note, when patching bash, if endian bash is patch level 14, apply patches from 15 to the latest.
Logged
deanstyles
Full Member
***
Offline Offline

Posts: 12


« Reply #22 on: Tuesday 30 September 2014, 08:43:27 am »

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.   
Logged
mrkroket
Hero Member
*****
Offline Offline

Posts: 495


« Reply #23 on: Tuesday 30 September 2014, 09:00:27 am »

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.
Logged
mrkroket
Hero Member
*****
Offline Offline

Posts: 495


« Reply #24 on: Tuesday 30 September 2014, 09:02:35 am »

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.
Logged
TheEricHarris
Full Member
***
Offline Offline

Posts: 86


« Reply #25 on: Tuesday 30 September 2014, 09:03:32 am »

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.
Logged
deanstyles
Full Member
***
Offline Offline

Posts: 12


« Reply #26 on: Tuesday 30 September 2014, 12:06:42 pm »

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.
Logged
TheEricHarris
Full Member
***
Offline Offline

Posts: 86


« Reply #27 on: Tuesday 30 September 2014, 01:18:52 pm »

Great work!

It works on 2.5.2 and 2.4.1!
Logged
noita
Jr. Member
*
Offline Offline

Posts: 2


« Reply #28 on: Tuesday 30 September 2014, 02:55:43 pm »

Just tried it on 2.5.1. Seems working like charm! Smiley
Thank you!
Logged
jack.mauro
Jr. Member
*
Offline Offline

Posts: 4


« Reply #29 on: Tuesday 30 September 2014, 03:25:23 pm »

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

Thank you!

Jack
Logged
Pages: 1 [2] 3 Go Up Print 
« previous next »
Jump to:  

Page created in 0.113 seconds with 19 queries.
Powered by SMF 1.1 RC2 | SMF © 2001-2005, Lewis Media Design by 7dana.com