bugtraq - Re: Extending JavaScript Portscanning to Include Banner Grabbing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <1173169572.10389.17.camel@dapcva>
Date: Tue, 06 Mar 2007 09:26:12 +0100
From: Vincent Archer <varcher@...yall.com>
To: mark <mark@...dshell.net>
Cc: bugtraq@...urityfocus.com
Subject: Re: Extending JavaScript Portscanning to Include Banner Grabbing

On Sun, 2007-03-04 at 17:13 +0000, mark wrote:
> There's a new paper/advisory at: http://bindshell.net/papers/ftppasv
> 
> Here's a quick summary:
> 
> A common implementation flaw in FTP clients allows FTP servers
> to cause clients to connect to other hosts. This seemly small vulnerability
> has some interesting consequences for web browser security (namely in
> Firefox, Opera and Konqueror).
> 
> This paper discusses the FTP client flaw in detail and demonstrates how
> it can be used to attack web browsers...
(snip)

I wouldn't say it's an implementation flaw. As the paper says, it's not
contrary to the RFC; in fact, it's exactly as the RFC says. The
inclusion of the IP in the PASV response is there for a purpose: saying
to the client "connect there, and nowhere else for the content you
requested".

30 years ago, in an era of 1200bps modems and tiny little boxes
connected to those wires, the ability to have completely controllable
data flows that didn't had to go back and forth between multiple clients
and servers was seductive. Of course, as you also remark, there's little
practical use of that feature by today's standards.

If anything, IE's ignorance of the IP is the flaw: it's non conformant.
It also happens to be the more secure behaviour though, so don't expect
me to agitate the flag and insist they conform to standards on this.

The RFC 2428 extended the PASV command to EPSV. EPSV does what you seem
to expect the PASV to do: get a TCP port to connect to, and let the IP
be the same as the control connection. However, not every FTP server
support this, and many firewalls/NAT boxes will fail to detect the
command and will not open the data conduit for the FTP transfer when
thus ordered.

-- 
Vincent ARCHER
varcher@...yall.com

Tel : +33 (0)1 40 07 47 14
Fax : +33 (0)1 40 07 47 27
Deny All - 23, rue Notre Dame des Victoires - 75002 Paris - France