«

> OP: Did you discover this supposed security hole from black-box
observation
> of behavior or by being one of the 'lots of people being able to look
at
> source code', thereby giving evidence to the point?

The technique used which is the source of the problem was actually
first discovered in a separate package to the Python distribution, but
it was known that the same technique was used in a module within the
Python distribution. It is quite possible that other third party
packages might use it as well, although a few of the main stream
packages have been checked and they don't use exactly the same
technique so are okay. I could have just ignored the fact that the
Python distribution had the problem and worried about the other package
only.

> a) The OP has provided no info about his/her claim.

Since the problem at least affects two packages and because of the
potential for mischief, I am hardly about to identify the packages
concerned, nor describe anything that is going to allow people to work
out what the issue is.

> b) The OP's original post is a classical troll: blast volunteer
developers
> for not having anticipated and planned for a novel situation; argue
against
> things not said, at least now here, not recently; imply that
volunteers own
> him something. Most people with the expertise to detect a security
hole
> would know better.

And the reaction is what I have more and more been seeing in Open
Source circles. That, is either treat posters like ignoreant newbies
who know no better, or assume they are a trolls trying to discredit
Open Source. Quite sad really, one tries to do the right thing and gets
abused for it. It doesn't matter if a large project may be perceived as
being mostly immune to security problems, one could still occur and if
it isn't simple to raise such an issue I am sure than some people
wouldn't even bother.

> c) The noise generated because of b) has alerted any malware writers
> monitering c.l.p for hints about exploitable security holes that
there
> might be one in one of the few modules where such could reasonably
be.

With approx 200+ modules in the Python distribution I can hardly see
how this helps. If I had done what you had wanted in (a) and gave
actual information about the problem I would have been narrowing down
the problem to less than a dozen modules. You can't have it both ways.

> OP: If my doubts are wrong and you really do have something to
quietly
> report to the 'authority', then do so, and quit making a noise about
it.

And so it is was and knowledgeable people are looking at the issue. It
should not though have necessitated me making a noise in order to find
someone to deal with it in a timely manner. When a proprietary company
doesn't have an easy way of reporting problems or seems not to care too
much, Open Source people are on top of them like wolves. Why can't Open
Source people hold themselves to the same standard.

Not sure why I have even bothered to respond to you as it is probably
just the sort of attention you want. You even appear to have some
history of taking issue with people, even though in one of your own
posts you state:

> Responding to trollish postings. (Jan 26)
>
> My personal strategy is to read only as much of trollish
> threads as I find interesting or somehow instructive, almost never
respond,
> and then ignore the rest. I also mostly ignore discussions about
such
> threads.
>
> Terry J. Reedy

Maybe you should simply have not responded. Lets see if you now ignore
the followup discussion.

Fredrik Lundh wrote:
> Nick Coghlan wrote:
>
>
>>>I'm sorry, but this isn't really good enough. If Open Source wants to
>>>say that they are better than these proprietary companies, they need
>>>to deal with these sorts of things more professionally and establish
>>>decent channels of communications for dealing with it.
>>
>>Is that the sound of a volunteer I hear?
>>
>>All you have to do is put your hand up, and the problem will be solved. If not you, who?
>
>
> oh, please. this is a security issue. it needs a little more coordination
> than an ordinary bug report.
>
> </F>

Well, a less facetious answer to the OP's question would be Anthony Baxter. As
the current release manager, he's the best contact point I can think of.

Cheers,
Nick.

--
Nick Coghlan | | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net

wrote:
> Who are the appropriate people to report security problems to
> in respect of a module included with the Python distribution?
> I don't feel it appropriate to be reporting it on general mailing
> lists.
>

After my original flippant reply, I've been thinking some more about this, and
whether CPython can really benefit from initial notification of a security flaw
going privately to the developers first.

And, due to CPython's release model, I really don't think it can.

Upgrading your Python interpreter (even to a new maintenance branch release) in
a production environment is usually a fairly involved exercise requiring a
significant amount of testing, and the fact of the matter is, you're unlikely to
do so unless there is some feature or bug-fix in a new version that you really
need. (I'm still using Python 2.2.2 at work - it's entirely adequate for our
needs, so there's no real pressure to upgrade on the current project. For a new
project, I'd probably start with 2.4, planning to go to 2.4.1 in a couple of
months time, but there aren't really any post-2.2 additions to Python that I
can't handle living without).

So, for CPython, the window of vulnerability is driven mainly by the time to
when application developers, system administrators and end users get around to
upgrading, not by the time to when a patched version is released. In that sort
of environment, even if the developers were to release a new maintenance patch
within an hour of being notified of the problem, the window of vulnerability is
still going to be huge (there are still systems out there running Python *1.5*,
fer cryin' out loud).

More significantly, any security problem is likely to be with a specific
function or object that has been implemented in C. This means any such security
problem can be worked around by not using the affected feature, by employing
appropriate safeguards against abuse, or by substituting a Python equivalent.

This is something which is going to be application dependent, and relies on
application developers being notified.

So the most appropriate response to security issues in the CPython interpreter
and standard library is to notify application developers as to what the issue
is, and exactly which features it affects. Sending a private notification to the
*interpreter* developers does nothing to assist in this.

In accordance with the above, I would suggest that, even for security problems,
Python's standard Sourceforge bug tracker is the most appropriate place to file
the problem report.

If the problem is significant, then it should also be brought directly to the
attention of python-dev. At that point, the decision may be made to make a
general announcement as to the feature which needs to be avoided or handled
carefully. This would likely take the form of announcements on the
www.python.org website, and on comp.lang.python.announce.

Regards,
Nick.

--
Nick Coghlan | | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net

Nick Coghlan <> writes:
> After my original flippant reply, I've been thinking some more about
> this, and whether CPython can really benefit from initial notification
> of a security flaw going privately to the developers first.
>
> And, due to CPython's release model, I really don't think it can.
>
> Upgrading your Python interpreter (even to a new maintenance branch
> release) in a production environment is usually a fairly involved
> exercise requiring a significant amount of testing, and the fact of

That's true of any production environment, and yet if there's a
serious flaw, you absolutely have to do it.

> So, for CPython, the window of vulnerability is driven mainly by the
> time to when application developers, system administrators and end
> users get around to upgrading, not by the time to when a patched
> version is released.

No. If you're running a production system you have to stay on top of
security patches and install them ASAP. If a vulnerability is bad
enough, you have to close down your service until you're done
installing the fix.

If it takes 72 hours for the developers to make a patch, and 8 hours
for you to install the patch once it's announced, then your exposure
to attackers who learn of the bug from the announcement is 10 times
smaller if the bug and patch are announced simultaneously than if the
bug is announced immediately and the patch is released 72 hours later.

> More significantly, any security problem is likely to be with a
> specific function or object that has been implemented in C.

False; the Cookie module example we talked about was caused by an
unforeseen interaction between pure Python modules (Cookie and pickle).

> So the most appropriate response to security issues in the CPython
> interpreter and standard library is to notify application developers
> as to what the issue is, and exactly which features it affects.

It helps a lot if when the application developers are notified, a
patch is already available, since once there's a lot of notification,
the bug is public.

> Sending a private notification to the *interpreter* developers does
> nothing to assist in this.

Um, it lets them get a patch ready before they notify the app developers.

> If the problem is significant, then it should also be brought directly
> to the attention of python-dev.

It's a sure bet that attackers are monitoring python-dev and one
should generally assume that they're monitoring the email of any
developer for projects with serious security footprints. Notifying
python-dev isn't much different than broadcasting the info on "Attack
TV". Security bug reports should be made through SSL-encrypted web
pages, not unencrypted email.

Bugzilla already has this feature. I think it should also be added to
Sourceforge, if it's not already there. If it's available in
Sourceforge, then Python's Sourceforge project should enable it.

Meanwhile, the OP can always open a CERT notification (www.cert.org),
though it usually takes a very long time for anything to happen with
those.

Paul Rubin wrote:
>>More significantly, any security problem is likely to be with a
>>specific function or object that has been implemented in C.
>
>
> False; the Cookie module example we talked about was caused by an
> unforeseen interaction between pure Python modules (Cookie and pickle).

Fair cop on the C thing, but that example otherwise illustrates my point perfectly.

Unpickling untrusted data is just as dangerous as evaluating or executing
untrusted data.

This is *still* dangerous, because there *is no patch* to fix the problem. There
are only documentation changes to highlight the security risks associated with
unpickling, and Deprecation Warnings on the Cookie classes which use this unsafe
feature.

So, the only effective mechanism is to get the word out to Python *users* that
the feature is unsafe, and should be used with care, which basically requires
telling the world about the problem.

Any time Python has a problem of this sort, there is going to be at least one
solution, and only possibly two:

1. Avoid the feature that represents a security risk

2. Eliminate the security risk in a maintenance update.

The first solution applies regardless of whether the security risk is inherent
in Python's design or not. Some obvious examples (given above) relate to
execution of untrusted code.

The second solution applies only to bugs in the CPython implementation and
extension modules. And often, tweaking the application's Python code to avoid
the dangerous features is going to be faster (and safer) than changing over to a
new Python version.

By keeping the process public, and clearly identifying the problematic features,
application developers can immediately start working on protecting themselves,
in parallel with the CPython developers (possibly) working on a new maintenance
release.

To go with the 72 hours + 8 example you gave - what if you could work around the
broken feature in 6?

I suspect we'll have to agree to disagree on this point. Where we can agree is
that I certainly wouldn't be unhappy if SF had a feature like Bugzilla's
security flag.

Regards,
Nick.

--
Nick Coghlan | | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net

Nick Coghlan <> writes:
> Fair cop on the C thing, but that example otherwise illustrates my
> point perfectly.

I'm not sure what point you mean.

> Unpickling untrusted data is just as dangerous as evaluating or
> executing untrusted data.
>
> This is *still* dangerous, because there *is no patch* to fix the
> problem.

Pickle is now documented as being unsafe for untrusted data. It's
just like eval now. Nobody is going to make a patch for eval that
makes it safe for untrusted data. It would be nice if there were a
pickle alternative that's safe to use with untrusted data, but that's
sort of a separate issue (see the marshal doc thread referenced
earlier).

> There are only documentation changes to highlight the security risks
> associated with unpickling, and

I would say that unpickle's feature set actually changed incompatibly,
since (see analysis in the sf bug thread) unpickle was originally
designed to be safe.

> Deprecation Warnings on the Cookie classes which use this unsafe feature.

Yes, that means as soon as someone uses Cookie.Cookie, their
application will throw a DeprecationWarning and they have to fix the
error before the app can run.

> So, the only effective mechanism is to get the word out to Python
> *users* that the feature is unsafe, and should be used with care,
> which basically requires telling the world about the problem.

That's true, but the problem still has to be analyzed and a
recommendation formulated, which can take a little while.

> Any time Python has a problem of this sort, there is going to be at
> least one solution, and only possibly two:
>
> 1. Avoid the feature that represents a security risk
> 2. Eliminate the security risk in a maintenance update.

You forgot
3. install a patch as soon as you become aware of the problem,
without waiting for a maintenance update.

> By keeping the process public, and clearly identifying the problematic
> features, application developers can immediately start working on
> protecting themselves, in parallel with the CPython developers
> (possibly) working on a new maintenance release.

The hope is that during the short period in which there's a
confidential bug report in the system, the number of exploits in the
wild won't change. Either attackers knew about the bug already and
have exploits out before the bug is even reported, or they don't know
about it yet. Either way, random application developers get the bug
report at the same time as attackers. So the choices are that app
developers get a raw bug report and have to figure out a solution
while at the same time attackers who saw the same announcement are
starting to launch new exploits, or else when the app developers get
the bug report, they also get a bunch of analysis from the Python
developers, which can help them decide what to do next. I think they
benefit from the analysis, if they can get it.

Keep in mind also that the submitters of the bug reports often don't
see the full implications, that the app developers also might not see,
but that attackers are likely to figure out instantly. So again, it
helps if the Python developers can supply some analysis of their own.

Finally, some reports of security bugs turn out to not really be bugs
(I've submitted a few myself that have turned out that way). That
kind of thing can panic an application developer into shutting down a
service unnecessarily while figuring out what to do next, often at a
cost of kilobucks or worse per minute of downtime, or maybe having
some lesser fire drill to figure out that the problem is a
non-problem. Better to let the Python developers explain the problem
and close the bug before publishing it.

> To go with the 72 hours + 8 example you gave - what if you could work
> around the broken feature in 6?

If 6 hours from seeing the raw bug report are enough to analyze the
problem and develop a workaround, then given not only the raw bug
report but also 72 hours worth of analysis and recommendations/fixes
from the developers, I should need even less than 6 hours to install a
patch.

> I suspect we'll have to agree to disagree on this point. Where we can
> agree is that I certainly wouldn't be unhappy if SF had a feature like
> Bugzilla's security flag.

I do have to say that developer responsiveness to security issues
varies from one program to another. It's excellent for OpenBSD and
reasonably good for Mozilla; but for Python, it's something of a weak
spot, as we're seeing.

Nick> Upgrading your Python interpreter (even to a new maintenance
Nick> branch release) in a production environment is usually a fairly
Nick> involved exercise requiring a significant amount of testing, and
Nick> the fact of the matter is, you're unlikely to do so unless there
Nick> is some feature or bug-fix in a new version that you really
Nick> need. (I'm still using Python 2.2.2 at work - it's entirely
Nick> adequate for our needs, so there's no real pressure to upgrade on
Nick> the current project. For a new project, I'd probably start with
Nick> 2.4, planning to go to 2.4.1 in a couple of months time, but there
Nick> aren't really any post-2.2 additions to Python that I can't handle
Nick> living without).

Still, if a security bug was serious enough, my guess is that someone would
step up to supply patches (or Windows installers) for any of a number of
versions that were affected by the bug, even 2.1 or 1.5.2. That someone
might or might not be part of the core development team. That nothing like
that has been done before doesn't preclude it being done in the future.

Skip

In article <mailman.1566.1107005039.22381.python->,
Skip Montanaro <> wrote:
>
> Nick> Upgrading your Python interpreter (even to a new maintenance
> Nick> branch release) in a production environment is usually a fairly
> Nick> involved exercise requiring a significant amount of testing, and
> Nick> the fact of the matter is, you're unlikely to do so unless there
> Nick> is some feature or bug-fix in a new version that you really
> Nick> need. (I'm still using Python 2.2.2 at work - it's entirely
> Nick> adequate for our needs, so there's no real pressure to upgrade on
> Nick> the current project. For a new project, I'd probably start with
> Nick> 2.4, planning to go to 2.4.1 in a couple of months time, but there
> Nick> aren't really any post-2.2 additions to Python that I can't handle
> Nick> living without).
>
>Still, if a security bug was serious enough, my guess is that someone would
>step up to supply patches (or Windows installers) for any of a number of
>versions that were affected by the bug, even 2.1 or 1.5.2. That someone
>might or might not be part of the core development team. That nothing like
>that has been done before doesn't preclude it being done in the future.

While true, such coordination also requires public discussion, given the
way the Python community works. Which obviates the OPs request for
private correspondence.
--
Aahz () <*> http://www.pythoncraft.com/

"19. A language that doesn't affect the way you think about programming,
is not worth knowing." --Alan Perlis

Paul Rubin wrote:
> "Fuzzyman" <> writes:
> > The sourceforge bug tracker *is* the single right place to post
such
> > issues. The py-dev mailing list would be a second *useful* place to
> > post such a comment, although not really the right place. The OP
seemed
> > to want an individual with whom he could have a private
conversation
> > about it.
>
> I think he wanted a place to send a bug report that wouldn't be
> exposed to public view until the developers had a chance to issue a
> patch. With bugzilla, for example, you can check a bug labelled
"this
> is a security bug, keep it confidential". There's lots of dilemmas
> and some controversy about keeping any bug reports confidential in an
> open source system. But the general strategy selected by Mozilla
> after much debate seems to mostly work ok. It basically says develop
> a patch quickly, keep the bug confidential while the patch is being
> developed, and once the patch is available, notify distro maintainers
> to install it, and then after a short delay (like a couple days),
> publish the bug.
>
> Note that anyone with access to the bug (that includes the reporter
> and selected developers) can uncheck the box at any time, if they
> think the bug no longer needs to be confidential. The bug then
> becomes visible to the public.

Sounds like a useful feature request to Sourceforge.
Regards,

Fuzzy
http://www.voidspace.org.uk/python/index.shtml