Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 25 May 2010 02:03:16 -0700
From: Paul Lesniewski <>
To: Thijs Kinkhorst <>
	Max Olsterd <>,
Subject: Re: [SquirrelMail-Security] CVE Request for Horde and 

On Sun, May 23, 2010 at 5:39 AM, Thijs Kinkhorst <> wrote:
> On sneon 22 Maaie 2010, Max Olsterd wrote:
>> But someone gave me an explanation, with a live hacking demo, and it was
>> awesome : this guy has been able to scan the LAN of an international ISP
>> whereas there was a firewall blocking incoming packets to the LAN (DMZ +
>> internal LAN) !!!
>> How ?
>> He had an account on the squirrelmail (ISP) and he has been able to create
>> an exploit for the advisory we are talking about here. Thanks to that, he
>> asked squirrelmail to scan some ranges of IP addresses that were private
>> (10.x.x.x) and unreachable from the outside of this ISP (NAT). Then he
>> found multiple interesting hosts with unpatched services, which gave him
>> an idea of how secure it was for real when you are inside. He also used
>> the DNS scanning attack that was described in the slides of HITB, by
>> bruteforcing names, and he found other IP addresses (but a firewall
>> blocked the scan so deep on the LAN).
> That this is possible is inherent in providing the ability to your users to
> configure any POP3 server they want to retreive email. The whole idea of the
> POP3 fetch mail plugin is to allow to connect to other servers. And hence if
> you want to provide this functionality there will always be the possibility
> that someone connects to a local machine, and there's no real solution to that
> given the premise.

But there *is* a solution to the fact that they can connect to *any*
port on a local machine using this method.  There isn't really a good
reason not to simply restrict the port number to the standard POP3
port, which would then remove the possibility that someone can use
SquirrelMail to port-scan your internal network.  The next release of
SquirrelMail will do just that, and provide administrators a
configuration option where they can add other allowable port numbers,
or open it back up to any and all port numbers if they so feel they
need to.

> It is a choice to not patch internal services but any
> adminsitrator has the responsibility to determine what 'internal' means and
> who will have access to this network.
> And note that still the only thing you, as an authenticated user, can do is
> connect to those ports within a POP3 context.

Indeed, however, a port scan is still more than some administrators want.

> The only new idea that this research adds, is that they've scripted the
> changing of the pop3 server info so they can increase the amount of
> hosts/ports to connect to in a given timeframe. But even if this wouldn't be
> scriptable, it would still be possible for the user to specify POP3 servers by
> hand (as that is the goal of the plugin) and hence any network setup that
> can't deal with this but does enable the plugin, is broken by design.
> It's only a matter of scaling that they add. Anything that is 'vulnerable'
> with this, is already vulnerable if this scripting wouldn't be possible.

I don't think the question is about whether or not the vulnerability
can be scripted.  The issue is that there *is* a vulnerability at all
(albeit a very minor one).  I have thus applied for a CVE recently and
can report back when I receive it.

Paul Lesniewski
SquirrelMail Team
Please support Open Source Software by donating to SquirrelMail!

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ