mailing list archives
Re: FireWall-1 FTP Server Vulnerability
From: mouse () RODENTS MONTREAL QC CA (der Mouse)
Date: Thu, 17 Feb 2000 03:49:15 -0500
A in my opinion better approach would be to
* require that the 227 (PASV) reply is the one and only line present in
* 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 segment boundaries
fall in a TCP data stream is broken. Anything. (I haven't been able
to think of any exceptions, at least. I'd welcome any anyone has to
offer.) You cannot depend on ever seeing the entire PASV response in a
single packet; you cannot depend on ever seeing more than one octet of
data per segment. Sure, it's fine to optimize for the case where the
whole thing is in a single packet, since that will be the common case.
But breaking if it's not is, well, broken.
And quite aside from that, you can't depend on much of anything in the
PASV response, as far as I can tell - you certainly can't depend on
being able to parse it mechanically. The only spec I've ever found for
the response is the wording in RFC959, which says only "The response to
this command includes the host and port address this server is
listening on"; it doesn't say anything about how this information is
formatted or whether there may be other information present that
happens to look similar. (At least, that's the best info I have now.
If anyone has pointers to updates that specify otherwise, I'd love to
hear about them.) This is one thing EPSV helps with (see RFC2428).
It is probably not possible to making a 100% secure filter agains
this while having a broken FTP server, at least not without seriously
impairing the use of the server.
It is not possible to put an FTP server behind a NAT box without
breaking something. (The same is true of other protocols that embed IP
addresses in data streams; the only other example that comes to mind
offhand is Quake.) Attempting to kludge around this brokenness by
rewriting data streams in the NAT box, blindly assuming anything to
port 21 is an FTP control connection, is piling brokenness on top of
brokenness, and it's hardly surprising if the house of cards threatens
to come tumbling down.
mouse () rodents montreal qc ca
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: FireWall-1 FTP Server Vulnerability Borbely Zoltan (Feb 16)
Re: FireWall-1 FTP Server Vulnerability Peter Benie (Feb 16)
Re: FireWall-1 FTP Server Vulnerability der Mouse (Feb 17)
Re: FireWall-1 FTP Server Vulnerability chess () US IBM COM (Feb 18)
- DDoS whitepaper, (continued)