This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 459530 - Mailman private archives are available to all local users
Mailman private archives are available to all local users
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: mailman (Show other bugs)
12
All Linux
high Severity high
: ---
: ---
Assigned To: Jan Kaluža
Fedora Extras Quality Assurance
: Reopened, Triaged
Depends On:
Blocks: 613607
  Show dependency treegraph
 
Reported: 2008-08-19 14:48 EDT by H. Peter Anvin
Modified: 2010-07-13 06:12 EDT (History)
3 users (show)

See Also:
Fixed In Version: mailman-2.1.13-4.fc14
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 613607 (view as bug list)
Environment:
Last Closed: 2010-07-13 06:12:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description H. Peter Anvin 2008-08-19 14:48:10 EDT
With the default installation of Mailman from RPM, /var/lib/mailman/archives/private is mode 2771 mailman,mailman.  Mailman then creates archives below that are mode 775.

Mailman doesn't use any salting for the archive directories, which means that any local user can access the supposedly-private archives as long as they know the name of the list.

This problem appears to still exist in at least mailman-2.1.9-10.fc9.x86_64.rpm.
Comment 1 H. Peter Anvin 2008-08-19 15:23:03 EDT
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.
Comment 2 Tomas Smetana 2008-08-25 08:06:59 EDT
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.
Comment 3 H. Peter Anvin 2008-08-26 17:21:09 EDT
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.
Comment 4 Tomas Hoger 2008-08-26 17:32:59 EDT
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?
Comment 5 Tomas Hoger 2008-08-26 17:33:23 EDT
Link to already mentioned upstream bug report:

http://sourceforge.net/tracker/?func=detail&atid=100103&aid=474616&group_id=103
Comment 6 H. Peter Anvin 2008-08-28 17:15:42 EDT
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).
Comment 7 Bug Zapper 2009-06-10 07:07:19 EDT
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
Comment 8 Bug Zapper 2009-07-14 09:58:30 EDT
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.
Comment 9 H. Peter Anvin 2009-07-26 20:34:07 EDT
Confirmed in Fedora 10.  Doubt Fedora 11 is any different.
Comment 10 Bug Zapper 2009-11-18 02:46:15 EST
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
Comment 11 Bug Zapper 2009-12-18 01:19:08 EST
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.
Comment 12 H. Peter Anvin 2009-12-29 13:14:57 EST
*Sigh* still there...
Comment 13 Bug Zapper 2010-04-27 08:12:20 EDT
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
Comment 14 Jan Kaluža 2010-06-17 09:11:53 EDT
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.
Comment 15 H. Peter Anvin 2010-06-17 17:53:01 EDT
Perhaps creating a group for the http servers and making it a group directory?
Comment 16 Jan Kaluža 2010-07-12 08:28:31 EDT
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?
Comment 17 Tomas Hoger 2010-07-12 10:19:25 EDT
(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.
Comment 18 Jan Kaluža 2010-07-13 02:34:26 EDT
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.
Comment 19 Jan Kaluža 2010-07-13 06:12:04 EDT
This issue should be fixed in rawhide in mailman-2.1.13-4.fc14 as I've described in Comment #18.

Note You need to log in before you can comment on or make changes to this bug.