Re: FWD: Squirrelmail XSS + SQL security bug?
On Tue, Jul 06, 2004 at 12:47:21PM +0200, Rom?n Medina wrote:
> Hi Jeroen,
> > Sam, could you please forward you incoming mail about security issues to
> > someone who has more time to look into it?
> Well, I wouldn't lose time doing so. Better to upgrade to latest 1.4.3a.
> Yes, contrary to the Debian "backporting" policy, but in this case there
> are sufficient reasons to make the exception (and it's less "intrusive"
> than completely removing SM from Woody, as I listened before). I wouldn't
> trust an old 1.2.6 version; not without some guarantees than SM team would
> provide a detailed info of applied security fixes. And that's not the
> case, as stated by Matt. In this case, I agree with him: SM team should
> make a little effort to document such bugs instead of silently patching. I
> told this to SM developpers when I contacted them one month ago. Security
> through obscurity is not good at all.
I agree with what you say about the SM team, as much as getting a
cc/forward of commit mails that fix a security issue, would already be
Simply putting a new major upstream release (1.4.x instead of 1.2.x)
won't be accepted for a security update, and also because XSS issues
are not that a severe issue, I don't think there is any reason to remove
1.2.x from woody. Those XSS, and especially the SQL injection needs to
be fixed though.
Thanks for your very detailed mail, I'll look into it w.r.t. remaining
woody issues. I also saw three CVE's assigned to squirrelmail in 2004,
none of them have been patched by Debian. I'll trace that down.
> >> I disclosed in a _detailed way_ several bugs:
> >> [RS-2004-1] http://www.rs-labs.com/adv/RS-Labs-Advisory-2004-1.txt
> > This wasn't reported in the Debian BTS.
> I was unaware of Debian BTS when I reported the vuln. Anyway, it should be
> sufficient to notify it to security email address. People who reports
> security bugs doesn't necesarily need to know about bug tracking systems
> or the way a "vendor" archives or deals with a reported bug.
> Moreover, security teams should monitorize public security mailing-lists
> like Bugtraq. So if the usual communication channels fail (for instance,
> e-mail to security address), at least you are aware of public vulns) (and
> then you can feed your internal / external BTS, or act as whatever you
I fully agree with you, sorry, I didn't intend to 'blame' you for not
reporting it in the BTS. It would have made things easier/go faster, but
I agree, it is by no means your fault it didn't happen. It'd be
appreciated if you could do so though.
> > I (the person uploading that version) was not aware of this, partly
> > because you didn't file a bug in the BTS about this. Note however that
> As I have told, to "file a bug" is not my duty (although I would have made
> it if I had known of BTS' existence). I reported the bug to SM developpers
> (_before_ making it public, that's important, and letting sufficient time
> for the bug to be fixed) and also to Debian maintainer _as a courtesy_ (I
> don't have the time nor resources to notify all distros which use SM; I
> did the exception with Debian because I use Debian and I like it).
Then the problem was with Debian internally, that this wasn't
forwarded/fixed... again, sorry for insinuating you should have filed a
> >> - I don't know whether or not the old XSS bugs which I reported to
> >> affect
> >> Debian Woody (read RS-2004-1) are still uncovered. I'm afraid it is...
> > Thanks for the direct pointer, I assume you did contact
> > email@example.com about this?
> I should check my outbox to verify this (I think I placed
> firstname.lastname@example.org in cc). In all cases:
> - You can assume _at least_ Debian maintainer (Sam) was notified.
> - I recall to have talked about this with Matt, so I assume he is / was
> also aware of this. Indeed he replied in a public mailing-list to my
> advisory post so he should read it:
I don't know what happened to this. In answer to this question of yours:
| #ifdef _security_perspective_
| #define usual_channels bugtraq other_lists
| #ifdef _devel_perspective_
| #define usual_channels changelog_file
| printf("My usual channels are: %s", usual_channels);
| It was some kind of pseudocode :-) Question: which perspective are
| using Debian maintainers to monitorize their packages? In the
| particular case of SM, the old XSS issues were listed in ChangeLog,
| but .deb package was not updated. Why?
Debian maintainers should monitor upstream, especially changelogs of new
versions, and preferable also upstream devel mailinglists.
The .deb package was not updated because the Debian maintainer for
squirrelmail was too busy, why the security team didn't update woody
yet, maybe they were too busy too. I have a suggestion how to
potentially improve this, I'll send a separate mail about it.
> > But Debian unstable keeps getting lots of other bugs, so is often no
> > alternative :)
> Well, from security perspective I prefer unstable. Same applies to
> "usability" perspective (I don't like outdated versions of certain
> software). Again this is my personal opinion. I respect Debian Woody
> policy but I don't support it. Better not to speak about this (flame-war
> risk! :-)).
You're of course entitled to your own opinion. We shall agree to
disagree on this issue then :).
> > If Debian isn't notified of security bugs, they can't fix them. Weird
> Don't blame me. Your statement is easily refutable: "If Debian maintainers
> don't answer to important mails (I know the email address was fine because
> I previosly had contacted Sam using the same method; and I insisted trying
> to re-contact) and Debian security team is unaware of public security
> mailing-lists (or they answer to certain threads without reading the
> original post :-?) it's not my fault". Please, don't start the war. I'm
> only defending my position :)
Again, my fault, indeed, you've done all (and more) that one could
expect from you. It still remains true that also filing a bug will help
more, but I agree it's a Debian internal problem if indeed nothing
happened after this (I of course don't know what happened in private,
so I am not going to guess on whether or not action was taken).
> > that you here claim unstable was free of these bugs, while above you
> > claim Debian unstable _had_ these bugs at the time of your advisory. So,
> > which one of the two is it? Or are there more issues involved than the
> > ones detailed in RS-2004-1?
> [elaborate explaination]
> I hope this will clears things out.
Thanks, indeed it does for me.
Jeroen van Wolffelaar
Jeroen@wolffelaar.nl (also for Jabber & MSN; ICQ: 33944357)