[Mailman-Users] any info on this reported exploit?

[Stephen J. Turnbull]

>>>>> "Jim" == Jim Popovitch <jimpop at yahoo.com> writes:

    Jim> Stephen J. Turnbull wrote:

    >> Oh, if you prefer windstorms, hurricane is a bad analogy.  Far
    >> more accurate is "tornado".<0.1 wink>

    Jim> Hurricane is the most accurate analogy, because with
    Jim> hurricanes nobody knows about them until the NWS (at least
    Jim> here in the USA) informs them

The reason nobody knows until they're told is because they haven't
thought to google for "satellite weather photos".<wink>

One reason I say that hurricanes are a bad analogy (besides the fact
that they're not sentient, while even script kiddies are sentient) is
that they're big and they trash everything in their path.  Of course
it makes sense to invest in a press office to make announcements about
them.  Furthermore, non-specialists have a strong interest in the
news, because they have options---they can board the windows and run
away.  This is not the case with Mailman; only specialists (sysadmins
as well as developers) can do anything about it, and they should know
where to find the equivalent of satellite weather photos (CERT,
SecurityFocus, etc).

Here, we have a vulnerability; in this case the exploit is obvious,
but who is really going to exploit it?  Furthermore, if you just keep
daily stats on the size of the queues, you'll almost certainly catch
it before it's a real problem, unless you're using lists for
time-sensitive information.  But in that case you'd better be set up
for hourly reports, anyway.

While there are profitably exploitable defects, most defects are like
this one.  Is there really much benefit to keeping everyone up to
date?  No.

Now consider a moderately dangerous bug, like the path-traversal bug.
*It wasn't a Mailman bug, Mailman cannot enforce access control.*  If
you announce this bug, and how to work around it, you've exposed the
bug in Apache to the world.  If the Apache developers don't have a fix
ready to deploy, this is very dangerous.  Even if you don't mention
Apache, the black hats see your announcement and realize (1) Mailman
is not a webserver; (2) the path traversal bug must be in a webserver;
(3) they see how it works through the countermeasure taken.  Mailman
has just published a way to exploit Apache.

Of course not all cases are like this example, but determining what
kind of case it is, and what information others are likely to consider
sensitive (including asking them), is time- and attention-consuming.

    Jim> You mis-characterize (yet again?) what I am saying. I am not
    Jim> advocating for the developers to work more, or differently.

But you are.  I've worked on such fixes (a rank amateur, but I was who
was available), and I've seen pros at work.  You consistently assume
that the developers already possess the information you ask for; I see
no reason to believe they do.  Even the small amount of information
you say you want takes a fair amount of attention to produce.  If
there are two developers involved, they'll undoubtedly have different
cost estimates, so there needs to be a meeting.  If there is another
project involved, there will have to be a national election<wink>.  In
a free software project, it's reasonable to say that the only tasks
where reliable schedule estimates can be made are those that are
already finished.

Release of security-related information is yet more controversial
(witness this thread).  More meetings....

    Jim> That is an option that I reserve the right to make the
    Jim> decision on. Don't remove my capability to make that decision
    Jim> by hiding the info.

    >> Neither I nor you have any *right* in the matter.

    Jim> Huh?  re-read my comments.  I reserve the right to shut my
    Jim> Mailman system down, for any reason, at any time,
    Jim> lack-of-a-workaround or not.

No, you re-read your comments.  "Don't remove" is an imperative phrase
in the English language.  Your use of the imperative mood is
sufficient justification for assuming you think you have some rights
in the matter of receiving information.  Elsewhere you talk about what
you "expect", which corroborates that inference.

    Jim> Why should Mark/Barry/Tokio trust me anymore then the next
    Jim> guy?

They shouldn't.  I'm saying that there are a number of alternatives.
One of those is for you to contribute enough (and otherwise show
reliability) to become trusted.  If you want to ask them for "off the
top of their heads" estimates, you'd better be trustworthy, because
they're in too much of a hurry to think carefully about what they're
saying.

    >> I really have to disapprove of the way you consistently
    >> deprecate costs that others incur, while inflating those that
    >> you face.

    Jim> You need to re-read what I've been writing.

I've read what you've written carefully, see above for evidence.  You
may need to be more careful to write what you mean more precisely, but
that's not my problem---it's hard enough to respond accurately to
what's there in black and white.

Regarding the inflation of costs, you imply that schedule estimation
is costless and accurate enough to save you from overtime work.  It is
neither.  I've told you so, and you simply ignore that.  That is
deprecating others' costs.  Note that you are quite welcome to back up
your opinion and contest mine; I'm not Watts Humphrey.  You simply
haven't tried.  I'd ignore you, but there are altogether too many
people out there who believe the things you do, and your statements
(especially the implicit ones) should be debunked.

As to inflating your costs, that's a lot more controversial, and in
the end you're the expert.  But given that for a project like Mailman
security risks are fairly rare (a couple times a year at most), I
suppose it comes out in the wash with all of Mr. Murphy's other
attacks on your spare time.

-- 
School of Systems and Information Engineering 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.