A dependency on net in /etc/init.d/shorewall forces shorewall to wait until one (or even all) network interfaces ar up. Even if all network interfaces come up quickly, there rests a timespan of some seconds, during which the no firewall rules are effective. If /etc/rc.conf is configured to wait until all interfaces are up, shorewall may be delayed forever. depend() { need net provide firewall after ulogd } At least with iptables, shorewall could (and should) be started before any network interface is able to communicate. iptables can handle not yet existing network interfaces. Reproducible: Always Steps to Reproduce:
netmon and Vieri, can you please comment on mitigations or fixes for this issue?
ping ...
Which services should start before shorewall (including the eth* scripts) depends on the user's shorewall configuration. Shorewall could start before the NICs are brought up but the user may have defined some shorewall configuration constructs that require the network to be up. Likewise, if the user defines hostnames in Shorewall then they won't work if name resolution is not up. The fact is that Shorewall is quite complex and flexible. So I think that the current init script is "safe enough" for most scenarios. Users who wish to tailor to their needs may use options such as RC_NET_STRICT_CHECKING instead. In any case, I agree that the depend() clause should be modified. Maybe a conf.d file for shorewall should be created so the user can adapt shorewall's init position (especially for "use" or "need"). The default may be: use net provide firewall after logger Just an opinion.
Maybe this is "too flexible": depend() { [ -d ${SW_NEED} ] && need ${SW_NEED} [ -d ${SW_USE} ] && use ${SW_NEED} [ -d ${SW_BEFORE} ] && before ${SW_NEED} [ -d ${SW_AFTER} ] && after ${SW_NEED} provide firewall } where SW_* are defined in /etc/conf.d
(In reply to comment #3) > The default may be: > > use net > provide firewall > after logger I encountered this problem on a notebook, when rc_depend_strict was enabled by default, after I was forced to switch from wlan to an ethernet NIC which I normally don't use. Not looking too closely at the usual boot chatter, I sailed for a day without an enabled firewall while being part of a foreign network. Such a situation could also happen with servers, when NICs come up late or become unavailable for some reason. Thus I think, starting Shorewall per default "before net" would be a safe option, and whoever really needs to do name resolution within a firewall script could change that explicitly. As an aside, man 8 iptables has this about using hostnames instead of plain numbers: [!] -s, --source address[/mask][,...] Source specification. Address can be either a network name, a hostname (please note that specifying any name to be resolved with a remote query such as DNS is a really bad idea),[...]
(In reply to comment #4) > Maybe this is "too flexible": My take: depend() { [[ ${SW_NEED} ]] && need ${SW_NEED} [[ ${SW_USE} ]] && use ${SW_USE} [[ ${SW_BEFORE} ]] && before ${SW_BEFORE} [[ ${SW_AFTER} ]] && after ${SW_AFTER} [[ ${SW_NEED} || ${SW_USE} \ || ${SW_BEFORE} || ${SW_AFTER} ]] || before net provide firewall } with SW_* defined in etc/conf.d/Shorewall. With SW_* perhaps better renamed to SHOREWALL_*. What is the semantic difference between "use" and "after"? I did not find anything in rc's man pages. Does "use" mean that the service referred to must have started successfully?
(In reply to comment #6) > difference between "use" and "after"? Taken from the handbook: "In some cases you might not require a service, but want your service to be started before (or after) another service if it is available on the system (note the conditional - this is no dependency anymore) and run in the same runlevel (note the conditional - only services in the same runlevel are involved)." Your depend() looks better. Maybe a smarter depend() would make conditional sed's on the shorewall config files in order to automatically determine need, use, order... But that may be overkill and error-prone.
Just found this in Shorewall's FAQ at http://www.shorewall.net/configuration_file_basics.htm#dnsnames : Using DNS Names Caution I personally recommend strongly against using DNS names in Shorewall configuration files. If you use DNS names and you are called out of bed at 2:00AM because Shorewall won't start as a result of DNS problems then don't say that you were not forewarned. Host addresses in Shorewall configuration files may be specified as either IP addresses or DNS Names. DNS names in iptables rules aren't nearly as useful as they first appear. When a DNS name appears in a rule, the iptables utility resolves the name to one or more IP addresses and inserts those addresses into the rule. So changes in the DNS->IP address relationship that occur after the firewall has started have absolutely no effect on the firewall's rule set. [...]
Created attachment 211618 [details, diff] shorewall ebuild diff to include confd file
Created attachment 211620 [details] shorewall confd file
Created attachment 211621 [details] shorewall init script
Created attachment 211622 [details, diff] shorewall init script diff
Forget the grepping. Keep it simple. These files are only for testing, not for committing, yet. Hugo, please test and report back ;-) You can also apply manually to shorewall6 and/or shorewall-lite if you wish to test those too.
(In reply to comment #13) I've a few minor points, and one major objection. 1.) shorewall.confd should include a reference to Tom Eastep's warning which I cited in comment #8. 2.) Shorewall.confd maybe renamed to "shorewall", as all other files residing in /etc/conf.d have lowercase filenames and no extension. The convention seems to be to name the file in /etc/conf.d exactly like the init script in /etc/init.d. 3.) RHS variable references should be fully quoted everywhere, like "${SOMETHING}" -- an expression like [[ "" ]] still evaluates to false 4.) Use $() to spawn a subshell instead of the deprecated backtick notation 5.) I originally followed your idea to introduce four variables. After having thought about it, I now think it would be less error prone when only a before/after logic is provided. Consider the set of hidden, contradictory or cyclic dependencies when the effective graph depends on four freely configurable variables! An example for such a hidden dependency is the depend function of /etc/init.d/syslog-ng, providing an implementation of "logger", and introducing, among other, a hidden dependency on net: depend() { # Make networking dependency conditional on configuration case $(sed 's/#.*//' /etc/syslog-ng/syslog-ng.conf) in *source*tcp*|*source*udp*|*destination*tcp*|*destination*udp*) need net use stunnel ;; esac # kludge for baselayout-1 compatibility [ -z "${svclib}" ] && config /etc/syslog-ng/syslog-ng.conf need clock hostname localmount provide logger } For our convenience, I'm just linking the Gentoo init script documentation here: http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=4#doc_chap4 Interestingly, you can call every init script with a parameter such as ineed, iuse, ibefore, iafter and so on. Thus it should be possible construct a dependency list from within an init script, providing the grounds for testing against sloppy dynamic configurations. Is there already an official way to generate such a dependency list also for virtual targets, say, for "logger"?
(In continuation of my comment #14) Seems as if we are partly reinventing the wheel. man runscript has the following: [...] With the exception of /etc/rc.conf, the configuration files can also influence the dependencies of the service through variables. Simply prefix the name of the dependency with rc_. Examples: # Whilst most services don't bind to a specific interface, our # openvpn configuration requires a specific interface, namely bge0. rc_need="net.bge0" # To put it in /etc/rc.conf you would do it like this rc_openvpn_need="net.bge0" # Services should not depend on the tap1 interface for network, # but we need to add net.tap1 to the default runlevel to start it. rc_provide="!net" # To put it in /etc/conf.d/net you would do it like this rc_provide_tap1="!net" # To put in in /etc/rc.conf you would do it like this rc_net_tap1_provide="!net" # It's also possible to negate keywords. # This is mainly useful for prefix # users testing OpenRC. rc_keyword="!noprefix"
Thanks for pointing that out. A Gentoo dev should take a look at this.
Hugo, does /etc/rc.conf works for you? If it does (well, it should) the only thing that's needed here is to change defaults. And yes, by default it's better to start firewall before net. And if default will be changed it's good idea to place some ewarn into ebuild.
(In reply to comment #17) > Hugo, does /etc/rc.conf works for you? There isn't a simple answer. It depends how rc_depend_strict is set, and if the shorewall script actually depends on net. Clearly, if rc_depend_strict is "YES" (the default) and shorewall depends on net, then you run into the situation that one interface comes up while shorewall waits for the others, maybe forever. If you set rc_depend_strict to "NO", you may still get a some seconds window. Since many hosts running custom applications are configured to reboot regularily for getting rid of memory hogs, with the exact timing determinable, e.g., by using ping, this window could be remotely exploitable (and even more so, when also rc_parallel would have been set to "YES"). >If it does (well, it should) the only thing that's needed here is to >change defaults. And yes, by default it's better to start firewall >before net. And if default will be changed it's good idea to place >some ewarn into ebuild. If I understand you right you are argueing for taking "before net" as a default instead of "need net", and put a warning about it into the ebuild of shorewall? However, it is still unclear (to me) what runscript really does when it encounters contradictory dependencies, i.e., in this case: "before net" and "need net" (by logger proxy, eventually, see comment #8). May be, as it seems, "before" takes precedence. But this inconsistency is not handled properly. I had assumed runscript would flag an error -- but it does not, at least not with runscript taken from sys-apps/openrc-0.5.1.
Based on what I see here, the elaborate approach that was proposed for the init.d script is not required. Going for a KISS approach, I would shorten depend() to: before net provide firewall Yes, this could introduce another gap where any packet logging rule results are only logged on the console and do not end up in the log files. However, we can be sure that the firewall is up before any interface launches, closing the gap described in all situations. Hugo, security, opinions?
*** Bug 307521 has been marked as a duplicate of this bug. ***
(In reply to comment #19) > Based on what I see here, the elaborate approach that was proposed for the > init.d script is not required. Going for a KISS approach, I would shorten > depend() to: > before net > provide firewall I concur, provided nobody adds "logger" or something later on, which calls for "net" implicitely. OpenRC's runscript, whenever it encounters contradictory constructs like "before net" and, later on, "need net", simply uses the latter and quietly disregards the former. This seems to be an OpenRC bug.
(In reply to comment #21) > OpenRC's runscript, whenever it encounters contradictory > constructs like "before net" and, later on, "need net", simply uses the latter > and quietly disregards the former. This seems to be an OpenRC bug. Not an OpenRC bug. As "need, use and after" are all contradictory to before so we remove the before depend. There is no ordering here, but if there was it would be like so need > use > after > before
+*shorewall6-4.2.11-r1 (13 Apr 2010) + + 13 Apr 2010; <chainsaw@gentoo.org> +files/shorewall6.initd2, + +shorewall6-4.2.11-r1.ebuild: + Updated init script with simplified dependencies addresses security bug + #288992 by Hugo Mildenberger. +*shorewall-common-4.2.11-r1 (13 Apr 2010) + + 13 Apr 2010; <chainsaw@gentoo.org> +shorewall-common-4.2.11-r1.ebuild, + +files/shorewall.initd2: + Updated init script with simplified dependencies addresses security bug + #288992 by Hugo Mildenberger.
Arches, please test and mark stable: =net-firewall/shorewall6-4.2.11-r1 =net-firewall/shorewall-common-4.2.11-r1 =net-firewall/shorewall-lite-4.2.11 =net-firewall/shorewall-perl-4.2.11.1 =net-firewall/shorewall-shell-4.2.11 This will address the security vulnerability discussed and bring our Shorewall packages in line with the current upstream stable. The ebuilds in question have been in the tree since October 2009 with no bugs reported. Shorewall6 has no previous stable but would benefit from a unified stable. To confirm, both users of the shell and the perl variety will be able to migrate. It is the later 4.4 version that deprecates shell in favour of perl. Any concerns, please talk to me on IRC in #gentoo-security Target keywords="alpha amd64 hppa ppc ppc64 sparc x86"
Oh, i've got a slight problem with "before net". Just add a warning that the "detect" option must not be used in interfaces for shorewall otherwise some people will find themselves locked out like i did from my server/AP machine. Just imagine this kind of thing happening for a dedicated/vps server with no physical access....
(In reply to comment #25) > Oh, i've got a slight problem with "before net". > Just add a warning that the "detect" option must not be used in interfaces for > shorewall otherwise some people will find themselves locked out like i did > from my server/AP machine. + 13 Apr 2010; <chainsaw@gentoo.org> shorewall6-4.2.11-r1.ebuild: + As per Gustavo Zacarias, add an ewarn noting that the detect option on + interfaces should be avoided with the new init script dependencies. + 13 Apr 2010; <chainsaw@gentoo.org> shorewall-common-4.2.11-r1.ebuild: + As per Gustavo Zacarias, add an ewarn noting that the detect option on + interfaces should be avoided with the new init script dependencies.
Stable for HPPA.
x86 stable
ppc done
amd64 stable
(In reply to comment #30) > amd64 stable > Thanks.
This update works, but now shorewall shows up (using baselayout 1 rc system) as not having started when it really has. Observe that it has actually started: ------------------------------------------------------------------------------ twister ~ # shorewall status Shorewall-4.2.11 Status at twister - Thu Apr 15 22:16:00 EDT 2010 Shorewall is running State:Started (Thu Apr 15 22:11:11 EDT 2010) ------------------------------------------------------------------------------ (I have also verified that it actually started and is running by seeing startup entries in logs, new blacklist hits in logs, etc.) However, the rc system says it has not started: ------------------------------------------------------------------------------ twister ~ # /etc/init.d/shorewall status * status: stopped ------------------------------------------------------------------------------ I've reviewed the dependencies of my init scripts and don't see anything amiss there. What would cause this?
(In reply to comment #32) > This update works, but now shorewall shows up (using baselayout 1 rc system) > as not having started when it really has. Separate issues in separate bugs, thank you. This is not an appropriate place for user pings.
(In reply to comment #33) > (In reply to comment #32) > > This update works, but now shorewall shows up (using baselayout 1 rc system) > > as not having started when it really has. > > Separate issues in separate bugs, thank you. This is not an appropriate place > for user pings. > How is it a separate issue, if the change implemented here caused this problem?
(In reply to comment #34) > How is it a separate issue, if the change implemented here caused this problem? If a dependency simplification tickles a bug in the dependency resolver, that is a baselayout bug. Not a shorewall bug. This security bug is not an appropriate place to report a defective dependency resolver. I'm glad that you have a reproducable test case for the bug that you have found. Please go forth and report it where it belongs. I hope I won't have to repeat myself again.
ppc64 done
shorewall6-4.2.11-r1.ebuild has an ewarn noting that the detect option on interfaces should be avoided... But shorewall-perl only supports 'detect' or '-' in this column (from man shorewall-interfaces) while '-' only serves for multi zone interfaces.
(In reply to comment #37) > shorewall6-4.2.11-r1.ebuild has an ewarn noting that the detect option on > interfaces should be avoided... > But shorewall-perl only supports 'detect' or '-' in this column (from man > shorewall-interfaces) while '-' only serves for multi zone interfaces. Seperate issues in separate bugs please, thank you very much. Security bugs are *not* an appropriate place for user pings or unrelated comments/reports.
alpha/sparc stable
Hi guys, firstly I agree to Hugo Mildenberger how created that bug. But after updating shorewall my firewall was not starting anymore. The problem is that I have to use masq. But if you try starting shorewall it tries to execute the following commands if you have masq configured: ip addr ls dev <interface> But this command - of course - fails if the device is not up. This happens since "before net" is specified in dependencies. Any ideas on how to solve this problem? I have not! I changed the dependency to "after net" but this is not the solution of Hugos problem. greez Daniel
(In reply to comment #40) > Hi guys, > firstly I agree to Hugo Mildenberger how created that bug. > > But after updating shorewall my firewall was not starting anymore. The problem > is that I have to use masq. But if you try starting shorewall it tries to > execute the following commands if you have masq configured: > > ip addr ls dev <interface> > > But this command - of course - fails if the device is not up. This happens > since "before net" is specified in dependencies. > > Any ideas on how to solve this problem? I have not! I changed the dependency to > "after net" but this is not the solution of Hugos problem. > > greez > Daniel > I am running shorewall on my router and I have the same problem here. When I reboot my router (which runs shorewall and uses the masq file to define the NAT) shorewall fails to start. This causes a loss of ALL internet access from every PC on my network and requires me to log into the router via the console (to restart shorewall). Checking the console on the router shows this message: "ERROR: Unable to determine the routes through interface eth_lan" From the shorewall documentation: "ERROR: Unable to determine the routes through interface <interface> You have specified <interface> in the SUBNET column of /etc/shorewall/masq which means that Shorewall is supposed to determine the network(s) routed through that interface. To do that, Shorewall issues the command ip addr ls dev <interface> and that command failed. This usually means that you are trying to start Shorewall before the <interface> is brought up." The current solution is not satisfactory, as it will break masquerading (NAT) on every router that I administer. As such, I can not upgrade shorewall on any of them. I have opened bug 328521 to address this issue.
GLSA Vote: Yes.
Vote: NO, IMHO not a real security problem in itself, but a bug (startup failure). For a component like a firewall you might have wanted to check its functionality anyways..
Hi Stefan, I agree with you. This is not a real security bug. But my router starts up every day at 7am automatically. Thus I am not able to check the firewall. I sleep :-) cheers Daniel
This "fix" should be reverted. It causes a critical regression in shorewall.
(In reply to comment #45) > This "fix" should be reverted. It causes a critical regression in shorewall. It causes a critical regression for people used to put interfaces online before firewalling had started. Among them, apparently, staffers working for Sophos and even Cisco, if I understand the reference frame of their respective comments correctly.
voting no too and closing.
