[27569] in bugtraq
Re: Ambiguities in TCP/IP - firewall bypassing
daemon@ATHENA.MIT.EDU (Florian Weimer)
Wed Oct 23 00:44:03 2002
To: Aaron Hopkins <lists@die.net>
From: Florian Weimer <Weimer@CERT.Uni-Stuttgart.DE>
Date: Mon, 21 Oct 2002 11:50:42 +0200
In-Reply-To: <Pine.LNX.4.44.0210190026480.18964-100000@asherah.die.net> (Aaron
Hopkins's message of "Sat, 19 Oct 2002 01:24:39 -0700 (PDT)")
Message-ID: <87znt8ktn1.fsf@Login.CERT.Uni-Stuttgart.DE>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Aaron Hopkins <lists@die.net> 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 Weimer@CERT.Uni-Stuttgart.DE
University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT fax +49-711-685-5898
