Summary: | net-firewall/iptables: problem with automatically loading modules | ||||||
---|---|---|---|---|---|---|---|
Product: | Gentoo Security | Reporter: | Matthias Geerdsen (RETIRED) <vorlon> | ||||
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | normal | CC: | aliz | ||||
Priority: | High | Keywords: | InVCS | ||||
Version: | unspecified | ||||||
Hardware: | All | ||||||
OS: | All | ||||||
URL: | http://securitytracker.com/alerts/2004/Nov/1012025.html | ||||||
Whiteboard: | A4 [noglsa] vorlon | ||||||
Package list: | Runtime testing required: | --- | |||||
Attachments: |
|
Description
Matthias Geerdsen (RETIRED)
2004-11-06 03:18:48 UTC
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 |