|Summary:||CVE-2012-2663 iptables: --syn flag bypass|
|Product:||[Other] Security Response||Reporter:||Kurt Seifried <kseifried>|
|Component:||vulnerability||Assignee:||Red Hat Product Security <security-response-team>|
|Status:||CLOSED WONTFIX||QA Contact:|
|Version:||unspecified||CC:||agordeev, anton, arozansk, avaddara, dhoward, fhrbata, fweimer, gbarros, john.haxby, kernel-mgr, lwang, plougher, pmatouse, ppandit, sforsber, tgraf, vcizek, wnefal+redhatbugzilla, yohmura|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2014-03-10 12:39:45 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:|
Description Kurt Seifried 2012-05-30 19:45:29 UTC
Originally reported as a DoS related issue: http://git.kernel.org/?p=linux/kernel/git/davem/net-next.git;a=commitdiff;h=fdf5af0daf8019cec2396cdef8fb042d80fe71fa Denys Fedoryshchenko reported that SYN+FIN attacks were bringing his linux machines to their limits. Dont call conn_request() if the TCP flags includes SYN flag --- This issue also allows bypass of --syn rules in iptables: http://www.spinics.net/lists/netfilter-devel/msg21248.html Unfortunately, with current stable Linux kernel release (as well as with most of the previous versions) blocking TCP packets with the SYN bit set and the ACK,RST and FIN bits cleared won't prevent incoming TCP connections. It should be noted that the combination of SYN+FIN in a TCP-IP packet is generally "illegal" and serves no legitimate purpose.
Comment 2 Kurt Seifried 2012-05-30 20:09:42 UTC
The -m state --state NEW rules do not appear to be bypassed by the combination of SYN+FIN, so a potential workaround is to use rules such as: -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j DROP to control access rather than rules such as: -A INPUT -p tcp --syn --dport 22 -j DROP
Comment 3 Florian Weimer 2012-05-31 07:59:20 UTC
Older kernels will accept SYN+FIN because they have remnants of T/TCP support (see RFCs 1379, 1644; RFC 6247 moved them to HISTORIC for security issues). We went over this when in 2002, it was discovered that the Cisco IOS "established" ACL keyword would let segments with SYN+RST flags pass, which would be interpreted as plain SYN by some stacks (including Linux), thus bypassing the packet filter. (CVE-2002-2438, as discussed on oss-security.) At that time, we did not feel comfortable with outlowing the Linux SYN+FIN behavior, even though it was clearly known at that time (e.g., <http://cert.uni-stuttgart.de/ticker/article.php?mid=1006>, it's German, sorry). Obviously, the Internet has moved on since then. My actual concern here is that the proposed change only moves the goalposts. We discard a crafted packet earlier. The next time, attackers will use a flag combination which gets past the initial filter, and the impact of the attack will be similar to what happened before.
Comment 5 Kurt Seifried 2012-05-31 17:39:27 UTC
To clarify: this CVE was meant for the syn+fin processing vulnerability in iptables, not the Linux Kernel.
Comment 18 Petr Matousek 2014-03-10 12:39:45 UTC
Statement: This issue does affect Red Hat Enterprise Linux 5 and 6. The risks in breaking compatability associated with fixing this flaw outweigh the benefits of the fix, therefore Red Hat does not plan to fix this flaw in Red Hat Enterprise Linux 5 and 6. Please note that the remote DoS issue in the way how Linux kernel treats SYN+FIN flags set is being handled under different CVE, CVE-2012-6638, and is planned to be fixed in all affected Red Hat Enterprise Linux releases.
Comment 19 Petr Matousek 2014-03-10 12:43:13 UTC
Mitigation: Instead of --syn use --tcp-flags SYN,RST,ACK SYN in your rulesets in case you want to also match packets with both SYN+FIN flags set.