As I said in my original posting to vuln-dev:
I think you will find that ALL stateful inspection firewalls
with FTP ALGs that do not reassemble the TCP stream are vulnerable
to this attack.
Jacek Lipkowski wrote:
>
> the recent firewall-1 pasv vulnerability also applies to cisco pix (don't
> kno
the recent firewall-1 pasv vulnerability also applies to cisco pix (don't
know which version - it's not my pix :).
jacek
What follows is a clarification of a statement in the advisory by John
McDonald and Thomas Lopatic which can be retrieved in its entirety from
the BUGTRAQ archive:
http://www.securityfocus.com/templates/archive.pike?list=1&date=2000-02-8&[EMAIL PROTECTED]
Here is the relevant portion:
"FireWal
On Fri, 18 Feb 2000, Mikael Olsson wrote:
> The only solution that even begins to look "good" is to completely
> reassemble the TCP stream and not make "educated" guesses about what
> packet data belongs on what line and in which order and state of the
> FTP protocol.
inspecting TCP application
>a firewall has an icicle's chance in hell of adequately
>mimicking a system it is supposed to protect if it does so purely on
>the assumption that the code it is protecting works "correctly" by
>the firewall developer's interpretation of "correct".
Or, for that matter, by the official protocol s
Mikael Olsson wrote:
>
> The only solution that even begins to look "good" is to
> completely reassemble the TCP stream and not make "educated"
> guesses about what packet data belongs on what line and in
> which order and state of the FTP protocol.
>
> It doesn't have to be a "proxy" in order to
On Wed, 16 Feb 2000, Borbely Zoltan wrote:
> On Mon, Feb 14, 2000 at 07:32:54PM -0600, monti wrote:
> [...snip...]
>
> > First watch for:
> > client -> ftp-server "PASV"
> >
> > which triggers the firewall to look for this immediately afterwards:
> > client <- ftp-server "227 Entering Passive Mod
Henrik Nordstrom wrote:
>
> A in my opinion better approach would be to
> * require that the 227 (PASV) reply is the one and only line present in
> the packet
Attackers can accomplished this by setting the TCP MSS to the right size.
> * that this packet properly ends with a newline
No problem i
> A in my opinion better approach would be to
> * require that the 227 (PASV) reply is the one and only line present in
> the packet
> * that this packet properly ends with a newline
> * that this packet is not oversized for being a 227 reply
Anything that depends for correct operation on where s
<>
> Even with the best firewall in the world, I'm pretty convinced that
> you need an ftp server that implements the FTP protocol correctly
> before you have a hope of handling PASV correctly.
Which is a different way of making the point Greg Hoglund did in a
recent-ish ntbugtraq post (Subject:
monti writes ("Re: FireWall-1 FTP Server Vulnerability"):
> STAT -1
> 213-status of -1:
> .
> ..
> 227 Entering Passive Mode (xxx,xxx,xxx,xxx,0,139)
> [snip]
> 213 End of Status
Strictly speaking, the ftp server is breaking the FTP protocol.
The server is requir
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
> m
monti wrote:
> The attacker then issues something like a 'stat -1 filename',
> and plays
Interesting.. a bug in wuftpd which makes the life a lot more
interesting for the FW1 issue.
The bug is that wuftpd does not pad lines that may be misread as FTP
status codes in multiline responses with a s
The patch described below does not sound as though it will 'fix the
problem'. I could be wrong, but... The enforcement of a newline at the end
of the packet might still open the possibility of exploitation through at
least one method that I can think of off the top of my head.
Possible Example:
On Sat, 12 Feb 2000 [EMAIL PROTECTED] wrote:
> -Original Message-
> From: Check Point Support [mailto:[EMAIL PROTECTED]]
> Sent: 12. februar 2000 06:01
> To: [EMAIL PROTECTED]
> Subject: [FW1] Check Point News Announcement
>
[snip]
> - For those using stateful inspection of passive FTP, t
-Original Message-
From: Check Point Support [mailto:[EMAIL PROTECTED]]
Sent: 12. februar 2000 06:01
To: [EMAIL PROTECTED]
Subject: [FW1] Check Point News Announcement
News Announcement:
http://www.checkpoint.com/techsupport/alerts/pasvftp.html
It has been brought to Check Point's atte
FireWall-1 FTP Server Vulnerability
Background Paper #1, data protect AG
John McDonald <[EMAIL PROTECTED]>
Thomas Lopatic <[EMAIL PROTECTED]>
References
--
Please reference the recent vuln-dev posting by Mikael Olsson entitled,
"Breaking through FTP ALGs -- is it possi
17 matches
Mail list logo
