Re: FWD: Squirrelmail XSS + SQL security bug?
On Mon, Jul 05, 2004 at 01:38:45PM -0700, Matt Zimmerman wrote:
> On Mon, Jul 05, 2004 at 12:05:23PM -0700, email@example.com wrote:
> > Long ago and far away, I sent this message to security@, and a small
> > amount of conversation occured, but I never heard back from Sam Johnston
> > or Matt Zimmerman (the two parties present in the discussion in addition
> > to myself), and I've sent a total of two messages since then to no avail.
> > I'm guessing they are both quite busy and unable to get to it, so I
> > thought I would ask here in case the discussion occured elsewhere and I
> > missed it.
> You did receive responses. In fact, I have in front of me right now at a
> copy of a message from you where you quote _both_ my reply and Sam
> Johnston's. What would you hope to gain by misrepresenting the situation?
You're right; I apologize. I had a serious brain misfire, I was worried about sending that without your permission, but instead I made it sound like I'd received no response. I apologize a second time. Furthermore, I should have been more clear about why I was concerned --- it looked to me that the initial discussion hadn't gotten to more than discussion. And now it is fairly clear to me that there are (as I expected) other issues existing with regard to squirrelmail developers that I don't know. I did, however, send followup messages on 3 June and 29 June to which I have not received a response, and that is why I contacted debian-security@. That said, we have had intermittent power problems, so it is possible that the responses were never delivered, and therefore I will apologize in advance if that is the case.
-----quote original discussion----
Date: Wed, 26 May 2004 17:05:55 +1000
From: Sam Johnston <firstname.lastname@example.org>
To: Matt Zimmerman <email@example.com>
CC: Adam Morley <firstname.lastname@example.org>
Subject: Re: Squirrelmail XSS + SQL security bug?
Matt Zimmerman wrote:
>On Sat, May 22, 2004 at 08:13:48AM -0700, Adam Morley wrote:
>>I noticed recently that squirrelmail released a new version to fix a few
>>bugs in its code base:
>>But I haven't seen anything from Debian --- and I'm wondering where
>>exactly I should ask the question, "Is Debian's squirrelmail vulnerable to
>>this?" I noticed a debian-security, but its listed as a "Developer"
>>mailing list on lists.debian.org, and -user doesn't seem like a place I
>>should go for security information (or is it?).
>>I read the FAQ, but that wasn't helpful in this case (or maybe I'm missing
>>something!) --- it strikes me that it was not immediately obvious to me, a
>>new user of Debian, where to go to find out about a possible security
>>problem, that may or may not affect Debian. Am I to always assume the
>>Security Team will never "miss" a security update? Or is there a forum
>>where this should be directed?
>In general, inquiries like this should go to the security team and the
>package maintainer (CCed).
>At this time the best answer I have is that squirrelmail in stable contains
>at least some of the bugs, but more investigation is needed.
>Sam: can you assist with this?
Yes. Thanks Adam.
Courtesy Marc Groot Koercamp:
Regarding 1.4.3 and the debian release policy, I do not understand how
debian can think that 1.2.6 is stable and safe. There have been many
security related fixes since the 1.2.6 release and we never explained in
release notes what the specific fixes were. By stating that Debian
backports security fixes to 1.2.6. I get curious how they do that. Do they
follow every cvs commit? Did you know that working with a php version with
register globals = off is seen as insecure? SquirrelMail 1.2.6 cannot work
with the register globals = off setting. SquirrelMail 1.4.x and 1.2.8
works with register globals - off.
Don't get me wrong, I do understand that customers don't like to update
packages every 3 month, but even Redhat ships newer SquirrelMail versions.
What is your take on this?
Sam Johnston, Director
Australian Online Solutions
1300 132 809
Date: Thu, 3 Jun 2004 23:54:32 -0700
> What is your take on this?
I wasn't sure if this was directed at me, but since I haven't heard anything
I thought I'd chime in. I know I need the newer squirrelmail and will
probably stop using the Debian package for that reason, at least unless
I hear otherwise at some point. I find it rather disconcerting that the
Squirrelmail team recommended a release candidate as "stable" software
in order to fix the problem. Granted, new stable is out, but. . .
I constantly wish that patches for security fixes would be released on
some sort of long-lived stable branch by open source projects, but I'm
guessing that's too much work and not exciting. I am amazed at how
Debian does this, and sometimes wonder if something doesn't get missed,
so I will follow this conversation quite closely.
Thanks for maintaining such a easily maintained distro,
Date: Tue, 29 Jun 2004 11:59:20 -0700
> What is your take on this?
I've heard nothing more on this --- is something still happening? Or ?
> Sam Johnston, Director
> Australian Online Solutions
> 1300 132 809
> > Effectively, I'm questioning the version of squirrelmail included with
> > woody, as it is quite old, and theoretically contains vulnerabilities.
> Debian's stable release is quite old, and there is nothing that the Security
> Team can do about that. Let's confine our discussion to vulnerabilities.
I am under the impression, since there has been no update to the Debian woody squirrelmail package since the 1.4.3 release of squirrelmail (which was released rather hurridly and in very shoddy form --- they issued a release candidate as a security fix! exceedingly annoying! and then the actual stable release was broken!), that the Debian woody version is vulnerable to the issues listed at:
That is my primary concern.
> > I'd like to know whether it is indeed audited separate from the current,
> > "secure" version of squirrelmail, as I maintain the current version
> > instead of the Debian version --- because the debian version supposedly
> > contains some of the security bugs.
> Refer to DSA 191-1, DSA 191-2 and DSA 220-1 for examples of past bugs fixed
> in the squirrelmail package in woody. Let me assure you, it is no pleasure
> to support a project like squirrelmail, where new cross-site scripting bugs
> are discovered on a regular basis (the past three release announcements
> mention XSS bugs), and at least one of the upstream developers (Marc Groot
> Koercamp) demonstrates outright hostility toward the Security Team's efforts
> to support squirrelmail for Debian users.
This makes sense to me. I'm actually rather impressed with how timely security updates for Debian are.
> It is very time-consuming work to assess these vulnerabilities and backport
> fixes for them. When the upstream developers refuse to provide details of
> the vulnerabilities, and instead try to force a new upstream release on us,
> this creates _much_ more work for the security team, who are already
> overloaded volunteers. The fact that the squirrelmail 1.4.3 release turned
> out to have a critical bug which caused it to be recalled by the developers
> further emphasizes the problems with upstream's security procedures.
Actually, the fix wasn't even the release version; it was a release candidate, which is even worse. It made me want to stop using squirrelmail.
> If anyone can provide precise details of the vulnerabilities fixed in
> 1.4.3-RC1, 1.4.3 and 1.4.3a (yes, all three are said to have contained some
> unknown number of security fixes to unknown parts of the code), or convince
> squirrelmail upstream to provide such details, then that would provide some
> hope for its support in Debian stable.
I must ask the question: is there a method for removing security support and marking a package as so in the Debian project? It sounds like, if the lead with Thijs Kinkhorst does not work out, there needs to be a way to mark packages (like squirrelmail) as known (or suspected) to be insecure, and unsupportable, as removing them from stable would require updating cd images, changing the distro, etc. This is the only idea that I get off the top of my head.
Again, Matt, sorry about the brain misfire, and I apologize again. Thanks for all your hard work!