Re: Ambiguities in TCP/IP - firewall bypassing
Aaron Hopkins <[EMAIL PROTECTED]> writes: > On Sat, 19 Oct 2002, Florian Weimer wrote: > >> "established" in Cisco parlance does not mean "SYN unset", but "ACK or RST >> set". This means that the impact for non-Linux hosts (which do not react >> to SYN-RST packets according to Paul's survey) is less severe if your >> filters run IOS. > > This is true for IOS up through 11.3. The 12.0, 12.1, and 12.2 > documentation claims: > established: (Optional) For the TCP protocol only: Indicates an > established connection. A match occurs if the TCP datagram > has the ACK, FIN, PSH, RST, SYN or URG control bits set. > The nonmatching case is that of the initial TCP datagram to > form a connection." This documentation is quite misleading. Our experiments with a 12.1 version suggests that RST and/or ACK bits cause the packet to pass. > If the documentation is correct, then you can fool IOS 12.0+ "permit tcp any > any established" at the top of an access list into letting you make > connections to any port on at least Linux 2.4.19, Solaris 5.8, FreeBSD 4.5, > and Windows NT 4.0, as reported by Paul Starzetz in the post starting this > thread. The SYN,FIN combination is filtered (it's permitted by the RFC if you read it carefully, I think, and some systems can cope with it). > Thats not necessarily true. At least with current IOS (12.2, perhaps > earlier), you can specify "permit tcp any any ack" instead of "permit tcp > any any established" to work around this bug entirely and retain almost all > functionality. Interesting, thanks. It's not documented for 12.1. The CLI accepts it, though. I'll check if it's properly supported. This approach is much more general than reflexive access lists (which can break long-lasting interactive sessions because of the timeouts involved). -- Florian Weimer[EMAIL PROTECTED] University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT fax +49-711-685-5898
RE: Ambiguities in TCP/IP - firewall bypassing
I would like to refer you back to a March 2000 Bugtraq post: http://online.securityfocus.com/archive/1/52793 The flag combinations with that post relate to Linux 2.2.x and Windows NT 4 SP6 (and not to all *nix as it states). It is also advised to read a reply from Lamont Granquist - http://online.securityfocus.com/archive/1/52939. I have also stated with that post that: "The Filtering Device is lame: If the firewall is just a simple packet filter that blocks incoming SYN's than some of the combinations I have listed would elicit a reply. If the Firewall is statefull (AND do his job as it should. I have seen some idiotically cases were statefull was not implemented as it should) nothing should pass it." As a side note - although the RFCs are not specific regarding the question on how to handle several different flag combinations, there is also a common sense that needs to be applied. For example, sending a TCP packet with the SYN|FIN flags on is known to be an OS fingerprinting attempt, a fact known for several years now (even appears on several text books :P). I do expect firewall manufactures to provide some kind of protection and filtering for non-logical and non-legitimate TCP/IP traffic, but as I noted back in March 2000, still there are some firewalls and filtering devices that let this traffic go by. Yours, Ofir Arkin [[EMAIL PROTECTED]] Founder The Sys-Security Group http://www.sys-security.com PGP CC2C BE53 12C6 C9F2 87B1 B8C6 0DFA CF2D D360 43FA -Original Message- From: Paul Starzetz [mailto:paul@;starzetz.de] Sent: Friday, October 18, 2002 4:47 PM To: [EMAIL PROTECTED] Subject: Ambiguities in TCP/IP - firewall bypassing 1. Abstract --- There are ambiguities in implementations of the TCP/IP suite for various operating systems. Even if this fact has been used since a long time in different software for OS fingerprinting, no real attempt has been made to identify the security impact of the differences in the TCP/IP semantics. We have done some research on the TCP/IP connection open semantics which is of course very important for security of networked systems. We believe that the flaws we have detected have a big impact on design of firewalls and packet filters since an improper implementation can easily lead to serious security problems. 2. Details -- The TCP/IP protocol stack offers a three way handshake for connection oriented communication using the TCP protocol. Basically, a connection can be opened by sending a synchronization packet to a listening service on a particular host. The host will respond with a synchronization acknowledgment packet which in turn must be acknowledged by the requesting host. Then, the connection is considered to be open (at least at the transport layer) and the two hosts may exchange some data. The three way handshake is an essential part of the communication using the TCP protocol. Therefore many packet filter firewalls try to prevent the three way handshake from completion in order to protect an internal/corporate network from being accessed from the outside. Of course, statefull firewalls may have some more sophisticated mechanism. We have found a very ambiguous behavior of TCP/IP implementations while doing some research on the connection request phase. Below you will find the findings about various OSes, however the list should not be considered complete. We have used the NemesisTCP tool [1] to generate the traffic and tcpdump to capture the responses. * The normal behavior (of all OSes) is like this: 14:18:00.595517 192.168.1.184.12345 > 192.168.1.111.: S 420:420(0) win 512 (DF) [tos 0x18] 14:18:00.595731 192.168.1.111. > 192.168.1.184.12345: S 1679763291:1679763291(0) ack 421 win 5840 (DF) The first host sends a SYN packet from port 12345 to a service on port and receives a SYN,ACK * Linux 2.4.19 The examination of the source code of the TCP engine reveals that a TCP connection can be opened by any combination of the TCP flags having the SYN bit set and the ACK bit reset. For example we can open a TCP connection by sending an obviously bogus SYN,RST packet: 14:25:43.97 192.168.1.184.12345 > 192.168.1.111.: SR 420:420(0) win 512 (DF) [tos 0x18] 14:25:43.889143 192.168.1.111. > 192.168.1.184.12345: S 2168208394:2168208394(0) ack 421 win 5840 (DF) or something called 'Christmas packet' having mostly every TCP flag set (except the ACK flag of course): 14:30:46.341732 192.168.1.184.12345 > 192.168.1.111.: SFRP 420:420(0) win 512 urg 8 (DF) [tos 0x18] 14:30:46.342444 192.168.1.111. > 192.168.1.184.12345: S 2492223280:2492223280(0) ack 421 win 5840 (DF) Also SYN,FIN packets works well... * Solaris 5.8 Here we have success by sending SYN,FIN packets: 14:33:24.549246 192.168.1.184.12345 > 192.168.1.84.: SF 420:420(0) win 512 (DF) [tos 0x18] 14:33:24.549757 192.168.1.84. > 192.168.1.184.1
Re: Ambiguities in TCP/IP - firewall bypassing
>Think of ECN; should older stacks simply reject a packet with Syn+0x42 >because they don't know what 0x42 is? > >If I've understood correctly, you were suggesting to drop "bad" packets. >I agree; only let established traffic through your firewall, and only >let packets with Syn or Syn+Ack set and with Fin and Rst unset establish >state in the firewall. Ignore the rest of the flags. > >Of course, if anyone finds this un-interoperable, please chime in! Before people get too paranoid about accepting packets I recommend they read RFC 3360: Inappropriate TCP Resets Considered Harmful. 1. Introduction TCP uses the RST (Reset) bit in the TCP header to reset a TCP connection. Resets are appropriately sent in response to a connection request to a nonexistent connection, for example. The TCP receiver of the reset aborts the TCP connection, and notifies the application [RFC793, RFC1122, Ste94]. Unfortunately, a number of firewalls and load-balancers in the current Internet send a reset in response to a TCP SYN packet that use flags from the Reserved field in the TCP header. Section 3 below discusses the specific example of firewalls that send resets in response to TCP SYN packets from ECN-capable hosts. [ ... ] --lyndon
Re: Ambiguities in TCP/IP - firewall bypassing
Alun Jones <[EMAIL PROTECTED]> wrote: > >Not necessarily. Have you heard of T/TCP? Before that was around, I >remember hearing discussion of using a packet with SYN, FIN, and data all >in one, to cut down on round-trips in really short communications, while >still providing reliability. One of the problems with T/TCP on the wider Internet is that it is almost as vulnerable to source address spoofing as UDP, so security facilities like those provided by tcp_wrappers (and built in to many daemons) are no longer so effective. With vanilla TCP, the T/TCP combination of SYN+ data+FIN isn't useful, because the passive end should discard data that arrives before the handshake is completed in order to preserve its spoof- resistence, therefore requiring a retransmit. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ FORTIES CROMARTY FORTH TYNE DOGGER: NORTHWESTERLY 4 OR 5, OCCASIONALLY 6. SHOWERS. GOOD.
Re: Ambiguities in TCP/IP - firewall bypassing
On Sat, 19 Oct 2002, Florian Weimer wrote: > "established" in Cisco parlance does not mean "SYN unset", but "ACK or RST > set". This means that the impact for non-Linux hosts (which do not react > to SYN-RST packets according to Paul's survey) is less severe if your > filters run IOS. This is true for IOS up through 11.3. The 12.0, 12.1, and 12.2 documentation claims: established: (Optional) For the TCP protocol only: Indicates an established connection. A match occurs if the TCP datagram has the ACK, FIN, PSH, RST, SYN or URG control bits set. The nonmatching case is that of the initial TCP datagram to form a connection." See: http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_command_reference_chapter09186a00800873c8.html#xtocid2 If the documentation is correct, then you can fool IOS 12.0+ "permit tcp any any established" at the top of an access list into letting you make connections to any port on at least Linux 2.4.19, Solaris 5.8, FreeBSD 4.5, and Windows NT 4.0, as reported by Paul Starzetz in the post starting this thread. Anyone want to test this? > As a result of this bug, it's quite complicated (if not impossible in some > configurations) to properly filter connection attempts to Linux hosts on > Cisco IOS routers. Thats not necessarily true. At least with current IOS (12.2, perhaps earlier), you can specify "permit tcp any any ack" instead of "permit tcp any any established" to work around this bug entirely and retain almost all functionality. All packets will be accepted that would have been by IOS < 12.0 "established", except those containing RST and not ACK. At least Linux only generates these in response to an ACK, which would mean you might have to time out the occasional connection instead of getting a "Connection reset by peer". So in leiu of any other fixes, I'd recommend replacing "established" with "ack" in all access-lists if your IOS supports it. -- Aaron
Re: Ambiguities in TCP/IP - firewall bypassing
Paul Starzetz wrote: >We believe that the flaws we have detected have a big impact on >design of firewalls and packet filters since an improper implementation >can easily lead to serious security problems. Is there any reason to expect that such improper implementation would be common? As far as I know, the common case is packet filters that look at only the ACK and SYN bits. A typical configuration: All incoming packets with the ACK bit set are allowed, as are all outgoing packets. The anomalies you found don't seem to pose any problems for such a style of configuration. Are you aware of any common configurations that are at risk?
Re: Ambiguities in TCP/IP - firewall bypassing
Alan DeKok wrote: > Benjamin Krueger <[EMAIL PROTECTED]> wrote: > > > [snip RFC 1025 (TCP and IP bake-off)] > > > > Identify what the packet should be, and treat it as such? If that is > > the correct way to handle these packets, then these stacks are correct. > > So... what should the packet be? As I said, the spec is ambiguous. > If you don't know what the packet is, you obviously don't know how to > treat it. Think of ECN; should older stacks simply reject a packet with Syn+0x42 because they don't know what 0x42 is? If I've understood correctly, you were suggesting to drop "bad" packets. I agree; only let established traffic through your firewall, and only let packets with Syn or Syn+Ack set and with Fin and Rst unset establish state in the firewall. Ignore the rest of the flags. Of course, if anyone finds this un-interoperable, please chime in!
RE: Ambiguities in TCP/IP - firewall bypassing
An interesting point, T/TCP does indeed require multiple flags to be set simultaneously, however, it's also not a proven protocol. In fact there are potential security issues Apart from the potential DoS (re-introducing SYN floods to some environments) it's not clear how all IP stacks will respond to these packets. There's also a clear security issue with allowing one side of the handshake to send commands before the handshake's been completed - with standard TCP/IP it's relatively easy to spoof the source IP for the SYN but this doesn't get the perpetrator very far - with T/TCP a spoofed SYN could actually send a command which may be actioned if the target host only uses the source IP as validation (such as rlogin/rsh). This last matter isn't a show stopper, I don't allow rlogin etc - and if I did it would only be for addresses that can only be internal (the firewall would prevent external devices from spoofing such addresses). But this is just one example of a new security hole being opened by T/TCP...Ever cautious, I'm inclined to block this traffic and see what else turns up as the protocol matures. If anything, this reaffirms my belief in blocking any unexpected traffic (allow it only when it becomes clear that it must be allowed through, and only after making sure that new security holes aren't being introduced) While on the subject, have there been any moves to ramp up the acceptance of T/TCP, I can see that there are distinct performance advantages for HTTP? -Original Message- From: Alun Jones [mailto:alun@;texis.com] Sent: 18 October 2002 22:28 To: [EMAIL PROTECTED] Subject: Re: Ambiguities in TCP/IP - firewall bypassing At 03:55 PM 10/18/2002, Benjamin Krueger wrote: > One could also make a case for continuing to abide by the cardinal >rule "Be permissive in what you accept, and strict in what you send". >Tough call, but its difficult to justify describing stacks that are >permissive as "highly bogus" or "lazy" given that being permissive in >what you accept is an established notion. If a usage makes any kind of sense, then it has usually been allowed. >Compliant by the letter, if questionably in spirit. I'm not aware of any >tcp client systems that would send SynFin in the real world, so a stack >that responded with RST could arguably be "more" correct (for example). Not necessarily. Have you heard of T/TCP? Before that was around, I remember hearing discussion of using a packet with SYN, FIN, and data all in one, to cut down on round-trips in really short communications, while still providing reliability. One of the lessons you learn when writing / reading RFC material is that "there are more things on heaven and earth, Horatio, than are dreamt of in your philosophy" (or thereabouts). Just because _you_ don't see a use for a feature, that doesn't mean to say that someone else won't / can't, and specifically, it isn't usually worth limiting a protocol for the rather arbitrary reason that you can't see how a feature would be used. Alun. -- Texas Imperial Software | Try WFTPD, the Windows FTP Server. Find us at 1602 Harvest Moon Place | http://www.wftpd.com or email [EMAIL PROTECTED] Cedar Park TX 78613-1419 | VISA/MC accepted. NT-based sites, be sure to Fax/Voice +1(512)258-9858 | read details of WFTPD Pro for NT.
Re: Ambiguities in TCP/IP - firewall bypassing
On Sat, 19 Oct 2002, Florian Weimer wrote: > > As a result of this bug, it's quite complicated (if not impossible in > some configurations) to properly filter connection attempts to Linux > hosts on Cisco IOS routers. Actually, not really provided you are IOS 11.3 or higher. > If your access list is a whitelist with a "permit tcp any any > established" statement somewhere, it's very likely that you can bypass > the filter just by setting the RST in the initial SYN packet True, which is why if you are relying on ACL's as your only line of defense you are better off doing a: ip access-list extended filterout permit tcp 219.80.71.0 0.0.0.255 any reflect tcp-state ip access-list extended filterin evaluate tcp-state Yes you will take a bigger performance hit with reflexive filters, but it's worth it if it's your only line of defense. HTH, C
Re: Ambiguities in TCP/IP - firewall bypassing
Paul Starzetz <[EMAIL PROTECTED]> writes: > * Linux 2.4.19 > > The examination of the source code of the TCP engine reveals that a > TCP connection can be opened by any combination of the TCP flags > having the SYN bit set and the ACK bit reset. For example we can open > a TCP connection by sending an obviously bogus SYN,RST packet: > > 14:25:43.97 192.168.1.184.12345 > 192.168.1.111.: SR > 420:420(0) win 512 (DF) [tos 0x18] > 14:25:43.889143 192.168.1.111. > 192.168.1.184.12345: S > 2168208394:2168208394(0) ack 421 win 5840 (DF) As a result of this bug, it's quite complicated (if not impossible in some configurations) to properly filter connection attempts to Linux hosts on Cisco IOS routers. If your access list is a whitelist with a "permit tcp any any established" statement somewhere, it's very likely that you can bypass the filter just by setting the RST in the initial SYN packet, as described above. The router will forward the packet, and the Linux host will happily initiate the three-way handshake. "established" in Cisco parlance does not mean "SYN unset", but "ACK or RST set". This means that the impact for non-Linux hosts (which do not react to SYN-RST packets according to Paul's survey) is less severe if your filters run IOS. -- Florian Weimer[EMAIL PROTECTED] University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT fax +49-711-685-5898
Re: Ambiguities in TCP/IP - firewall bypassing
* Alan DeKok ([EMAIL PROTECTED]) [021018 13:21]: > Paul Starzetz <[EMAIL PROTECTED]> wrote: > > There are ambiguities in implementations of the TCP/IP suite for various > > operating systems. > > What about the specifications? > > In my (admittedly quick) readings of RFC 793 and RFC 1122, I don't > see any text forbidding the use of other flags, in conjunction with > SYN, when opening a new connection. Even RFC 2525 (Known TCP > Implementation Problems) doesn't appear to cover this issue. > > RFC 1025 (TCP and IP bake-off) has the following text: > > 10 points for correctly being able to process a "Kamikaze" > packet (AKA nastygram, christmas tree packet, lamp test > segment, et al.). That is, correctly handle a segment with > the maximum combination of features at once (e.g., a SYN URG > PUSH FIN segment with options and data). > > > But it doesn't define what it means by "correctly handle" such a > packet. Identify what the packet should be, and treat it as such? If that is the correct way to handle these packets, then these stacks are correct. > The TCP state machine diagram has labels naming the flags on > transitions from 'listen' to 'syn received', but it's silent on the > topic of which flags are NOT allowed. It does, however, consistantly refer to packets as "Syn" or "SynAck" or "Fin" packets, suggesting that only a specific flag or combination of flags should be used during the connection. One could also make a case for continuing to abide by the cardinal rule "Be permissive in what you accept, and strict in what you send". Tough call, but its difficult to justify describing stacks that are permissive as "highly bogus" or "lazy" given that being permissive in what you accept is an established notion. > > We believe that the flaws we have detected have a big impact on > > design of firewalls and packet filters since an improper implementation > > can easily lead to serious security problems. > > I believe that all of the implementations you named are "compliant" > with the ambiguous TCP specification. Compliant by the letter, if questionably in spirit. I'm not aware of any tcp client systems that would send SynFin in the real world, so a stack that responded with RST could arguably be "more" correct (for example). > > The ambiguities can be used to bypass/tunnel firewalls filtering TCP > > packets according to the TCP flags set. Especially stateless firewalls > > simply comparing the flags field with some expected value(s) to > > distinguish between synchronization packets and packet from an already > > open connection can be easily bypassed just by sending a bogus > > synchronization packet to a listening port. > > Then the firewall is too permissive. The people who designed it > either did not understand TCP, or knowingly made the rules too > permissive, or were stuck with a marketing department which required > this insecure behaviour. :( > > > The currently deployed TCP stacks seem to be highly bogus and lazy > > implemented. > > One method around that would be to have a complete TCP > specification via finite state machines. Such a state machine can > then be analyzed, and proven to be correct under whatever definitions > of "correct" you choose. > > I believe this has been tried, but I don't know that anyone has been > successful at it yet. Even the normal "state machine" diagram used to > explain TCP is very high-level, and misses many of the implementation > details and requirements. > > Alan DeKok. -- Benjamin Krueger Send mail w/ subject 'send public key' or query for (0x251A4B18) Fingerprint = A642 F299 C1C1 C828 F186 A851 CFF0 7711 251A 4B18
Re: Ambiguities in TCP/IP - firewall bypassing
At 03:55 PM 10/18/2002, Benjamin Krueger wrote: One could also make a case for continuing to abide by the cardinal rule "Be permissive in what you accept, and strict in what you send". Tough call, but its difficult to justify describing stacks that are permissive as "highly bogus" or "lazy" given that being permissive in what you accept is an established notion. If a usage makes any kind of sense, then it has usually been allowed. Compliant by the letter, if questionably in spirit. I'm not aware of any tcp client systems that would send SynFin in the real world, so a stack that responded with RST could arguably be "more" correct (for example). Not necessarily. Have you heard of T/TCP? Before that was around, I remember hearing discussion of using a packet with SYN, FIN, and data all in one, to cut down on round-trips in really short communications, while still providing reliability. One of the lessons you learn when writing / reading RFC material is that "there are more things on heaven and earth, Horatio, than are dreamt of in your philosophy" (or thereabouts). Just because _you_ don't see a use for a feature, that doesn't mean to say that someone else won't / can't, and specifically, it isn't usually worth limiting a protocol for the rather arbitrary reason that you can't see how a feature would be used. Alun. -- Texas Imperial Software | Try WFTPD, the Windows FTP Server. Find us at 1602 Harvest Moon Place | http://www.wftpd.com or email [EMAIL PROTECTED] Cedar Park TX 78613-1419 | VISA/MC accepted. NT-based sites, be sure to Fax/Voice +1(512)258-9858 | read details of WFTPD Pro for NT.
Ambiguities in TCP/IP - firewall bypassing
1. Abstract --- There are ambiguities in implementations of the TCP/IP suite for various operating systems. Even if this fact has been used since a long time in different software for OS fingerprinting, no real attempt has been made to identify the security impact of the differences in the TCP/IP semantics. We have done some research on the TCP/IP connection open semantics which is of course very important for security of networked systems. We believe that the flaws we have detected have a big impact on design of firewalls and packet filters since an improper implementation can easily lead to serious security problems. 2. Details -- The TCP/IP protocol stack offers a three way handshake for connection oriented communication using the TCP protocol. Basically, a connection can be opened by sending a synchronization packet to a listening service on a particular host. The host will respond with a synchronization acknowledgment packet which in turn must be acknowledged by the requesting host. Then, the connection is considered to be open (at least at the transport layer) and the two hosts may exchange some data. The three way handshake is an essential part of the communication using the TCP protocol. Therefore many packet filter firewalls try to prevent the three way handshake from completion in order to protect an internal/corporate network from being accessed from the outside. Of course, statefull firewalls may have some more sophisticated mechanism. We have found a very ambiguous behavior of TCP/IP implementations while doing some research on the connection request phase. Below you will find the findings about various OSes, however the list should not be considered complete. We have used the NemesisTCP tool [1] to generate the traffic and tcpdump to capture the responses. * The normal behavior (of all OSes) is like this: 14:18:00.595517 192.168.1.184.12345 > 192.168.1.111.: S 420:420(0) win 512 (DF) [tos 0x18] 14:18:00.595731 192.168.1.111. > 192.168.1.184.12345: S 1679763291:1679763291(0) ack 421 win 5840 (DF) The first host sends a SYN packet from port 12345 to a service on port and receives a SYN,ACK * Linux 2.4.19 The examination of the source code of the TCP engine reveals that a TCP connection can be opened by any combination of the TCP flags having the SYN bit set and the ACK bit reset. For example we can open a TCP connection by sending an obviously bogus SYN,RST packet: 14:25:43.97 192.168.1.184.12345 > 192.168.1.111.: SR 420:420(0) win 512 (DF) [tos 0x18] 14:25:43.889143 192.168.1.111. > 192.168.1.184.12345: S 2168208394:2168208394(0) ack 421 win 5840 (DF) or something called 'Christmas packet' having mostly every TCP flag set (except the ACK flag of course): 14:30:46.341732 192.168.1.184.12345 > 192.168.1.111.: SFRP 420:420(0) win 512 urg 8 (DF) [tos 0x18] 14:30:46.342444 192.168.1.111. > 192.168.1.184.12345: S 2492223280:2492223280(0) ack 421 win 5840 (DF) Also SYN,FIN packets works well... * Solaris 5.8 Here we have success by sending SYN,FIN packets: 14:33:24.549246 192.168.1.184.12345 > 192.168.1.84.: SF 420:420(0) win 512 (DF) [tos 0x18] 14:33:24.549757 192.168.1.84. > 192.168.1.184.12345: S 913533039:913533039(0) ack 421 win 24656 (DF) or SYN,FIN,PSH packets with no payload 14:35:14.398346 192.168.1.184.12345 > 192.168.1.84.: SFP 420:420(0) win 512 (DF) [tos 0x18] 14:35:14.398801 192.168.1.84. > 192.168.1.184.12345: S 940377913:940377913(0) ack 421 win 24656 (DF) other combinations don't seem to induce the SynSent state in the TCP/IP stack * FreeBSD 4.5 Here we also have luck with SYN,FIN packets: 14:47:21.558541 192.168.1.184.12345 > 192.168.1.104.: SF 420:420(0) win 512 (DF) [tos 0x18] 14:47:21.558719 192.168.1.104. > 192.168.1.184.12345: S 127436:127436(0) ack 421 win 65535 as well as with other combinations which don't combine the RST and/or ACK flag with SYN: 14:48:11.678246 192.168.1.184.12345 > 192.168.1.104.: SP 420:420(0) win 512 (DF) [tos 0x18] 14:48:11.678366 192.168.1.104. > 192.168.1.184.12345: S 1714046856:1714046856(0) ack 421 win 65535 * Windows NT 4.0 As in the case of BSD we can open connections using any combination of TCP flags as long as we do not set the RST and/or ACK flag (where did they take the code from...hm...): 14:59:46.315126 192.168.1.184.12345 > 192.168.1.17.: SF 420:420(0) win 512 (DF) [tos 0x18] 14:59:46.315566 192.168.1.17. > 192.168.1.184.12345: S 15062452:15062452(0) ack 421 win 8576 (DF) Other OSes than those tested above are expected to behave in a similar manner after obtaining such a discouraging result... 3. Impact - The ambiguities can be used to bypass/tunnel firewalls filtering TCP packets according to the TCP flags set. Especially stateless firewalls simply comparing the flags field with some expected value(s) to distinguish between synchronization
