[13884] in bugtraq
Re: FireWall-1 FTP Server Vulnerability
daemon@ATHENA.MIT.EDU (Borbely Zoltan)
Thu Feb 17 06:35:47 2000
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-Id: <20000216023505.G751@cheetah.cyberworks.hu>
Date: Wed, 16 Feb 2000 02:35:05 +0100
Reply-To: Borbely Zoltan <bozo@SZIVARVANYNET.HU>
From: Borbely Zoltan <bozo@SZIVARVANYNET.HU>
X-To: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <Pine.BSF.3.96.1000214185206.15092B-100000@mournblade>; from
monti on Mon, Feb 14, 2000 at 07:32:54PM -0600
On Mon, Feb 14, 2000 at 07:32:54PM -0600, monti wrote:
[...snip...]
> I dont really think the issue is with 'how' the PASV response and packet
> appears on the wire, but with the Firewall's logic in creating a hole for
> PASV ftp data connections. I think the firewall should probably be a bit
> more strict about how it makes the decision to open the PASV hole and
> follow rules like the following:
>
> First watch for:
> client -> ftp-server "PASV"
>
> which triggers the firewall to look for this immediately afterwards:
> client <- ftp-server "227 Entering Passive Mode (xxx,xxx,xxx,xxx,prt,prt)
>
> If any other statement is seen from client or server, before the presence
> of the 227 port declaration, the attempt is ignored.
This solution can't block the exploit. In the following case:
C -> S "STAT -1"
S -> C "."
S -> C ".."
C -> S "PASV"
S -> C "227 Entering..."
I know, this is against the RFC, but the SPF firewalls can misinterpret
the whole situation.
The time frame of the successful attack is very small, but maybe you can
try to close the send window of the server. Maybe it works, but this is just
theory.
Zoltan BORBELY
