On Thu, Oct 3, 2013 at 10:47 PM, Guido van Rossum <guido@python.org> wrote:
> Sounds a bit like some security researchers drumming up business. If you can
> run the binary, presumably you can also recover the seed by looking in
> /proc, right? Or use ctypes or something. This demonstration seems of
> academic interest only.

I'll not try to defend the opposite point of view very actively, but
let me just say that, in my opinion, your objection is not valid. �It
is broken the same way as a different objection, which would claim
that Python can be made sandbox-safe without caring about the numerous
segfault cases. �They are all very obscure for sure; I tried at some
point to list them in Lib/test/crashers. �I gave up when people
started deleting the files because they no longer crashed on newer
versions, just because details changed --- but not because the general
crash they explained was in any way fixed... �Anyway, my point is that
most segfaults can, given enough effort, be transformed into a single,
well-documented tool to conduct a large class of attacks.

The hash issue is similar. �It should be IMHO either ignored (which is
fine for a huge fraction of users), or seriously fixed by people with
the correctly pessimistic approach. �The current hash randomization is
simply not preventing anything; someone posted long ago a way to
recover bit-by-bit the hash randomized used by a remote web program in
Python running on a server. �The only benefit of this hash
randomization option (-R) was to say to the press that Python fixed
very quickly the problem when it was mediatized :-/

This kind of security issues should never be classified as "academic
interest only". �Instead they can be classified as "it will take weeks
/ months / years before some crazy man manages to put together a
general attack script, but likely, someone will eventually".

>From this point of view I'm saluting Christian's effort, even if I
prefer to stay far away from this kind of issues myself :-)

I don't want to defend my position too actively either: I'm fine with a new hash function as long as it's either faster, or safer and not slower, and I think that being able to change it at compile time is good enough.
">

(original) (raw)

On Thu, Oct 3, 2013 at 11:20 PM, Armin Rigo <arigo@tunes.org> wrote:

Hi Guido,


On Thu, Oct 3, 2013 at 10:47 PM, Guido van Rossum <guido@python.org> wrote:
\> Sounds a bit like some security researchers drumming up business. If you can
\> run the binary, presumably you can also recover the seed by looking in
\> /proc, right? Or use ctypes or something. This demonstration seems of
\> academic interest only.

I'll not try to defend the opposite point of view very actively, but
let me just say that, in my opinion, your objection is not valid. �It
is broken the same way as a different objection, which would claim
that Python can be made sandbox-safe without caring about the numerous
segfault cases. �They are all very obscure for sure; I tried at some
point to list them in Lib/test/crashers. �I gave up when people
started deleting the files because they no longer crashed on newer
versions, just because details changed --- but not because the general
crash they explained was in any way fixed... �Anyway, my point is that
most segfaults can, given enough effort, be transformed into a single,
well-documented tool to conduct a large class of attacks.

The hash issue is similar. �It should be IMHO either ignored (which is
fine for a huge fraction of users), or seriously fixed by people with
the correctly pessimistic approach. �The current hash randomization is
simply not preventing anything; someone posted long ago a way to
recover bit-by-bit the hash randomized used by a remote web program in
Python running on a server. �The only benefit of this hash
randomization option (-R) was to say to the press that Python fixed
very quickly the problem when it was mediatized :-/

This kind of security issues should never be classified as "academic
interest only". �Instead they can be classified as "it will take weeks
/ months / years before some crazy man manages to put together a
general attack script, but likely, someone will eventually".

\>From this point of view I'm saluting Christian's effort, even if I
prefer to stay far away from this kind of issues myself :-)

I don't want to defend my position too actively either: I'm fine with a new hash function as long as it's either faster, or safer and not slower, and I think that being able to change it at compile time is good enough.


However, I do want to object to the view (common among security "purists") that any vulnerability, no matter how hard to exploit (or fix) needs to be treated the same. I consider security work as a race of arms, where the effort spent on defense must be commensurate with the risk of attack. Just because your bike lock can still be busted by a professional bike thief (or picked by an ingenuous MIT student) that doesn't mean it's worthless -- especially if the unpickable lock might be worth (or weigh!) more than the bike.


A good defense combines multiple techniques -- e.g. common sense about when and where you park your bike together with a mediocre lock might make the theft risk acceptably low.


--
--Guido van Rossum (python.org/~guido)