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]

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.

 

[grahamd]

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]

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.

 

[phr]

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.

 

[Fredrik Lundh]

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>

 

[Duncan Booth]

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?

 

[Paul Rubin]

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.

 

[Fredrik Lundh]

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]

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/python-bugs-list/2001-October/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]

SF doesn't seem to know about any such bug any more.
Google finds me
http://mail.python.org/pipermail/python-bugs-list/2001-October/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]

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

 

[Paul Rubin]

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]

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]

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:

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.

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]

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.

 

[Tim Peters]

[[email protected]]

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:[email protected]>. 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]

[[email protected]]

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:[email protected]>. 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? ;-)

 

[Terry Reedy]

OP:
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