CentOS - Feb 2005 - full-d] Administrivia: List Compromised due to Mailman Vulnerability (fwd)

Sorry for the cross post, but this is an important one 
potentially affecting all recipients.

This just crossed the Full Disclosure mailman moderated 
mailing list.  It bears a careful read, and thought about 
whether a response is needed.

The implication is that if there is any use of a mailman 
password in common with a password you 'care' about, you need 
to take appropriate action at once.  Also some backends merge 
Bugzilla and mailman password stores, which can cause 
unexpected secondary effects.

I have not seen a patch yet, and so one has to assume that the 
configs and passwords for all mailman moderated mailing lists 
are compromised.  Once a fix issues, Mailman moderators will 
want to do a global password change, and local list 
modification.

-- Russ Herrold


---------- Forwarded message ----------
Date: Wed, 9 Feb 2005 18:15:02 +0000
From: John Cartwright <johnc at grok.org.uk>
To: full-disclosure at lists.netsys.com
Subject: full-d]  Administrivia: List Compromised due to Mailman  Vulnerability

Hi

On 7th February 2005 I was notified of a number of potentially -
compromised Full-Disclosure subscriber accounts. Following an
investigation it appears that the Mailman configuration database was
obtained from lists.netsys.com on 2nd January 2005 using a remote
directory traversal exploit for a previously unpublished
vulnerability in Mailman 2.1.5.

Subscriber addresses and passwords have been compromised. All list
members are advised to change their password immediately. There do
not appear to be further signs of intrusion although investigations
continue.

The vulnerability lies in the Mailman/Cgi/private.py file:

def true_path(path):
     "Ensure that the path is safe by removing .."
     path = path.replace('../', '')
     path = path.replace('./', '')
     return path[1:]

A crafted URL fragment of the form ".../....///" will pass through the
above function and return as "../", thus allowing directory traversal
to occur using the following URL syntax to retrieve an arbitrary path.

/mailman/private/<list>/<path>?username=<username>&password=<password>

Expect vendor advisories nearer the end of the week, for now here is a
suggested fix from Barry Warsaw:

SLASH = '/'

def true_path(path):
     "Ensure that the path is safe by removing .."
     parts = [x for x in path.split(SLASH) if x not in ('.',
'..')]
     return SLASH.join(parts)[1:]

This issue only affects Mailman installations running on web servers
that don't strip extraneous slashes from URLs, such as Apache 1.3.x.

The Common Vulnerabilities and Exposures project (cve.mitre.org) has
assigned the name CAN-2005-0202 to this mailman issue.

Cheers
- John
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

On Wed, 2005-02-09 at 14:41 -0500, R P Herrold wrote:
> Sorry for the cross post, but this is an important one 
> potentially affecting all recipients.
> 
> This just crossed the Full Disclosure mailman moderated 
> mailing list.  It bears a careful read, and thought about 
> whether a response is needed.
> 
> The implication is that if there is any use of a mailman 
> password in common with a password you 'care' about, you need 
> to take appropriate action at once.  Also some backends merge 
> Bugzilla and mailman password stores, which can cause 
> unexpected secondary effects.
> 
> I have not seen a patch yet, and so one has to assume that the 
> configs and passwords for all mailman moderated mailing lists 
> are compromised.  Once a fix issues, Mailman moderators will 
> want to do a global password change, and local list 
> modification.
> 
the patch to mailman came out weeks ago unless this is a new password
exposure bug.

-sv

R P Herrold wrote:
> 
> This issue only affects Mailman installations running on web servers
> that don't strip extraneous slashes from URLs, such as Apache 1.3.x.
 From those of us out here in the peanut gallery -- is this to imply 
that if we are running it under Apache2 (RH9 and above, basically), that 
we are not affected by this issue?

Thanks for posting!
-te

-- 
Troy Engel | Systems Engineer
Fluid, Inc | http://www.fluid.com