Bugzilla Bug 74459

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 ***