Message-ID: <4CB919C7.3090705@moritz-naumann.com>
Date: Sat, 16 Oct 2010 05:19:35 +0200
From: Moritz Naumann <security@...itz-naumann.com>
To: Paul Lesniewski <paul@...irrelmail.org>
Cc: full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com,
	Daniel Kobayashi Imori <daniel@...tion.com.br>
Subject: Re: [SquirrelMail-Security] XSS in Squirrelmail plugin 'Virtual Keyboard'
 <= 0.9.1

Hi Paul,

On 16.10.2010 02:44 Paul Lesniewski wrote:
> On Tue, Oct 5, 2010 at 9:28 AM, Moritz Naumann
> <security@...itz-naumann.com> wrote:
>> Squirrelmail plugin 'Virtual Keyboard' version 0.9.1 and lower is
>> vulnerable to cross site scripting (XSS).
[..]
> As a member of the SquirrelMail development team, I am quite
> displeased with this announcement.  

thanks for openly sharing your opinion on this matter.

I guess I have to provide a complete timeline. 'Complete' here, means
from my perspective, since I initially reported the vulnerability and
thus have the responsibility of ensuring it get's published, in time, so
that users are able to patch their vulnerable systems. That's also why
the Full Disclosure Policy [1] requires a steady flow of communication
and information in both directions. Unfortunately, in this case, it was
somewhat one-sided.

May 05, 2010: Moritz reports vulnerability to Daniel and
security-2010@...irrelmail

May 06, 2010: Daniel responds to Moritz and security-2010@...irrelmail,
attaching a fixed version

May 07, 2010: Moritz responds to Daniel and security-2010@...irrelmail,
asking for source code repository or other public storage location

May 07, 2010: Daniel responds to Moritz and security-2010@...irrelmail,
reporting that his account on the squirrelmail.org plugin repository is
disabled and he's trying to get in touch with the Squirrelmail
developers on this

May 07, 2010: Moritz responds to Daniel, stating that (after having
reviewed the new version by Daniel) it should fix the previously
reported vulnerability.

May 10, 2010: Moritz responds to Daniel and security-2010@...irrelmail,
trying to mediate between Daniel and the Squirrelmail developers, in the
interest of getting the security fix out as soon as possible, and
checking with Daniel whether it would be ok to distibute his update by
other means in case his access to the repository cannot be restored in a
timely fashion.

May 10, 2010: Daniel responds to Moritz, giving permission to publish
his work, stating he is awaiting a response by the Squirrelmail Team to
get his plugin repository account reactivated.

May 11, 2010: Paul of Squirrelmail responds to Moritz (for the first
time) and Daniel, stating that the plugin is not conformant with current
Squirrelmail standards, and that he (not the Squirrelmail team as a
whole) will work with Daniel to get the code to release quality, asking
Moritz for patience and  noting that he is "sure [Moritz] will be made
aware of a release".

May 29, 2010: Moritz contacts Daniel, Paul and
security-2010@...irrelmail; not having heard from either Daniel or
anyone from Suqirrelmail for a while, he asks for an update.

May 31, 2010: Daniel responds to Moritz, stating that he is currently ill.

June 01, 2010: Moritz responds to Daniel stating that he will delay the
advisory for another week.

June 02, 2010: Daniel responds to Moritz, Paul and
security-2010@...irrelmail, attaching an improved fixed version

June 07, 2010: Moritz responds to Daniel, Paul and
security-2010@...irrelmail, suggesting that, "unless more changes need
to happen, the Squirrelmail team could probably review and publish"
Daniels new version in their plugin repository.

Oct 05, 2010: Not having heard again from Squirrelmail team or Paul or
Daniel on this matter, realizing that 5 months after the initial report
there is still no security fix available, Moritz publishes an advisory,
including Daniels' fix, in the interest of safeguarding the users of
this plugin (and, yes, for the credit, too).


While I think this timeline puts the handling of this vulnerability in a
different light than your email, I am not going into the details since I
am not interested in extending this discussion - it simply serves no
purpose. My primary interest was in making it possible to fix the
vulnerable installations out there, and this advisory was a result of
it. I would have preferred to see it better handled (and I'm not only
addressing this to you, Paul), but this is not always possible.

If you would like to discuss this further, you are welcome to do so, but
please consider whether it is possible to do this off-list
(I assume only few subscribers, if any, will not consider this
off-topic). I have nothing to hide in this respect, but I also don't
want to annoy people with a mostly - to the general audience of these
mailing lists - irrelevant discussion.

Moritz

[1] http://www.wiretrip.net/rfp/policy.html

Powered by blists - more mailing lists