[Python-Dev] Make str/bytes hash algorithm pluggable? (original) (raw)

Guido van Rossum guido at python.org
Sat Oct 5 17:25:01 CEST 2013

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>

More information about the Python-Dev mailing list