Another XSS vulnerability is reported on FD. Fixed in SM CVS with comment: "Fixed XSS vulnarability spotted by "Roman Medina" after a very thorough research of the SquirrelMail source. I was impressed." http://cvs.sf.net/viewcvs.py/squirrelmail/squirrelmail/functions/mime.php New release of SM should be out shortly according to: http://www.rs-labs.com/adv/RS-Labs-Advisory-2004-1.txt
*** This bug has been marked as a duplicate of 49675 ***
really another (new one)
www.squirrelmail.org : "ANNOUNCE: SquirrelMail 1.4.3 Released May 30, 2004 by Jonathan Angliss We are pleased to announce the release of SquirrelMail 1.4.3. This is a very important release as there was a number of XSS issues uncovered, and resolved. Many thanks to Eyal Udassin, Roman Medina and others for reporting the issues. As the previous release contained issues, it is STRONGLY advised that all users should upgrade to the latest release. This release contains a number of bug fixes (including security based issues), and some minor user interface tweaks."
yup this is a new XSS vulnerability found in 1.4.3_rc1, fixed in 1.4.3. <http://squirrelmail.org/changelog.php> says: Version 1.4.3 - CVS ------------------- - Fix form functions default parameter. - Disabled Korean extra functions, because they don't provide all required options and message composition is broken. - Added Basque translation support. - Fixed XSS vulnarability in content-type display in the attachment area of read_body.php discovered by Roman Medina. also note that squirrelmail has moved from net-mail to mail-client.
in x86. ppc and sparc need to add 1.4.3 to stable before we can release GLSA. alpha should also consider marking this stable as we bombed their last stable version with the last security fix, but AFAIK it's not neccessary for releaseing the GLSA. 1.4.3_rc1 -> 1.4.3 (webapp-apache) 1.4.3_rc1-r1 -> 1.4.3-r1 (webapp)
GLSA drafted and reviewed by krispykringle and concordes. Ready to ship when marked stable on ppc and sparc.
Setting back Product/Component as this is not GLSA-ready yet (waiting for stable).
*** Bug 52524 has been marked as a duplicate of this bug. ***
Stable on sparc.
Stable on alpha.
UPDATE: The SquirrelMail 1.4.3 Release contains a serious memory exhausting bug. Please be patient and wait until we released version 1.4.3a (To be expected soon) or download a fixed version of compose.php Rev 1.319.2.35 from CVS and replace the compose.php file in the src directory.
2nd part that didn't get pasted... The SquirrelMail development team are pleased to announce the release of 1.4.3a. This release contains a minor bug fix that seemed to have caused some issues with users in replying to mail. This release also contains numerous XSS fixes from the 1.4.3 release.
Hmmm... We should probably wait for a 1.4.3a ebuild before releasing this glsa. Jeremy: sorry to bother you again :)
squirrelmail-1.3.1 and squirrelmail-1.3.1-r1 already have a patch for "memory exhausting bug". See bug #52656. IMHO, I don't think we need to bump.
The patch has been added after the ebuild version was released. People that upgraded between May 31 and June 2 will still get an unpatched version, so I would still recommend a bump... Waiting for eradicator's opinion on this ?
just see http://www.gentoo.org/doc/en/policy.xml Versioning and revision bumps Package revision numbers should be incremented by Gentoo Linux developers when the ebuild has changed to the point where users would want to upgrade. Typically, this is the case when fixes are made to an ebuild that affect the resultant installed files, but the ebuild uses the same source tarball as the previous release. If you make an internal, stylistic change to the ebuild that does not change any of the installed files, then there is no need to bump the revision number. Likewise, if you fix a compilation problem in the ebuild that was affecting some users, there is no need to bump the revision number, since those for whom it worked perfectly would see no benefit in installing a new revision, and those who experienced the problem do not have the package installed (since compilation failed) and thus have no need for the new revision number to force an upgrade. A revision bump is also not necessary if a minority of users will be affected and the package has a nontrivial average compilation time; use your best judgement in these circumstances.
yes, a bump should occur when the memory-exhaustion bug is fixed. I've been away since Thursday, so I'm looking at this now.
ok... i wasn't aware that the patch that I included fixed an exaustive memory bug. I just thought it fixed double messages in a reply (which seemed trivial ebough to me not to bump). In any event, 1.4.3a is out now, and I'll be making an ebuild for that in a few... we should not release the GLSA until that is ready.
1.4.3a is now in portage and needs to be marked stable by ppc and sparc.
ppc, please mark mail-client/squirrelmail-1.4.3a stable...
Marked ppc
Thanks ! Ready for GLSA
GLSA 200406-08
