There is a critical security flaw in Mailman 2.1.5 and earlier Mailman
2.1 versions which can allow remote attackers to gain access to member
passwords under certain conditions. The extent of the vulnerability
depends on what version of Apache you are running, and (possibly) how
you have configure
I think CAN-2005-0202 gives us the opportunity to finally implement what
we have long considered an embarrassing exposure in Mailman's config.pck
databases. Member passwords are kept in this database in the clear.
The obvious fix is to hash member passwords and keep only the hash in
the database.
I can't speak to whether the work is worth the benefit, but I'm
definitely in favor of the change. I've always questioned the benefit
of having recoverable passwords. I feel like a password should be a one
way thing. You put it in, and you can't get it back. If you forget it,
you have to re
Hi all,
I am new to this list and just want to give my two cents as a first
step. I mainly will give my best on i18n things in future (en->de).
Joel Ebel <[EMAIL PROTECTED]> wrote :
> I can't speak to whether the work is worth the benefit, but I'm
> definitely in favor of the change. I've alway
Hi Barry,
While you're on this subject, I was intrigued by the password resetting
script but was disappointed that there is no way to actually configure
the password on the command-line. I was thinking this would enable
integration of Mailman subscriptions into an existing user database
(i.
On Feb 10, 2005, at 7:02 AM, Barry Warsaw wrote:
I think CAN-2005-0202 gives us the opportunity to finally implement
what
we have long considered an embarrassing exposure in Mailman's
config.pck
databases. Member passwords are kept in this database in the clear.
The obvious fix is to hash member
Ah - I had forgotten the ~mailman/bin/withlist script. Sorry, folks,
still just getting back into Mailman. If it works as advertised, then I
also vote for the changes Barry is recommending. It makes Mailman
completely compatible with the type of CMS integration I'm describing.
Joel's point
Hi all,
Is there a way to change the setting to restrict access to the roster
for all lists, globally? If there isn't one, would one of you be
willing to write one quickly? The only other option I see is to remove
the ~mailman/cgi-bin/roster script which would be a pity.
Given the risk, now
Barry
I am not convinced that all the potential security problems with
private.py are covered by the patch being published. For some time I
have added modifications to private.py as part of my htdig integration
patch which maybe should be considered for addition to the standard MM
distribut
My suggestion would be:
1) As soon as possible post MM 2.1.6 with the security patch.
2) Quickly follow up with MM 2.1.7 with the member passwords hashed. At
the same time I think we should implement the stronger password
generation suggested in this open advisory against mailman.
http://www.cve
On Thu, 2005-02-10 at 17:24 +, Richard Barrett wrote:
> As an aside, I am not able to:
>
> 1. identify exactly what the exploit is.
>
> 2. see why it impacts solely on private archive access via private.py.
>
> 3. why Apache version is relevant to private.py operates unless the
> PATH_INFO
Regarding my previous post on this subject.
Having read
http://lists.netsys.com/pipermail/full-disclosure/2005-February/
031562.html my lack of comprehension noted in my previous post is
resolved but my comments about other issues with private.py stand.
---
On Thu, Feb 10, 2005 at 11:40:29AM -0500, Tobias Eigen wrote:
> Hi all,
>
> Is there a way to change the setting to restrict access to the roster
> for all lists, globally? If there isn't one, would one of you be
> willing to write one quickly? The only other option I see is to remove
> the
I've -always- disabled the monthly reminders, so that would be no great loss.
If we convert to one-way passwords, could the upgrade script convert the current passwords? It
would be a -big- deal if everyone had to reset their passwords.
Bob
Barry Warsaw wrote:
I think CAN-2005-0202 gives us the
Why even bother with passwords? They're good to include in the unsubscribe URL,
so that if someone maliciously gets your list, they can't unsubscribe everyone
manually. But mainstream commercial autoresponders have no passwords, and they
work great.
Sure, it _is_ possible that someone could caus
Private mailing list archives. Needed for that.
Adrian Bye wrote:
Why even bother with passwords? They're good to include in the unsubscribe URL,
so that if someone maliciously gets your list, they can't unsubscribe everyone
manually. But mainstream commercial autoresponders have no passwords, a
I'm with Bob here - I did a scan of the httpd log on my mailman server
and I'm pretty sure we were not hit by either the spammers using the
~mailman/cgi-bin/roster vulnerability or the hackers via the
~mailman/cgi-bin/private vulnerability. I've now disabled both of these
scripts for the ti
this might not be a bad idea, but -- would require all operations to be
validated via a URL emailed to the affected address. But I could live
with that.
On Feb 10, 2005, at 10:44 AM, Adrian Bye wrote:
Getting rid of passwords would open up mailman to usage to a much
wider range of
users, which
On Feb 10, 2005, at 9:32 AM, John Dennis wrote:
My suggestion would be:
1) As soon as possible post MM 2.1.6 with the security patch.
2) Quickly follow up with MM 2.1.7 with the member passwords hashed. At
Then in the MM 3.0 time frame the entire mailman security framework
should be revisited, the
To make Joel's words mine. Even, where the password is set by the server,
there are only so many passwords a person can remember - and invariably if
one signs up to multiple forums/ lists/ one tends to repeat the password. So
having the password mailed back is an unnecessary exposure. All that is
w
(sorry for the top posting..)
I actually the the (yes, call me a fool) passwords of some private
lists as a unified authentication system so the passwords are used
to gain access to other 'authorized' content for list members.
of course there's issues with them being sent
At 11:40 AM -0500 2005-02-10, Tobias Eigen wrote:
Is there a way to change the setting to restrict access to the roster for
all lists, globally?
That should be possible to do using "withlist". However, I don't
know the specifics of how to do that.
--
Brad Knowles, <[EMAIL PROTECTED]>
"Those w
At 10:02 AM -0500 2005-02-10, Barry Warsaw wrote:
As for #2, well, I think most people hate those password reminders
anyway, and we've decided that they are going away for MM3.
I don't hate them. I find them quite useful. I do have filters
set up to filter them all off into their own mail fol
At 11:17 AM -0500 2005-02-10, Tobias Eigen wrote:
And this, plus the CAN prefix to the patch name, reminds me: correct me
if I'm wrong, but my understanding is that Mailman as it exists does
not comply with the new (unfortunately named) CAN SPAM act. According
to this act, a recipient of an ema
[whoops, meant to send to the whole list]
def roster_privatize(mlist):
mlist.private_roster = 1
m.Save()
m.Unlock()
Put that into your mailman/bin/roster_privatize.py and then run
withlist -a -l -r roster_privatize
Yeah I haven't tested that code but that's the rough idea.
Take a look at set
Hi Dan,
Given the risk, now made worse by Bernhard's very helpfully
distributing this script for spammers, this is a really urgent issue.
Not that hard to write such a script. I expect the spammers already
have several alternatives to choose from. So, it's quite likely
no harm has been done, and
Hi,
John Dennis wrote:
> My suggestion would be:
>
> 1) As soon as possible post MM 2.1.6 with the security patch.
+1
>
> 2) Quickly follow up with MM 2.1.7 with the member passwords hashed.
I would suggest 'mailman 2.2' and introduce password-less membership.
Most of the user operations sh
Other 2.2 features I imagine are:
- Languages are selectable at configure option.
- Internal strings are unified to unicode to reduce type checking.
- Utf-8 web pages for
- Uft-8 web pages for all languages.
Sorry for the incomplete post.
--
Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp
http://weathe
Folks,
Just to let you know, the machine that normally provides service
for www.python.org is currently down. The facility that provides the
co-location is having power problems, and they are working on solving
it.
We have temporarily moved the www.python.org hostname to a
different machine
> I would suggest 'mailman 2.2' and introduce password-less membership.
> Most of the user operations should be done by confirmation
> string sent by email message. Users can optionally have their
> passwords which should be stored in hashed format.
This would be great.
As an additional note, I
I would suggest 'mailman 2.2' and introduce password-less membership.
Most of the user operations should be done by confirmation
string sent by email message. Users can optionally have their
passwords which should be stored in hashed format.
This would be great.
I'm very into this idea of password-
I'm all for the password-less stuff, but then how do you authenticate for
members-only archives? I've got big lists that must be members-only for the
archives.
Bob
-- Original Message ---
From: Tokio Kikuchi <[EMAIL PROTECTED]>
To: John Dennis <[EMAIL PROTECTED]>
Cc: mailman-dev
Bob Puff wrote:
I'm all for the password-less stuff, but then how do you authenticate for
members-only archives? I've got big lists that must be members-only for the
archives.
Most of the user operations should be done by confirmation string
sent by email message.
Operations include authenticati
33 matches
Mail list logo
