CAN-2004-0986 from Securitytracker: Iptables May Fail to Automatically Load Some Modules SecurityTracker Alert ID: 1012025 SecurityTracker URL: http://securitytracker.com/id?1012025 CVE Reference: CAN-2004-0986 (Links to External Site) Date: Nov 1 2004 Impact: Host/resource access via network, Modification of system information Fix Available: Yes Vendor Confirmed: Yes Version(s): 1.2.11 Description: A vulnerability was reported in iptables. In certain configurations, some modules may not load automatically. It is reported that in certain situations, the software may fail to load the required modules. As a result, some rules may not be properly enforced. The flaw resides in 'iptables.c' and 'ip6tables.c'. Faheem Mitha is credited with reporting this flaw. Impact: The software may fail to load some modules, potentially causing some rules to not be properly enforced. Solution: A fix is available via CVS. Vendor URL: www.netfilter.org/ (Links to External Site) Cause: Exception handling error ___ http://lists.netfilter.org/pipermail/netfilter-devel/2004-October/017113.html http://secunia.com/advisories/13061/ ___ aliz pls verify/patch as appropriate
Created attachment 43395 [details, diff] patch used by debian for their iptables_1.2.11-4
sorry for the noise... I'm lacking some (sleep|caffeine) I guess :\
Timeout waiting on maintainer. Patched added in iptables-1.2.11-r3 KEYWORDS: iptables-1.2.7a-r3: mips iptables-1.2.9-r4: arm ia64 iptables-1.2.11-r2: ppc x86 ppc64 sparc alpha hppa amd64 iptables-1.2.11-r3: ~amd64 ~hppa ~x86 ~mips ~ia64 ~ppc ~alpha ~sparc ~ppc64 ~arm
Arches, please test and mark iptables-1.2.11-r3 stable
mips stable.
sparc'd
stable on x86
stable on ppc
Stable on alpha.
stable on amd64
security, since we are nearly done with stable marking, please vote on GLSA Debian and Mandrake issued advisories already Personally I would vote yes, although the problem mainly seems to exist with rules created by 'lokkit', which I don't think we have an ebuild for.
stable on ppc64
readding ppc since the ebuild has not been marked stable yet iptables-1.2.11-r3.ebuild:KEYWORDS="x86 ~ppc sparc mips alpha ~arm ~hppa amd64 ~ia64 ppc64"
I vote for a GLSA on this one.
stable on ppc sorry for delay
Playing devil's advocate, I vote for no GLSA on this one. Our firewall scripts do not look affected (firewall and shorewall correctly load modules), and we don't include lokkit... You'll have to get another go-for-it. If you do issue it, "Low" seems in order.
Elaborating my position : In iptables, adding rules without having the modules loaded result in an error. The problem here is that lokkit doesn't check for errors when issuing iptables commands, and let the script finish without bailing on error in an all-deny state. Lokkit says to iptables : "you should load modules in all cases so I don't have to doublecheck you did. So it's not my bug, it's yours, you should load in all cases". IPtables, being a nice guy, answers, "Yes, there is a bug in iptables, I'm not loading modules in a very specific case. I fixed that bug." For my part, I wouldn't trust a firewall script that silently ignores iptables errors and gives a false sense of security. I'm glad we don't have lokkit in portage. So I think it's lokkit fault as much as iptables fault. Issuing a GLSA without making sure at least one of our firewall scripts in portage is affected is somewhat misleading. shorewall is not affected. Our basic firewall script isn't either. We could adopt the "better safe than sorry" attitude Mandrake took and issue a GLSA even if not having lokkit in portage, just in case. If someone else thinks we should, then so be it.
arm/hppa/ia64 stable now
Voting against a GLSA, since iptables usually does report errors when a needed module is not loaded.
I vote no GLSA.
Closing without GLSA with 3 NO votes
