81646 2002-10-18 21:15 /156 rader/ Paul Starzetz <paul@starzetz.de>
Importerad: 2002-10-18 21:15 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <2008>
Ärende: 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.9999: S 420:420(0)
win 512 (DF) [tos 0x18]
14:18:00.595731 192.168.1.111.9999 > 192.168.1.184.12345: S
1679763291:1679763291(0) ack 421 win 5840 <mss 1460> (DF)
The first host sends a SYN packet from port 12345 to a service on port
9999 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.888897 192.168.1.184.12345 > 192.168.1.111.9999: SR
420:420(0) win 512 (DF) [tos 0x18] 14:25:43.889143
192.168.1.111.9999 > 192.168.1.184.12345: S 2168208394:2168208394(0)
ack 421 win 5840 <mss 1460> (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.9999: SFRP
420:420(0) win 512 urg 8 (DF) [tos 0x18]
14:30:46.342444 192.168.1.111.9999 > 192.168.1.184.12345: S
2492223280:2492223280(0) ack 421 win 5840 <mss 1460> (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.9999: SF 420:420(0)
win 512 (DF) [tos 0x18]
14:33:24.549757 192.168.1.84.9999 > 192.168.1.184.12345: S
913533039:913533039(0) ack 421 win 24656 <mss 1460> (DF)
or SYN,FIN,PSH packets with no payload
14:35:14.398346 192.168.1.184.12345 > 192.168.1.84.9999: SFP
420:420(0) win 512 (DF) [tos 0x18] 14:35:14.398801 192.168.1.84.9999
> 192.168.1.184.12345: S 940377913:940377913(0) ack 421 win 24656
<mss 1460> (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.9999: SF
420:420(0) win 512 (DF) [tos 0x18] 14:47:21.558719
192.168.1.104.9999 > 192.168.1.184.12345: S 1333327436:1333327436(0)
ack 421 win 65535 <mss 1460>
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.9999: SP
420:420(0) win 512 (DF) [tos 0x18] 14:48:11.678366
192.168.1.104.9999 > 192.168.1.184.12345: S 1714046856:1714046856(0)
ack 421 win 65535 <mss 1460>
* 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.9999: SF 420:420(0)
win 512 (DF) [tos 0x18]
14:59:46.315566 192.168.1.17.9999 > 192.168.1.184.12345: S
15062452:15062452(0) ack 421 win 8576 <mss 1460> (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 packets and packet from an already
open connection can be easily bypassed just by sending a bogus
synchronization packet to a listening port. The currently deployed TCP
stacks seem to be highly bogus and lazy implemented.
Administrators of firewall devices should set up some filtering rules
to drop bogus TCP packets as mentioned above. For example on systems
using iptables to filter packets bogus packets can be easily
distinguished by following rules:
iptables -A INPUT -p tcp -d HOST/MASK --tcp-flags SYN,FIN SYN,FIN -j
LOG -m limit --limit 10/m --log-level "LOGLEVEL" --log-prefix="bogus
packet" $IP -A INPUT -p tcp -d HOST/MASK --tcp-flags SYN,FIN SYN,FIN
-j DROP
and so on for other flag combinations.
4. References
-------------
[1] NemesisTCP: http://online.securityfocus.com/tools/1278
[2] Packet normalization:
http://www.icir.org/vern/papers/norm-usenix-sec-01-html
(81646) /Paul Starzetz <paul@starzetz.de>/(Ombruten)
Bilaga (text/plain) i text 81647
81647 2002-10-18 21:15 /95 rader/ Paul Starzetz <paul@starzetz.de>
Bilagans filnamn: "tcpamb2.txt"
Importerad: 2002-10-18 21:15 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <2009>
Bilaga (text/plain) till text 81646
Ärende: Bilaga (tcpamb2.txt) till: 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.9999: S 420:420(0) win 512 (DF) [tos 0x18]
14:18:00.595731 192.168.1.111.9999 > 192.168.1.184.12345: S 1679763291:1679763291(0) ack 421 win 5840 <mss 1460> (DF)
The first host sends a SYN packet from port 12345 to a service on
port 9999 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.888897 192.168.1.184.12345 > 192.168.1.111.9999: SR 420:420(0) win 512 (DF) [tos 0x18]
14:25:43.889143 192.168.1.111.9999 > 192.168.1.184.12345: S 2168208394:2168208394(0) ack 421 win 5840 <mss 1460> (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.9999: SFRP 420:420(0) win 512 urg 8 (DF) [tos 0x18]
14:30:46.342444 192.168.1.111.9999 > 192.168.1.184.12345: S 2492223280:2492223280(0) ack 421 win 5840 <mss 1460> (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.9999: SF 420:420(0) win 512 (DF) [tos 0x18]
14:33:24.549757 192.168.1.84.9999 > 192.168.1.184.12345: S 913533039:913533039(0) ack 421 win 24656 <mss 1460> (DF)
or SYN,FIN,PSH packets with no payload
14:35:14.398346 192.168.1.184.12345 > 192.168.1.84.9999: SFP 420:420(0) win 512 (DF) [tos 0x18]
14:35:14.398801 192.168.1.84.9999 > 192.168.1.184.12345: S 940377913:940377913(0) ack 421 win 24656 <mss 1460> (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.9999: SF 420:420(0) win 512 (DF) [tos 0x18]
14:47:21.558719 192.168.1.104.9999 > 192.168.1.184.12345: S 1333327436:1333327436(0) ack 421 win 65535 <mss 1460>
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.9999: SP 420:420(0) win 512 (DF) [tos 0x18]
14:48:11.678366 192.168.1.104.9999 > 192.168.1.184.12345: S 1714046856:1714046856(0) ack 421 win 65535 <mss 1460>
* 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.9999: SF 420:420(0) win 512 (DF) [tos 0x18]
14:59:46.315566 192.168.1.17.9999 > 192.168.1.184.12345: S 15062452:15062452(0) ack 421 win 8576 <mss 1460> (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 packets and packet
from an already open connection can be easily bypassed just by
sending a bogus synchronization packet to a listening port. The
currently deployed TCP stacks seem to be highly bogus and lazy
implemented.
Administrators of firewall devices should set up some filtering rules
to drop bogus TCP packets as mentioned above. For example on systems
using iptables to filter packets bogus packets can be easily
distinguished by following rules:
iptables -A INPUT -p tcp -d HOST/MASK --tcp-flags SYN,FIN SYN,FIN -j
LOG -m limit --limit 10/m --log-level "LOGLEVEL" --log-prefix="bogus
packet" $IP -A INPUT -p tcp -d HOST/MASK --tcp-flags SYN,FIN SYN,FIN
-j DROP
and so on for other flag combinations.
4. References
-------------
[1] NemesisTCP: http://online.securityfocus.com/tools/1278 [2] Packet
normalization: http://www.icir.org/vern/papers/norm-usenix-sec-01-html
(81647) /Paul Starzetz <paul@starzetz.de>/(Ombruten)
81649 2002-10-18 22:20 /61 rader/ Alan DeKok <aland@ox.org>
Importerad: 2002-10-18 22:20 av Brevbäraren
Extern mottagare: Paul Starzetz <paul@starzetz.de>
Mottagare: Bugtraq (import) <2011>
Ärende: Re: Ambiguities in TCP/IP - firewall bypassing
------------------------------------------------------------
Paul Starzetz <paul@starzetz.de> 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.
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.
> 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.
> 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.
(81649) /Alan DeKok <aland@ox.org>/-----------------
81651 2002-10-18 23:06 /85 rader/ Benjamin Krueger <benjamin@seattleFenix.net>
Importerad: 2002-10-18 23:06 av Brevbäraren
Extern mottagare: Alan DeKok <aland@ox.org>
Externa svar till: benjamin@seattleFenix.net
Mottagare: Bugtraq (import) <2013>
Ärende: Re: Ambiguities in TCP/IP - firewall bypassing
------------------------------------------------------------
* Alan DeKok (aland@ox.org) [021018 13:21]:
> Paul Starzetz <paul@starzetz.de> 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
(81651) /Benjamin Krueger <benjamin@seattleFenix.net>/(Ombruten)
81654 2002-10-19 01:03 /35 rader/ Alun Jones <alun@texis.com>
Importerad: 2002-10-19 01:03 av Brevbäraren
Extern mottagare: benjamin@seattleFenix.net
Mottagare: Bugtraq (import) <2016>
Ärende: 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 alun@texis.com
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.
(81654) /Alun Jones <alun@texis.com>/-----(Ombruten)
81668 2002-10-19 05:34 /67 rader/ Alan DeKok <aland@ox.org>
Importerad: 2002-10-19 05:34 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <2029>
Ärende: Re: Ambiguities in TCP/IP - firewall bypassing
------------------------------------------------------------
Benjamin Krueger <benjamin@seattlefenix.net> wrote:
...
> > 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.
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.
Sure, the spec *says* to treat packets with the SYN flag in a
certain way. I'm not arguing with that. What I'm arguing with is the
concept that because the spec is MISSING text on what to do in other
situations, that we know what to do in those situations.
The spec is silent on the use of ambiguous or contradictory flags
(SYN+FIN). So what happens when such a packet is received can only be
described as "implementation defined."
This is not the way to have a secure, or inter-operable protocol.
> > 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.
So SYN+URG is disallowed. But to me, that combination seems
reasonable. So my implementation may not inter-operate with yours.
At the least, we're making different assumptions, which leads to
security problems.
As I said, the spec is ambiguous.
> 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.
Well, at least I didn't say that.
> > 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).
<g> I may believe otherwise. Who's to say what's compliant, if the
definition of "compliance" isn't written down anywhere?
Alan DeKok.
(81668) /Alan DeKok <aland@ox.org>/-----------------
81676 2002-10-19 21:36 /82 rader/ John Fitzgerald <john@match-fit.com>
Importerad: 2002-10-19 21:36 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <2034>
Ärende: 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: benjamin@seattleFenix.net
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 alun@texis.com
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.
(81676) /John Fitzgerald <john@match-fit.com>/(Ombruten)
81677 2002-10-19 21:42 /21 rader/ Luis Bruno <lbruno@zbit.pt>
Importerad: 2002-10-19 21:42 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <2035>
Ärende: Re: Ambiguities in TCP/IP - firewall bypassing
------------------------------------------------------------
Alan DeKok wrote:
> Benjamin Krueger <benjamin@seattlefenix.net> 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!
(81677) /Luis Bruno <lbruno@zbit.pt>/-----(Ombruten)
81843 2002-10-21 18:44 /31 rader/ Lyndon Nerenberg <lyndon@orthanc.ab.ca>
Importerad: 2002-10-21 18:44 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <2049>
Ärende: 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
(81843) /Lyndon Nerenberg <lyndon@orthanc.ab.ca>/(Ombruten)
81940 2002-10-22 18:02 /208 rader/ Ofir Arkin <ofir@sys-security.com>
Importerad: 2002-10-22 18:02 av Brevbäraren
Extern mottagare: 'Paul Starzetz' <paul@starzetz.de>
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <2063>
Ärende: 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 [ofir@sys-security.com]
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: bugtraq@securityfocus.com
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.9999: S 420:420(0)
win 512 (DF) [tos 0x18]
14:18:00.595731 192.168.1.111.9999 > 192.168.1.184.12345: S
1679763291:1679763291(0) ack 421 win 5840 <mss 1460> (DF)
The first host sends a SYN packet from port 12345 to a service on port
9999 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.888897 192.168.1.184.12345 > 192.168.1.111.9999: SR
420:420(0) win 512 (DF) [tos 0x18] 14:25:43.889143
192.168.1.111.9999 > 192.168.1.184.12345: S 2168208394:2168208394(0)
ack 421 win 5840 <mss 1460> (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.9999: SFRP
420:420(0) win 512 urg 8 (DF) [tos 0x18]
14:30:46.342444 192.168.1.111.9999 > 192.168.1.184.12345: S
2492223280:2492223280(0) ack 421 win 5840 <mss 1460> (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.9999: SF 420:420(0)
win 512 (DF) [tos 0x18]
14:33:24.549757 192.168.1.84.9999 > 192.168.1.184.12345: S
913533039:913533039(0) ack 421 win 24656 <mss 1460> (DF)
or SYN,FIN,PSH packets with no payload
14:35:14.398346 192.168.1.184.12345 > 192.168.1.84.9999: SFP
420:420(0) win 512 (DF) [tos 0x18] 14:35:14.398801 192.168.1.84.9999
> 192.168.1.184.12345: S 940377913:940377913(0) ack 421 win 24656
<mss 1460> (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.9999: SF
420:420(0) win 512 (DF) [tos 0x18] 14:47:21.558719
192.168.1.104.9999 > 192.168.1.184.12345: S 1333327436:1333327436(0)
ack 421 win 65535 <mss 1460>
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.9999: SP
420:420(0) win 512 (DF) [tos 0x18] 14:48:11.678366
192.168.1.104.9999 > 192.168.1.184.12345: S 1714046856:1714046856(0)
ack 421 win 65535 <mss 1460>
* 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.9999: SF 420:420(0)
win 512 (DF) [tos 0x18]
14:59:46.315566 192.168.1.17.9999 > 192.168.1.184.12345: S
15062452:15062452(0) ack 421 win 8576 <mss 1460> (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 packets and packet from an already
open connection can be easily bypassed just by sending a bogus
synchronization packet to a listening port. The currently deployed TCP
stacks seem to be highly bogus and lazy implemented.
Administrators of firewall devices should set up some filtering rules
to
drop bogus TCP packets as mentioned above. For example on systems
using iptables to filter packets bogus packets can be easily
distinguished by following rules:
iptables -A INPUT -p tcp -d HOST/MASK --tcp-flags SYN,FIN SYN,FIN -j
LOG
-m limit --limit 10/m --log-level "LOGLEVEL" --log-prefix="bogus
packet" $IP -A INPUT -p tcp -d HOST/MASK --tcp-flags SYN,FIN SYN,FIN
-j DROP
and so on for other flag combinations.
4. References
-------------
[1] NemesisTCP: http://online.securityfocus.com/tools/1278
[2] Packet normalization:
http://www.icir.org/vern/papers/norm-usenix-sec-01-html
(81940) /Ofir Arkin <ofir@sys-security.com>/(Ombruten)