[Python-Dev] Make str/bytes hash algorithm pluggable?

[Guido van Rossum]

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

> Hi Guido,
>
> On Thu, Oct 3, 2013 at 10:47 PM, Guido van Rossum <guido at 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131005/d2abb489/attachment.html>