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 space
RFC 959 section 4.2:
...
the beginning of a line, and ignore all intermediary lines. If
an intermediary line begins with a 3-digit number, the Server
must pad the front to avoid confusion.
Another note is that the FW1 patch probably cannot be used if the FTP
server uses welcome messages. Welcome messages are large replies on the
control channel, and will quite likely exceed the MTU restriction.
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
* and that the TCP byte immediately in front of the response code is a
newline, not a space or anything else. Not sure if this is possible in
the FW1 filter engine. Also, this won't help in the case of buggy
wuftpd.
* The firewall should also obviously only listen for a 227 reply if a
PASV command has been sent. Any 227 replies received outside this
context is an protocol violation and should be handled as such.
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.
I would also expect some proxy based firewalls to be have problems with
this bug, and even more so than packet inspecting firewalls. Proxy based
firewalls looks at the FTP protocol TCP stream and doesn't usually care
about packet boundaries. The reply from wuftpd STAT can be forged to
look like a seeminly valid FTP control reply.
--
Henrik Nordstrom
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:35:04 PDT