On Thu, Oct 3, 2013 at 11:20 PM, Armin Rigo <ar...@tunes.org> wrote: > Hi Guido, > > On Thu, Oct 3, 2013 at 10:47 PM, Guido van Rossum <gu...@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)
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
