Bug 459530

This bug was originally reported in 2001 and has CVE number CVE-2002-0389.

Most likely Mailman needs to be changed to salt the private directories.

The upstream doesn't see this as vulnerability.  Moreover mangling the name in a predictable way ("salting") is not a solution.  I have discussed the bug with security response team.  I keep this open until I get more info.

Salting does not normally refer to mangling the name in a predictable way, but to prepending/appending unpredictable random data -- functionally a password.

(I believe you're thinking of hashing -- the two are frequently used together, but would not in this application.)

Please note that on a status change (especially going from public to private) the salting would have to be redone.

In other words, instead of:

   /var/lib/mailman/archives/private/foo

you'd have something like:

   /var/lib/mailman/archives/private/foo@FC3zoVUSLzoA

... where the suffix is a string of random characters.

And where should that string be recorded in the way that it is not accessible to local users, but accessible to web server user (and mailman)?  Some file owned by mailman, group-readable to web server group can be possibility, but that seems quite equivalent to making private directory only accessible to mailman user and web server group.  And that completely breaks if local users can run their own PHP scripts or CGIs...

Do you have any ideas on how to work around this?  How to you expect mailman to do that foo -> foo@FC3zoVUSLzoA mapping?

Link to already mentioned upstream bug report:

http://sourceforge.net/tracker/?func=detail&atid=100103&aid=474616&group_id=103

When the archive is public, the salt can be made public too (or even removed completely.)  Obviously the salt is visible when there is a symbolic link in /var/lib/mailman/archives/public (that should also take care of the issue of arbitrary scripts.)

When the archive is *private*, that's when the salt is needed; and in particular, that is why the salt needs to be changed when switching the archive from public to private.  The salt only needs to be accessible to mailman and should be practical to store in the mailman configuration database.  In fact, I believe there already are fields in that database for the paths to the public and private archives.

I realize this is - or should be - an upstream issue, but since upstream seems to ignore it (despite this vulnerability having *known* to be exploited to obtain sensitive information).

This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Confirmed in Fedora 10.  Doubt Fedora 11 is any different.

This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

*Sigh* still there...

This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

I'm not sure if I understand it well, but can't it be fixed by changing "private" directory owner to http server and change mode to o-x?

chown <web-server-user> private
chmod o-x private

I understand that just now it can't be used straightly in packages, because each http server uses different "user", but that's what upstream advises. If this fixes that situation I will try to find the way how to achieve it.

Perhaps creating a group for the http servers and making it a group directory?

I plan to add new group (probably "www-data", because that's what Debian uses) which should be used by all web-servers in Fedora. However, It would be easier to achieve it if we make this bug public. Do you agree with it?

(In reply to comment #14)
> I'm not sure if I understand it well, but can't it be fixed by changing
> "private" directory owner to http server and change mode to o-x?

Yes, this approach should be mentioned above, with possible issues pointed out.

(In reply to comment #16)
> I plan to add new group (probably "www-data", because that's what Debian uses)
> which should be used by all web-servers in Fedora.

Is there any active proposal to switch all web servers in Fedora to use single common non-privileged user?

> However, It would be easier to achieve it if we make this bug public. Do you
> agree with it?    

Agree this is better made public for further discussion.  Issue is already public via upstream bug report.

There is no active proposal yet, I wanted to start with public bug first.

I was thinking about this bug more and after discussion on #fedora-devel I think another solution would be to have Mailman preconfigured for httpd (which is also the current state, because it installs httpd config file and "Require:" httpd, so it would be logical to set that directory owner to "apache" group).

However, there's no mention that packages should be preconfigured only for httpd anywhere.

This issue should be fixed in rawhide in mailman-2.1.13-4.fc14 as I've described in Comment #18.