This may be known but I wanted to ask this esteemed body first.
I understand that from Python3.3 there was a security fix to ensure that
different python processes would generate different hash value for the
same input - to prevent denial of service based on crafted hash conflicts.
I opened two python REPLs on my Linux 64bit PC and did the following
Terminal 1:
>>> hash('Hello World')
-1010252950208276719
>>> hash( frozenset({1,9}) )
-7625378979602737914
>>> hash(frozenset({300,301}))
-8571255922896611313
>>> hash((1,9))
3713081631926832981
>>> hash((875,932))
3712694086932196356
Terminal 2:
>>> hash('Hello World')
-8267767374510285039
>>> hash( frozenset({1,9}) )
-7625378979602737914
>>> hash(frozenset({300,301}))
-8571255922896611313
>>> hash((1,9))
3713081631926832981
>>> hash((875,932))
3712694086932196356
As can be seen - taking a hash of a string does indeed create a
different value between the two processes (as expected).
However the frozen set hash, the same in both cases, as is the hash of
the tuples - suggesting that the vulnerability resolved in Python 3.3
wasn't resolved across all potentially hashable values. lI even used
different large numbers to ensure that the integers weren't being interned.
I can imagine that frozensets aren't used frequently as hash keys - but
I would think that tuples are regularly used. Since that their hashes
are not salted does the vulnerability still exist in some form ?.
--
--
Anthony Flury
email : *[email protected]*
Twitter : *@TonyFlury <https://twitter.com/TonyFlury/>*
_______________________________________________
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com