Bug#626524: proftpd-basic: DefaultAddress 127.0.0.1 not obeyed

[Hilmar Preuße]

On 12.05.2011 18:23, Andrei Caraman wrote:

Hi Andrei,

> Package: proftpd-basic
> Version: 1.3.3a-6squeeze1
> Severity: grave
> Tags: security
> Justification: user security hole
> 
https://bugs.debian.org/626524

Please read below.

> After adding the "DefaultAddress 127.0.0.1" in the server config section and
> restarting proftpd-basic, I can see 
> 
> # /etc/init.d/proftpd restart
> Stopping ftp server: proftpd.
> Starting ftp server: proftpd - setting default address to 127.0.0.1
> .
> 
> However, a quick "netstat -tlpe" after that shows 
> 
> # netstat -tlpe
> Active Internet connections (only servers)
> Proto Recv-Q Send-Q Local Address           Foreign Address         State   User       Inode       PID/Program name
> tcp        0      0 *:ftp                   *:*                     LISTEN  proftpd    2207704     1739/proftpd: (acce
> 
> and I have confirmed I get the initial username/password dialog when
> connecting from a remote client.
> 
> This has the potential of creating a false sense of security for the
> administrator:  we see the message about setting the default address to
> 127.0.0.1 and we expect no remote client can connect, when in fact anyone
> can.  
> TJ finally clarified:

<snip>
If you are have:

  SocketBindTight on

And proftpd receives a connection for which there is no <VirtualHost>
configured, the client will receive this response

  500 Sorry, no server available to handle request on xxx.xxx.xxx.xxx.

EXCEPT if your proftpd.conf has "DefaultServer on" somewhere. If
DefaultServer IS used, then that <VirtualHost> (or "server config")
section bearing the "DefaultServer on" setting is used to handle that
connection -- that's what the DefaultServer directive is for.

Thus if your "SocketBindTight on" configuration is not causing clients
to receive the "no server available to handle request" when they try to
connect to an unconfigured IP address/port, then it says that your
proftpd.conf is using DefaultServer somewhere.
<snip>

..to clarify, why the 500 error messages are missing. So are we all set?
Can we close that non-bug?

Hilmar
-- 
#206401 http://counter.li.org