Bug 826702 - (CVE-2012-2663) CVE-2012-2663 iptables: --syn flag bypass
CVE-2012-2663 iptables: --syn flag bypass
Status: CLOSED WONTFIX
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
impact=moderate,public=20111202,repor...
: Security
Depends On:
Blocks: 879100
  Show dependency treegraph
 
Reported: 2012-05-30 15:45 EDT by Kurt Seifried
Modified: 2015-07-15 21:21 EDT (History)
19 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-03-10 08:39:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Kurt Seifried 2012-05-30 15:45:29 EDT
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 16:09:42 EDT
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 03:59:20 EDT
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 13:39:27 EDT
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 08:39:45 EDT
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 08:43:13 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.