Small snip from mail to Vendor-Sec: Mailman 2.1.5 uses weak auto-generated passwords for new subscribers. These passwords are assigned when members subscribe without specifying their own password (either by email or the web frontend).
Small snip from mail to Vendor-Sec: Mailman 2.1.5 uses weak auto-generated passwords for new subscribers. These passwords are assigned when members subscribe without specifying their own password (either by email or the web frontend). Knowledge of this password allows an attacker to gain access to the list archive even though she's not a member and the archive is restricted to members only. The idea of storing sensitive data in Mailman archives seems to be a bit crazy, but unfortunately, it is common practice.
"This means that only about 5 million different passwords are ever generated, a number that is in the range of brute force attacks -- you only have to guess one subscriber address (which is usually not that hard)." It's probably more secure than letting careless users choose their own. Vulnerability profile is very slim : pick a mailing-list archiving confidential emails (uh ?) guess one subscriber address (not that hard ?), hope that he is a careless user subscribed to a confidential list that didn't change the autogenerated password (uh ?) and brute force the password by trying 5 million authentication on a HTTP host (easy cake)... A new mailman version "correcting" this would just be a security improvement, it doesn't close a vulnerability. I would just drop this one. Assigning a CAN number for this is a little ridiculous.
Koon does this from V-S make you happier? ;-) Currently, I'm aware of two more issues in Mailman 2.1: scripts/driver features a cross-site scripting vulnerability (easily triggered by visiting /mailman/savannah in the default Debian/unstable installation). A patch is straightforward. Setting STEALTH_MODe to 1 might be a good idea, too (personally, I don't view "path disclosure" as a security vulnerability, though). Mailman is vulnerable to cross-site request forgery (CSRF). This is non-trivial to fix correctly. I'm preparing a paper that proposes countermeasures which aren't too invasive. (That's why I stumbled across the XSS issue.) Maybe it's a good idea to roll all these patches into one update? I originally wanted to schedule the disclosure of the CSRF issues for early 2005 (it's not just Mailman, virtually all web applications are vulnerable), but SecureNet unfortunately rushed ahead and published an incomplete paper ("Session Riding"), probably after noticing the short discussion on CSRF attacks on the webappsec mailing list in November. 8-/
Public followup to bug 77524 *** This bug has been marked as a duplicate of 77524 ***