REDHAT-BUG-1182059: Medium severity red hat iptables-services vulnerability
It was reported [1] that iptables can allow protocols that do not have a protocol handler kernel module loaded.
Given following iptables ruleset: -P FORWARD DROP -A FORWARD -m sctp --dport 9 -j ACCEPT -A FORWARD -p tcp --dport 80 -j ACCEPT -A FORWARD -p tcp -m conntrack -m state ESTABLISHED,RELATED -j ACCEPT
One would assume that this allows SCTP on port 9 and TCP on port 80. Unfortunately, if the SCTP conntrack module is not loaded, this allows all SCTP communication to pass through, i.e. -p sctp -j ACCEPT
[1]: http://www.spinics.net/lists/netfilter-devel/msg33430.html
Affected Software
Event History
Frequently Asked Questions
When is this ruleset behavior exposed?
It is exposed when an iptables rule uses the SCTP match, such as "-m sctp --dport 9", but the SCTP conntrack protocol handler module is not loaded. In that condition, the port-specific SCTP rule can permit all SCTP traffic rather than only traffic to the intended port.
What traffic could an attacker send if the condition is present?
An attacker able to send SCTP traffic through the affected FORWARD path could communicate over SCTP to ports other than the explicitly allowed port. The described policy's default FORWARD DROP setting does not prevent this unintended SCTP allowance.
How can administrators assess whether their policy is affected?
Review FORWARD-chain rules for SCTP port matching and determine whether the SCTP conntrack protocol handler module is loaded. A configuration that expects a rule such as "-m sctp --dport 9" to restrict SCTP to that port is affected if the handler is absent.