Ambiguities in TCP/IP - firewall bypassing

Post by Paul Starzetz
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.

Post by Paul Starzetz
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.

Post by Paul Starzetz
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. :(

Post by Paul Starzetz
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

2002-10-18 20:55:15 UTC

Post by Paul Starzetz
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.
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.

Post by Alan DeKok
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.

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).

Post by Paul Starzetz
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

Alan DeKok

2002-10-18 21:06:23 UTC

Benjamin Krueger <***@seattlefenix.net> wrote:
...

Post by Alan DeKok
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.

Post by Alan DeKok
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.

Post by Benjamin Krueger
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.

Post by Alan DeKok
I believe that all of the implementations you named are "compliant"
with the ambiguous TCP specification.

<g> I may believe otherwise. Who's to say what's compliant, if the
definition of "compliance" isn't written down anywhere?

Alan DeKok.

Luis Bruno

2002-10-19 06:04:27 UTC

[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!

Tony Finch

2002-10-19 01:33:57 UTC

Post by Alun Jones
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 <***@dotat.at> http://dotat.at/
FORTIES CROMARTY FORTH TYNE DOGGER: NORTHWESTERLY 4 OR 5, OCCASIONALLY 6.
SHOWERS. GOOD.

Alun Jones

2002-10-18 21:28:25 UTC

If a usage makes any kind of sense, then it has usually been allowed.

Post by Benjamin Krueger
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 ***@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.

John Fitzgerald

2002-10-19 11:42:07 UTC

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:***@texis.com]
Sent: 18 October 2002 22:28
To: ***@seattleFenix.net
Subject: Re: Ambiguities in TCP/IP - firewall bypassing

If a usage makes any kind of sense, then it has usually been allowed.

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 ***@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.

Florian Weimer

2002-10-18 23:03:47 UTC

Post by Paul Starzetz
* 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
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)

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 ***@CERT.Uni-Stuttgart.DE
University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT fax +49-711-685-5898

c***@slartibartfast.pa.net

2002-10-19 17:20:47 UTC

Post by Florian Weimer
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.

Post by Florian Weimer
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

Aaron Hopkins

2002-10-19 08:24:39 UTC

"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

Florian Weimer

2002-10-21 09:50:42 UTC

Post by Aaron Hopkins

This is true for IOS up through 11.3. The 12.0, 12.1, and 12.2
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.

Post by Aaron Hopkins
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).

Post by Aaron Hopkins
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 ***@CERT.Uni-Stuttgart.DE
University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT fax +49-711-685-5898

David Wagner

2002-10-19 00:18:50 UTC

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?

Lyndon Nerenberg

2002-10-20 19:03:25 UTC

Post by Luis Bruno
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

Ofir Arkin

2002-10-21 12:17:52 UTC