Bug 826702 (CVE-2012-2663)

Summary: CVE-2012-2663 iptables: --syn flag bypass
Product: [Other] Security Response Reporter: Kurt Seifried <kseifried>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: agordeev, anton, arozansk, avaddara, dhoward, fhrbata, fweimer, gbarros, john.haxby, kernel-mgr, lwang, plougher, pmatouse, ppandit, sforsber, tgraf, vcizek, wnefal+redhatbugzilla, yohmura
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-03-10 12:39:45 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 879100    

Description Kurt Seifried 2012-05-30 19:45:29 UTC
Originally reported as a DoS related issue:


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:


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

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

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.