[SRU] firehol locks down Feisty & Gusty systems

Same here. FireHOL is unable to configure iptables correctly in feisty (everything is OK in both dapper and edgy). With FireHOL's default configuration it returns following errors and it blocks internet connection completely:
--------------------------------------------------------------------------------
ERROR : # 1.
WHAT : A runtime command failed to execute (returned error 2).
SOURCE : line INIT of /etc/firehol/firehol.conf
COMMAND : /sbin/iptables -t filter -A out_world_all_c1 -m state '' --state NEW\,ESTABLISHED -j ACCEPT
OUTPUT :

Try `iptables -h' or 'iptables --help' for more information.
Bad argument `'

--------------------------------------------------------------------------------
ERROR : # 2.
WHAT : A runtime command failed to execute (returned error 2).
SOURCE : line INIT of /etc/firehol/firehol.conf
COMMAND : /sbin/iptables -t filter -A in_world_all_c1 -m state '' --state ESTABLISHED -j ACCEPT
OUTPUT :

Try `iptables -h' or 'iptables --help' for more information.
Bad argument `'

--------------------------------------------------------------------------------
ERROR : # 3.
WHAT : A runtime command failed to execute (returned error 2).
SOURCE : line INIT of /etc/firehol/firehol.conf
COMMAND : /sbin/iptables -t filter -A out_world_irc_c2 -p tcp --sport 32768:61000 --dport 6667 -m state '' --state NEW\,ESTABLISHED -j ACCEPT
OUTPUT :

Try `iptables -h' or 'iptables --help' for more information.
Bad argument `'

--------------------------------------------------------------------------------
ERROR : # 4.
WHAT : A runtime command failed to execute (returned error 2).
SOURCE : line INIT of /etc/firehol/firehol.conf
COMMAND : /sbin/iptables -t filter -A in_world_irc_c2 -p tcp --sport 6667 --dport 32768:61000 -m state '' --state ESTABLISHED -j ACCEPT
OUTPUT :

Try `iptables -h' or 'iptables --help' for more information.
Bad argument `'

--------------------------------------------------------------------------------
ERROR : # 5.
WHAT : A runtime command failed to execute (returned error 2).
SOURCE : line INIT of /etc/firehol/firehol.conf
COMMAND : /sbin/iptables -t filter -A out_world_ftp_c3 -p tcp --sport 32768:61000 --dport ftp -m state '' --state NEW\,ESTABLISHED -j ACCEPT
OUTPUT :

Try `iptables -h' or 'iptables --help' for more information.
Bad argument `'

--------------------------------------------------------------------------------
ERROR : # 6.
WHAT : A runtime command failed to execute (returned error 2).
SOURCE : line INIT of /etc/firehol/firehol.conf
COMMAND : /sbin/iptables -t filter -A in_world_ftp_c3 -p tcp --sport ftp --dport 32768:61000 -m state '' --state ESTABLISHED -j ACCEPT
OUTPUT :

Try `iptables -h' or 'iptables --help' for more information.
Bad argument `'

--------------------------------------------------------------------------------
ERROR : # 7.
WHAT : A runtime command failed to execute (returned error 2).
SOURCE : line INIT of /etc/firehol/firehol.conf
COMMAND : /sbin/iptables -t filter -A in_world_ftp_c3 -p tcp --sport ftp-data --dport 32768:61000 -m state '' --state ESTABLISHED\,RELATED -j ACCEPT
OUTPUT :

Try `iptables -h' or 'ipt...

OK, I'll take Lukas' message as a confirmation;-)

I'll take too Lukas' message as a confirmation;-)

Ditto on my machine running feisty.

See #90646: firehol does not work with bash 3.2:-(

I'd really like to see this get fixed.. Any news?

#90646 is a duplicate of this bug report. Copying my comments there:

What my boss worked out was the following:

Grab the "bash" file from /bin on a Edgy (or dapper) box/install.

Rename this to bash31 and move to /bin on your Feisty box.

Then change the first line of your firehol script (/sbin/firehol or /usr/sbin/firehol) to reflect bash31 as opposed to bash.

Ugly, but it works :(

I've configured firehol with dansguardian (http://ubuntuforums.org/showthread.php?t=207008) and changed the /sbin/firehol script to use bash31. I can now start firehol without errors but the dansguardian/firehol/tinyproxy configuration doesn't work ; it works if I set firefox to use directly tinyproxy. So the transparent proxy is broken...
Here is the firehol.conf:

iptables -t filter -I OUTPUT -d 127.0.0.1 -p tcp --dport 3128 -m owner ! --uid-owner dansguardian -j DROP

transparent_squid 8080 "root root"

interface any world
policy drop
protection strong
client all accept
server cups accept

A solution that doesn't involve copying bash31 from an edgy system is as follows:

sudo vi /lib/firehol/firehol (replace vi with you editor of choice)
and replace all %q strings with %b.

This is what they've done in gentoo to solve the problem.

Will we be getting a security fix for this. A broken firewall
is about as bad as it gets from a security point of view.

From memory, Firehol locks down the system totally as a result of this bug, so it shouldn't be too critical a problem (unless someone disables it). The fix from scottmuz sounded good.

jMehdi, can you check that dansguardian etc are installed and working ok as well? Possbly, check your log files?

Hi!
I tried both use bash 3.1 and replace %q strings with %b and none of the workarounds solved the problem.
FireHOL even appears to be ok, without present error messages, but the firewall rules aren't correctly implemented.
I read somewhere a post of Costa Tsaousis (FireHOL author) stating that the replace method generates other problems.
I really surprised that I made a fresh install of Ubuntu 6.10 Server, apt-get update / apt-get upgrade, then apt-get install firehol and even using a very simple firehol.conf the firewall doesn't work correctly...

Hi Moso, your problem is not related to this one, this is a Feisty only problem (7.04) I would guess that it's a problem with your configuration. I'd suggest reinstalling a clean version of Firehol, and submit a support request on the forums, or through the answer system.

Hi Johnathon! :)

I spend an entire day trying to make FireHOL works with Ubuntu Feisty (7.04) without sucess.

Later, I tried everything from scratch, but this time using Ubuntu Edgy (6.10) and faced the same problems.

I will redo all from beginning, with Edgy (6.10) and later I post here the results.

Moso: do you want to email me directly the results? <email address hidden>

Hi Johnathon! :)

I want to be sure that I the problems are really related to this bug.

I will redo everything, in both 6.10 and 7.04 but this time using this simple iptables script ( http://wiki.ubuntu-br.org/ConfigurandoFirewall ) to see if all will work as expected. This way I want to eliminate all other possible problems of hardware/software before install FireHOL and try one or two simple firehol.conf.

As soon as possible I will email you the results.

Hi Johnathon! :)

I have success running FireHOL on Feisty using bash from Edgy, version 3.1.17(1)-release.

Copying bash from Edgy to /bin with name bash31, editing /sbin/firehol/firehol and /lib/firehol/firehol to use /bin/bash31 all firewall rules were implemented correctly.

I was still having crazy problems but after a lot of headache I discover that when firehol runs it clears all iptables rules.

As I am using a DSL pppoe connection, I discovered that a rule in /etc/ppp/ip-up.d/0clampmss were discarded and some things worked others don't.

By manually running /etc/ppp/ip-up.d/0clampmss after run firehol everything begins to work correctly.

Hello, glad you've got it working :)

Can you open a new bug regarding the DSL problem, targeting the firehol package please?

I don't think that this is a bug.

Maybe FireHOL has a way of work with the MSS clamp. I need to do more research... ;)

Apparently fixed upstream yesterday:

http://sourceforge.net/tracker/index.php?func=detail&aid=1607442&group_id=58425&atid=487692

where Costa says: "This issue has been fixed in v1.253, currently in the CVS."

I quickly mucked about trying to patch the code, but failed miserably. So an update to the Ubuntu package would be much appreciated. :)

for those in a hurry, the package with edgy's bash can be found in the following URL:

http://packages.ubuntulinux.org/cgi-bin/download.pl?arch=i386&file=pool%2Fmain%2Fb%2Fbash%2Fbash_3.1-5ubuntu3_i386.deb&md5sum=84c070bf7168e8f4b3d57f6d9a99af41&arch=i386&type=main

Open the package in file roller or whatever suits your fancy, open data.tar.gz and unpack /./bin/bash (in fileroller you must first double click on the "." though that doesn't seem to make sense). Then follow the instructions from a previous comment ( https://bugs.launchpad.net/ubuntu/+source/firehol/+bug/78017/comments/7 ) by Johnathon:

Grab the "bash" file from /bin on a Edgy (or dapper) box/install.

Rename this to bash31 and move to /bin on your Feisty box.

Then change the first line of your firehol script (/sbin/firehol or /usr/sbin/firehol) to reflect bash31 as opposed to bash.

Ugly, but it works :(

for non-i386 users though : http://packages.ubuntulinux.org/edgy/base/bash

my workaround was to edit /lib/firehol/firehol and replace the line #4626:

#local -a state_arg=("-m" "state" "${statenot}" "--state" "${state}" )

with:

local -a state_arg=("-m" "state" "--state" "${statenot}${state}" )

I think this change doesn't have any collateral effect, but I'm not completely sure since I'm not a bash guru (as you may have noticed :)

I got around by doing the %q => %b replacement and adding execute-permission to file /lib/firehol/firehol (no other bash needed):

sed 's/%q/%b/g' /lib/firehol/firehol > TMPFILE && mv TMPFILE /lib/firehol/firehol
chmod 744 /lib/firehol/firehol

my firehol.conf exactly like jMehdi's above I have been testing some good and some bad sites => seems good!

Just few cents:

1. work around from austin DID work for me
2. Don't forget to change START_FIREHOL to YES in file /etc/default/firehol . It is not reported if it is set to NO, leaves you guessing what is going on.
3. shouldn't there be a "status" for /etc/init.d/firehol ? /sbin/firehol handles it !

This is solved in FireHOL R5 v1.255. A new package should be built, as a non-functioning firewall is a major concern.
http://firehol.sourceforge.net/

We The next stage (according to Bugsquad list) is for someone to generate a debdiff. I will ask for help (mentoring on how to) on the bugsquad IRC channel or list when I get round to it. If anyone has some spare time, and knows enough about linux to be able to, feel free to go ahead and upload it to the bug ticket.

Hello,

I created a debdiff between the .dsc of ubuntu's repository version(1.231-7) and the new upstream version that I packaged.

Unfortunately, Upstream Version Freeze for Gutsy was in mid-August. In the meantime I'd encourage you to work with the Debian maintainer to get the new version uploaded so it can be sync'ed into Hardy Herron (Gutsy +1).

Can you advise on how to do this?

----- "Scott Kitterman" <email address hidden> wrote:
> Unfortunately, Upstream Version Freeze for Gutsy was in mid-August.
> In
> the meantime I'd encourage you to work with the Debian maintainer to
> get
> the new version uploaded so it can be sync'ed into Hardy Herron
> (Gutsy
> +1).
>
> --
> firehol no longer starts on Feisty
> https://bugs.launchpad.net/bugs/78017
> You received this bug notification because you are a direct
> subscriber
> of a duplicate bug.

I don't think upstream cares so much yet because last time I checked the bug doesn't exist there (this behaviour is dependant on the combination of older versions of firehol and recent versions of certain core packages, which debian (at least etch) hasn't updated to yet but ubuntu has)

The way I've fixed it on my affected systems (1 feisty, 1 gutsy) is simple, but we need a fix in the package:

download latest firehol
run (as root) get-iana.sh and answer yes to saving the list to /etc/firehol/RESERVED_IPS (If you're behind a proxy like me you need to first edit the script and remove '--no-proxy' so it will respect the http_proxy environment variable (One of those "What were they thinking?" moments))
copy firehol.sh to /sbin/firehol
/etc/init.d/firehol restart

This however ignores /etc/default/firehol, though patching the firehol script to support this in true debian style shouldn't be too hard.

It's to sad that this bug it still going to continue in Gutsy.

Today, just to check how it is in Debian, I've found that 1.256 was added in Debian unstable in 2007-09-01 and 2007-09-05 - http://packages.qa.debian.org/f/firehol.html - too late for Gutsy as Scott Kitterman said.

To install the deb package version 1.256 from Debian in Gutsy (I think it should work in Feisty too):

wget http://ftp.debian.org/debian/pool/main/f/firehol/firehol_1.256-2_all.deb
sudo dpkg -i firehol_1.256-2_all.deb

Apparently it is working without problems here.

El Tue, 16 Oct 2007 18:06:31 -0000
Rui Bernardo <email address hidden> escribió:

> It's to sad that this bug it still going to continue in Gutsy.

 Yes very sad indeed (to say the least)

>
> Today, just to check how it is in Debian, I've found that 1.256 was
> added in Debian unstable in 2007-09-01 and 2007-09-05 -
> http://packages.qa.debian.org/f/firehol.html - too late for Gutsy as
> Scott Kitterman said.
>
> To install the deb package version 1.256 from Debian in Gutsy (I think
> it should work in Feisty too):
>
> wget http://ftp.debian.org/debian/pool/main/f/firehol/firehol_1.256-2_all.deb
> sudo dpkg -i firehol_1.256-2_all.deb
>
> Apparently it is working without problems here.

 Thanks for the tip. Much apreciated

>

--
Nunca discutas con un idiota. Al final te hacen rebajarte a su nivel y entonces
te acaban ganando debido a su mayor experiencia.

We now need to go through the SRU process... I have no idea how to kick it off... anyone?

FWIW: Hardy has a newer version of firehol that seems to be fixed wrt. the new bash syntax. This bug can get closed once hardy is out;-)

New debdiff, many, many thanks to pochu on #ubuntu-bugsquad @freenode for helping talk me through this...

SRU proposal -
Impact on users: Major, bug stops firehol from working, and locks down the system it is applied on. Only way to fix it is to stop firehol, or apply one of the fudgy work-arounds, on console, which is painful if you don't have a serial console, and the server is 200 miles away... (Yes, done this.)

Development Branch fix:
Removed quotes around one variable. From the upstream changelog:
BASH 3.2 support.
The problem is in array variables.
For some reason, an empty array member in BASH 3.1 produces no iptables
arguments, but in BASH 3.2 an empty array member produces an empty iptables
argument which breaks iptables.

Debdiff attached directly above *should* cover the patch required.

Reproduction / Test Case:
> Install firehol
> Start firehol (firehol start)
> Failure

Regression potential is limited. However, if it does occur, would likley lock down systems to which it happens on. (Those systems on which firehol has been fudged to work. )

Jonathan, thanks for the patch.

Please apply the following changes:
 - use "LP: #78017" to close/refer to the bug from the changelog
 - the version should be 1.231-7ubuntu0.1
 - the pocket should be gutsy-proposed, not gutsy

See http://wiki.ubuntu.com/SRU for more information.

Please re-subscribe u-u-s once a satisfying patch is ready.

Hardy version of firehol solved this issue, both Gutsy and Feisty are affected (Edgy and Dapper are not).

If you want, you can prepare two debdiffs for gutsy-proposed and feisty-proposed with the fix provided in comment #35, which worked for me on both releases. You should follow http://wiki.ubuntu.com/SRU (as Daniel reported), but you should adjust a couple of things:
* Target release will be gutsy-proposed and feisty-proposed
* Version should be 1.231-7ubuntu0.7.10 for gutsy-proposed and 1.231-7ubuntu0.7.04 for feisty-proposed
* You should edit Maintainer field in debian/control as per https://wiki.ubuntu.com/DebianMaintainerField

Considering it was my first package build EVER, I was just happy to get it done. I don't have the packages here, they are at work. I've come down with some sort of bug, I'll redo it again once I'm over it, and am back at work.

Note: I have already done the Maintainer field, if you check the diff ;)

What is u-u-s? Is it the SRU team?

How do I set target release? (Or rather, where do I set target release?) I couldn't find it in the packaging recipe...

Johnathon, the "target release" is given in the changelog.

You may want to hop into the #ubuntu-motu IRC channel for further questions that may arise.

New debdiff for feisty as requested.

debdiff for gusty.

Thank you, Johnathon. I've verified that the patch fixes firehol in Gutsy.

Subscribing ubuntu-universe-sponsors again.

Uploaded in {feisty,gutsy}-proposed, thanks.

Accepted to feisty-proposed, please test

Accepted to gutsy-proposed, please test

So far, I am still waiting for the patch to come through gutsy-proposed before I start requesting testing.
Is there a large lag on the gb repos?

It looks like the source has been uploaded to gutsy-proposed, but that has not become a binary. Is that process automatic, and if so how long will it take?

Binary packages have been published and will be available soon:
https://launchpad.net/ubuntu/gutsy/+queue?queue_state=3&queue_text=firehol
https://launchpad.net/ubuntu/feisty/+queue?queue_state=3&queue_text=firehol

Installed from gutsy-universe same error showed
Installed from gutsy-proposed and no errors found all worked fine

Tested in Gutsy: works fine.

Pretty new here.. how long will firehol stay in gutsy-proposed before being moved into the main "gutsy" universe archive?

For at least seven days. It will be copied to -updates if two persons confirmed fix is good.
Could you give your feedback too to speed up the procedure? Thanks.

Sure. I just tested the gutsy-proposed version with the same configuration that failed with gutsy-universe and it works perfectly with no issues from what I can see.

Minimum aging period of seven days elapsed and two persons confirmed fix is good.
Tagging verification-motu-done as per https://wiki.ubuntu.com/StableReleaseUpdates.

El Sat, 24 Nov 2007 18:28:45 -0000
Luca Falavigna <email address hidden> escribió:

> For at least seven days. It will be copied to -updates if two persons confirmed fix is good.
> Could you give your feedback too to speed up the procedure? Thanks.
>
 I can confirm that the fix is good i'm using it now without any problems (that
i know of anyway ;P)

Copied to feisty/gutsy-updates.

YAY!

We can finally install firehol without having to muck around with bash binary hacks... :)

Thanks to everyone who helped get this bug through SRU :)