Who should security issues be reported to?

[grahamd]

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.

[Aahz]

In article <11*********************@f14g2000cwb.googlegroups. com>,
<gr*****@dscpl.com.au> 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.

There is no generally appropriate non-public mechanism for reporting
security issues. If you really think this needs to be handled
privately, do some research to find out which core developer is most
likely to be familiar with it. Even before you do that, check
SourceForge to find out whether anyone else has reported it as a bug.
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

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

[grahamd]

Aahz wrote:

In article <11*********************@f14g2000cwb.googlegroups. com>,
<gr*****@dscpl.com.au> 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.

There is no generally appropriate non-public mechanism for reporting
security issues. If you really think this needs to be handled
privately, do some research to find out which core developer is most
likely to be familiar with it. Even before you do that, check
SourceForge to find out whether anyone else has reported it as a bug.

I find this response a bit dissappointing frankly. Open Source people
make
such a big deal about having lots of people being able to look at
source
code and from that discover security problems, thus making it somehow
making it better than proprietary source code. From what I can see, if
an
Open Source project is quite large with lots of people involved, it
makes it
very hard to try and identify who you should report something to when
there is no clearly identifiable single point of contact for security
related
issues. Why should I have to go through hoops to try and track down who
is appropriate to send it to? All you need is a single advertised email
address
for security issues which is forwarded onto a small group of developers
who can then evaluate the issue and forward it on to the appropriate
person.
Such developers could probably do such evaluation in minutes, yet I
have
to spend a lot longer trying to research who to send it to and then
potentially
wait days for some obscure person mentioned in the source code who has
not touched it in years to respond, if at all. Meanwhile you have a
potentially
severe security hole sitting there wating for someone to expliot, with
the
only saving grace being the low relative numbers of users who may be
using
it in the insecure manner and that it would be hard to identify the
actual web
sites which suffer the problem.

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.

And yes I have tried mailing the only people mentioned in the module in
question and am still waiting for a response.

[Nick Coghlan]

gr*****@dscpl.com.au 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?

Cheers,
Nick.

--
Nick Coghlan | nc******@email.com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net

[phr]

Nick Coghlan <nc******@iinet.net.au> writes:

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?

Tell me about it. See the "rotor replacement" thread.

[Duncan Booth]

gr*****@dscpl.com.au wrote:

I find this response a bit dissappointing frankly. Open Source people
make
such a big deal about having lots of people being able to look at
source
code and from that discover security problems, thus making it somehow
making it better than proprietary source code.

I think part of the problem you are having is that Python doesn't make any
representations about security, so it is pretty hard to come up with issues
which really are security related. Products which are based on Python (e.g.
Zope) and which do aim to provide some kind of secure environment probably
will have some clear mechanism for reporting security related issues.

The only part of Python which used to claim to offer security was rexec and
the bastion module, but they had so many security issues that they were
removed from the distribution.

In other words, I'm intrigued how you managed to come up with something you
consider to be a security issue with Python since Python offers no
security. Perhaps, without revealing the actual issue in question, you
could give an example of some other situation which, if it came up in
Python you would consider to be a security issue?

[Fredrik Lundh]

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>

[Paul Rubin]

Duncan Booth <du**********@invalid.invalid> writes:

In other words, I'm intrigued how you managed to come up with something you
consider to be a security issue with Python since Python offers no
security. Perhaps, without revealing the actual issue in question, you
could give an example of some other situation which, if it came up in
Python you would consider to be a security issue?

Until fairly recently, the pickle module was insufficiently documented
as being unsafe to use with hostile data, so people used it that way.
As a result, the Cookie module's default settings allowed remote
attackers to take over Python web apps. See SF bug 467384.

[Richie Hindle]

[Duncan]

I'm intrigued how you managed to come up with something you
consider to be a security issue with Python since Python offers no
security. Perhaps, without revealing the actual issue in question, you
could give an example of some other situation which, if it came up in
Python you would consider to be a security issue?

I can't speak for the OP, but one hypothetical example might be a buffer
overrun vulnerability in the socket module.

--
Richie Hindle
ri****@entrian.com

[Fredrik Lundh]

Duncan Booth wrote:

I think part of the problem you are having is that Python doesn't make any
representations about security, so it is pretty hard to come up with issues
which really are security related. Products which are based on Python (e.g.
Zope) and which do aim to provide some kind of secure environment probably
will have some clear mechanism for reporting security related issues.

security issues occur when code that claims to do something can be used to do
something entirely different, by malevolent application users.

(wxPython doesn't make any security claims either, but if it turned out that you
could gain root access, modify the underlying database, modify variables in the
program, execute arbitrary code, or some other similar thing simply by typing the
right things into a password entry field, wouldn't you consider that a security
issue?)

(no, this issue isn't related to wxPython)

</F>

[Duncan Booth]

Paul Rubin wrote:

Duncan Booth <du**********@invalid.invalid> writes:

In other words, I'm intrigued how you managed to come up with
something you consider to be a security issue with Python since
Python offers no security. Perhaps, without revealing the actual
issue in question, you could give an example of some other situation
which, if it came up in Python you would consider to be a security
issue?

Until fairly recently, the pickle module was insufficiently documented
as being unsafe to use with hostile data, so people used it that way.
As a result, the Cookie module's default settings allowed remote
attackers to take over Python web apps. See SF bug 467384.

SF doesn't seem to know about any such bug any more.
Google finds me
http://mail.python.org/pipermail/pyt...er/007669.html
which appears to be SF bug 467384, but it says nothing about security or
the Cookie module, just that you wanted better documentation.

I think its a bit borderline whether this really was a security bug in
Python rather than just a problem with the way some people used Python. It
was a standard library which if used in the wrong way opens a security hole
on your machine, but there are plenty of ways to open security holes.
The response seems to have been to document that there is a security
concern here, but it is still just as possible to use python to expose your
machine to attack as it was before.

But thanks anyway, it does give me the sort of example I was asking for.

[Paul Rubin]

Duncan Booth <du**********@invalid.invalid> writes:

SF doesn't seem to know about any such bug any more.
Google finds me
http://mail.python.org/pipermail/pyt...er/007669.html
which appears to be SF bug 467384, but it says nothing about security or
the Cookie module, just that you wanted better documentation.
The Cookie issue is discussed some in that bug thread. But more
relevant is bug 471893. Sorry.
I think its a bit borderline whether this really was a security bug in
Python rather than just a problem with the way some people used Python.

If using a module the way it's documented results in a security hole,
that's definitely a security bug.

If using the module in an obvious and natural way that looks correct
results in a security hole, I'd say it's at least an issue needing
attention, even if some sufficiently hairsplitting reading of the
documentation says that usage is incorrect. Principle of least
astonishment.

I highly recommend reading the book "Security Engineering" by Ross
Anderson if you're trying to implement anything that might ever be
exposed to malicious parties. That includes any application that
communicates over the internet (such as web servers or clients), and
it includes any application that processes data downloaded from the
internet (such as jpeg viewers). Each of those classes of programs
has had examples of where hostile data could take over the
application.

[Fuzzyman]

gr*****@dscpl.com.au wrote:

Aahz wrote:

In article <11*********************@f14g2000cwb.googlegroups. com>,
<gr*****@dscpl.com.au> wrote:

Who are the appropriate people to report security problems to in
respect of a module included with the Python distribution? I don'tfeel it appropriate to be reporting it on general mailing lists.
There is no generally appropriate non-public mechanism for reporting security issues. If you really think this needs to be handled
privately, do some research to find out which core developer is most likely to be familiar with it. Even before you do that, check
SourceForge to find out whether anyone else has reported it as a

bug.
I find this response a bit dissappointing frankly. Open Source people
make
such a big deal about having lots of people being able to look at
source
code and from that discover security problems, thus making it somehow
making it better than proprietary source code. From what I can see, if an
Open Source project is quite large with lots of people involved, it
makes it
very hard to try and identify who you should report something to when
there is no clearly identifiable single point of contact for security
related
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.

Regards,
Fuzzy
http://www.voidspace.org.uk/python/index.shtml
issues. Why should I have to go through hoops to try and track down who is appropriate to send it to? All you need is a single advertised email address
for security issues which is forwarded onto a small group of developers who can then evaluate the issue and forward it on to the appropriate
person.
Such developers could probably do such evaluation in minutes, yet I
have
to spend a lot longer trying to research who to send it to and then
potentially
wait days for some obscure person mentioned in the source code who has not touched it in years to respond, if at all. Meanwhile you have a
potentially
severe security hole sitting there wating for someone to expliot, with the
only saving grace being the low relative numbers of users who may be
using
it in the insecure manner and that it would be hard to identify the
actual web
sites which suffer the problem.

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.

And yes I have tried mailing the only people mentioned in the module in question and am still waiting for a response.

[Paul Rubin]

"Fuzzyman" <fu******@gmail.com> 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.

[Fredrik Lundh]

Duncan Booth wrote:

I think its a bit borderline whether this really was a security bug in
Python rather than just a problem with the way some people used Python. It
was a standard library which if used in the wrong way opens a security hole
on your machine

for SmartCookie, that should be "if used, opens a security hole"

</F>

[Duncan Booth]

Paul Rubin wrote:

The Cookie issue is discussed some in that bug thread. But more
relevant is bug 471893. Sorry.
Thanks. There's an interesting comment in that thread:

A.M. Kuchling (akuchling) wrote: Date: 2003-02-06 09:29

The Cookie classes that use pickle have DeprecationWarnings in
2.3, and should disappear in 2.4.

Its a real pity that nobody seems to have remembered to actually remove
them.

I think its a bit borderline whether this really was a security bug in
Python rather than just a problem with the way some people used Python.

If using a module the way it's documented results in a security hole,
that's definitely a security bug.

If using the module in an obvious and natural way that looks correct
results in a security hole, I'd say it's at least an issue needing
attention, even if some sufficiently hairsplitting reading of the
documentation says that usage is incorrect. Principle of least
astonishment.

Agreed. Principle of least astonishment is definitely good.

[Aahz]

In article <11**********************@f14g2000cwb.googlegroups .com>,
<gr*****@dscpl.com.au> wrote:

Aahz wrote:

In article <11*********************@f14g2000cwb.googlegroups. com>,
<gr*****@dscpl.com.au> 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.
There is no generally appropriate non-public mechanism for reporting
security issues. If you really think this needs to be handled
privately, do some research to find out which core developer is most
likely to be familiar with it. Even before you do that, check
SourceForge to find out whether anyone else has reported it as a bug.

I find this response a bit dissappointing frankly. Open Source people
make such a big deal about having lots of people being able to look at
source code and from that discover security problems, thus making it
somehow making it better than proprietary source code.

That's generally true, but not universally. The key point you seem to
have missed in my response is "non-public mechanism". Historically,
Python security issues have been thrashed out in public; the Python
project does not have a release cycle that makes it possible to quickly
address security concerns, so keeping it private has little point.

Your decision to take the private route makes it your responsibility to
search for an appropriate mechanism.
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.

As other people said, sounds like you want to volunteer for this. Which
would be fine -- but there's still not much point until/unless we get
enough volunteers to manage quicker release cycles. Then there's still
the problem of getting people to update their local copies of Python.
This is a complex issue.
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

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

[Tim Peters]

[gr*****@dscpl.com.au]

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.

The Python project has no non-public resources for this. Filing a bug
report on SourceForge is the usual approach. If you must, you could
send email directly to Guido <mailto:gu***@python.org>. He may or may
not have time to follow up on it; public disclosure is the norm in
this project. Be forewarned that despite that he currently works for
a security startup, his threshold for "security panic" is very high.

[Aahz]

In article <ma***************************************@python. org>,
Tim Peters <ti********@gmail.com> wrote:

[gr*****@dscpl.com.au]

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.

The Python project has no non-public resources for this. Filing a bug
report on SourceForge is the usual approach. If you must, you could
send email directly to Guido <mailto:gu***@python.org>. He may or may
not have time to follow up on it; public disclosure is the norm in
this project. Be forewarned that despite that he currently works for
a security startup, his threshold for "security panic" is very high.

You mean s/despite/because/ don't you? ;-)
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

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

[Terry Reedy]

OP:

I find this response a bit dissappointing frankly. Open Source people
make such a big deal about having lots of people being able to look at
source code and from that discover security problems, thus making it
somehow making it better than proprietary source code.

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?

Everyone: I say 'supposed' because
a) The OP has provided no info about his/her claim.
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.
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.

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.

Terry J. Reedy

[grahamd]

> 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. :-)

[Nick Coghlan]

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 | nc******@email.com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net

[Nick Coghlan]

gr*****@dscpl.com.au 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 | nc******@email.com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net

[Paul Rubin]

Nick Coghlan <nc******@iinet.net.au> 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.

[Nick Coghlan]

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 | nc******@email.com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net

[Paul Rubin]

Nick Coghlan <nc******@iinet.net.au> 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.

[Skip Montanaro]

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

[Aahz]

In article <ma***************************************@python. org>,
Skip Montanaro <sk**@pobox.com> 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 (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

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

[Fuzzyman]

Paul Rubin wrote:

"Fuzzyman" <fu******@gmail.com> 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