This was forwarded to me by our security officer. I believe the original author, Florian Weimer, intended to reach this list but did not know how to and instead went through his security contacts. Perhaps Florian's concerns would best be addressed in MM 3.0 and maybe this should be added to the MM 3.0 feature list. BTW, is there an independent MM 3.0 list? I thought I had heard such a beast existed, but my recollection is hazy.
John Dennis <jdennis@redhat.com>
"John" == John Dennis <jdennis@redhat.com> writes:
John> The idea of storing sensitive data in Mailman archives seems
John> to be a bit crazy, but unfortunately, it is common practice.Not only that, but if you're incautious about the archive setup, 3rd parties may stash sensitive data there. Somebody (@163.com, according to the received trail) noticed that a certain Chinese spam was getting through my filters, and sent us an apparent copy that was actually a cache of credit card data several pages down. :-(
It's a public list, so there's nothing we want to do about the authentication of users problem discussed here; but watch those archives, guys.
-- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.
On Dec 15, 2004, at 11:37 AM, John Dennis wrote:
This was forwarded to me by our security officer. I believe the original author, Florian Weimer, intended to reach this list but did not know how to and instead went through his security contacts. Perhaps Florian's concerns would best be addressed in MM 3.0 and maybe this should be added to the MM 3.0 feature list. BTW, is there an independent MM 3.0 list? I thought I had heard such a beast existed, but my recollection is hazy.
The list for 3.0 is http://mail.python.org/mailman/listinfo/mailman3-dev
More information can also be found on the wiki http://zope.org/Members/bwarsaw/MailmanDesignNotes/FrontPage
First off -- as far as I know, the mailman password generation algorithm was never intended for significant security. It was intended to generate nearly-pronouncable (and thus easier to remember) passwords as a mild deterrent to attackers. I wouldn't really characterize this is a security bug so much as a design choice that you may or may not agree with.
I'm not sure it makes sense to worry about the auto-generated passwords when we're plaintexting them (and any archive data, and any email) across the Internet. If you're storing sensitive archives in Mailman you should probably be looking at something beyond Mailman for security, including an https server. Perhaps a short term fix would be to double-authenticate somehow.
The idea of storing sensitive data in Mailman archives seems to be a bit crazy, but unfortunately, it is common practice.
The idea of sending sensitive data *by unencrypted email* is a bit crazy. Doesn't mean it's not done, but I don't want to spend a whole lot of time designing a more secure mailman only to have people complain that their email still isn't secure. If you're really storing sensitive documents, maybe you need to look at some PGP extensions to Mailman as well...
Despite these considerations that make the whole idea more complex, it might be worth looking at some secure mailman options for 3.0 (assuming you've got a certified https server and all that jazz), and incorporating some of these suggestions for their other benefits (eg: disallowing user-selected passwords means people can't accidentally use trusted passwords for mailing lists). But we're going to have to do a lot more thinking and designing if we want to claim that Mailman's safe for sensitive documents.
Terri
- Terri Oda:
First off -- as far as I know, the mailman password generation algorithm was never intended for significant security. It was intended to generate nearly-pronouncable (and thus easier to remember) passwords as a mild deterrent to attackers. I wouldn't really characterize this is a security bug so much as a design choice that you may or may not agree with.
Your users disagree. As I wrote in the message forwarded by John, the brute-force attack is entirely pratical and leads to real-world security breaches.
I'm not sure it makes sense to worry about the auto-generated passwords when we're plaintexting them (and any archive data, and any email) across the Internet.
It does. The Internet is pretty resilent against casual eavesdropping. It takes much more effort to intercept passwords in an email message than to run some script to recover the Mailman-assigned password of a list member whose email address is known.
The idea of sending sensitive data *by unencrypted email* is a bit crazy. Doesn't mean it's not done, but I don't want to spend a whole lot of time designing a more secure mailman only to have people complain that their email still isn't secure. If you're really storing sensitive documents, maybe you need to look at some PGP extensions to Mailman as well...
Last time I checked, Mailman lables its member-only archives "private", and the implicit promise to keep things posted to the list private is not kept if the software assigns easily guessed to new members.
I can only repeat that Mailman's current behavior surprises your users *a* *lot*, and leads to security breaches.
Florian Weimer wrote:
Last time I checked, Mailman lables its member-only archives "private", and the implicit promise to keep things posted to the list private is not kept if the software assigns easily guessed to new members.
I can only repeat that Mailman's current behavior surprises your users *a* *lot*,
I disagree.
So called "private" archives are only kept from prying eyes until those eyes subscribe at which time they are then visible. As I see it, the point of Mailman's security measures is not to keep anyone "else" from ever viewing the archives, it is to keep random web browsers and web spiders from accessing the archives. If someone has the ability to script a password guessing algorithm to try to guess an acceptable username/password pair to access the archives, they can more easily script a program to subscribe, confirm, and then access the archives as a subscriber. Plus, no matter how simple or secure the password, if you are scripting a password cracker then it's just a matter of time, the more easily guessed password is cracked *faster* (on average) but even "secure" passwords will be cracked eventually.
If your mailing list archives need greater security than this, then you need a different system. I don't think it is necessary or useful for Mailman to be the system that meets those needs, especially at the cost of making Mailman less useful for others who don't need such strong security measures for their list archives.
and leads to security breaches.
I would love to see a cite for your claim of "leads to security breaches". Do you know of actual cases where someone has gained access to private archives by cracking a mailman generated semi-random password rather than by simply subscribing, or by gaining access to a single password thru intercept or social engineering means?
jc
While I agree that on the average, the passwords aren't that critical, I do have a few lists that are set to require the admin's approval for subscription. Here, security is a little tighter.
I do routinely disable the monthly password reminders though - there's enough in the web admin that people can retrieve their passwords if they really need them.
Bob
JC Dill wrote:
Florian Weimer wrote:
Last time I checked, Mailman lables its member-only archives "private", and the implicit promise to keep things posted to the list private is not kept if the software assigns easily guessed to new members.
I can only repeat that Mailman's current behavior surprises your users *a* *lot*,
I disagree. So called "private" archives are only kept from prying eyes until those eyes subscribe at which time they are then visible. As I see it, the point of Mailman's security measures is not to keep anyone "else" from ever viewing the archives, it is to keep random web browsers and web spiders from accessing the archives. If someone has the ability to script a password guessing algorithm to try to guess an acceptable username/password pair to access the archives, they can more easily script a program to subscribe, confirm, and then access the archives as a subscriber. Plus, no matter how simple or secure the password, if you are scripting a password cracker then it's just a matter of time, the more easily guessed password is cracked *faster* (on average) but even "secure" passwords will be cracked eventually. If your mailing list archives need greater security than this, then you need a different system. I don't think it is necessary or useful for Mailman to be the system that meets those needs, especially at the cost of making Mailman less useful for others who don't need such strong security measures for their list archives.
and leads to security breaches.
I would love to see a cite for your claim of "leads to security breaches". Do you know of actual cases where someone has gained access to private archives by cracking a mailman generated semi-random password rather than by simply subscribing, or by gaining access to a single password thru intercept or social engineering means?
jc
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/bob%40nleaudio.com
- JC Dill:
Florian Weimer wrote:
Last time I checked, Mailman lables its member-only archives "private", and the implicit promise to keep things posted to the list private is not kept if the software assigns easily guessed to new members.
I can only repeat that Mailman's current behavior surprises your users *a* *lot*,
I disagree.
So called "private" archives are only kept from prying eyes until those eyes subscribe at which time they are then visible.
Moderating subscription is also supported and heavily used. List administrators expect that it keeps out unwanted guests.
If this is not the case, you really should put a big fat warning somewhere on the list configuration page.
and leads to security breaches.
I would love to see a cite for your claim of "leads to security breaches". Do you know of actual cases where someone has gained access to private archives by cracking a mailman generated semi-random password rather than by simply subscribing, or by gaining access to a single password thru intercept or social engineering means?
Yes, see the leaked message.
On 12/21/2004 15:47, "Terri Oda" <terri@zone12.com> wrote:
On Dec 15, 2004, at 11:37 AM, John Dennis wrote:
This was forwarded to me by our security officer. I believe the original author, Florian Weimer, intended to reach this list but did not know how to and instead went through his security contacts. Perhaps Florian's concerns would best be addressed in MM 3.0 and maybe this should be added to the MM 3.0 feature list. BTW, is there an independent MM 3.0 list? I thought I had heard such a beast existed, but my recollection is hazy.
The underlying problem may be that Mailman refers to the access tokens as "passwords".
They are not "passwords" in the sense a security office would think of (they travel around in cleartext; they are stored in cleartext; they are gratuitously or by unauthenticated request mailed out, etc.
The expectation level should be implicit in the text from the listinfo page:
"You may enter a privacy password below. This provides only mild security, but should prevent others from messing with your subscription. Do not use a valuable password as it will occasionally be emailed back to you in cleartext."
Designing an archiving system such that only people who were subscribed at the time a message was posted and have been subscribed continuously since can see that message would certainly be possible (if the problems of email address changes are solved, which probably implies that an email address is no longer an identifier), along with "better" passwords. I would think it would be an option, not the new "way things are."
--John
- John Dennis:
This was forwarded to me by our security officer. I believe the original author, Florian Weimer, intended to reach this list but did not know how to and instead went through his security contacts.
Of course I went through my security contacts because I thought (and still think) that this is a security issue. I didn't want to disclose it on a public mailing list such as this one before a fix (as described in the message) was implemented.
Feedback from selected, trustworthy Mailman users indicates that Mailman users also think that this is a security bug.
At 11:04 AM +0100 2004-12-22, Florian Weimer wrote:
Feedback from selected, trustworthy Mailman users indicates that Mailman users also think that this is a security bug.
I agree that it's a security issue, but I think that there are other issues that are higher in the priority list for future updates to the 2.1.x tree as well as the all-new code for Mailman3.
You'd have to get the official answer from Barry and Tokio for their respective trees as to what it would take to get the priority boosted, but I don't know that you're going to have much luck.
In the future, if you feel that you have sensitive security issues with Mailman, it's probably better to contact Barry directly, and he can at least give you an indicator as to whether or not it he feels it would be appropriate to discuss amongst a broader group of people, and where he feels that discussion should/could take place.
-- Brad Knowles, <brad@stop.mail-abuse.org>
"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755SAGE member since 1995. See <http://www.sage.org/> for more info.
So let me try to address some of the issues raised here. There's two things: what we can do for Mailman 2.1, and what we can do for Mailman 3.0 (yes, it is still alive ;).
For the most part, passwords are one big PITA all around. I'd love to see mechanisms in MM3 that would eliminate passwords altogether. I don't know if that's possible, but one option might be to drop cookies after completing a web-based confirmation, or possibly pubkey based authentication for email communications. There needs to be /a lot/ of thought into this, including issues of usability vs. security, and what level of security we actually want to assert.
For MM2.1, we long ago did a risk assessment on the assets that the password protects and we decided on the current scheme based on the value of those assets, which we deemed to be fairly low. I still think that's true except perhaps for private archives. Understand also that the bundled archiver, called Pipermail, was never intended to be ultimately secure, nor for that matter, highly scalable, robust, etc. Its primary use case was for public mailing lists, and to provide zero effort archiving.
So my standard answer if you don't like Pipermail is, use some other archiver. They are easy to integrate with Mailman. I know that a number of large sites are doing this.
The question is, outside of private Pipermail archives, do you feel that the user friendly, but not very secure passwords are adequate given the value of the asset they protect? We certainly felt they were when we designed the current system (which includes all the other ways to crack the password, including plaintext password reminders and storage of plaintext passwords in config.pck file).
BTW, I believe Python 2.4 has an interface to /dev/urandom, and we could certainly add some optional support for more cryptographically secure password generation for Mailman 2.1. It should not be the default because I don't believe the majority of users would benefit from more secure but less user friendly passwords.
-Barry
participants (9)
-
Barry Warsaw -
Bob Puff＠NLE -
Brad Knowles -
Florian Weimer -
JC Dill -
John Dennis -
John W. Baxter -
Stephen J. Turnbull -
Terri Oda