develooper Front page | perl.perl5.porters | Postings from October 2012

Re: Eliminating the "rehash" mechanism for 5.18

Thread Previous | Thread Next
Tony Cook
October 29, 2012 16:23
Re: Eliminating the "rehash" mechanism for 5.18
Message ID:
On Mon, Oct 29, 2012 at 06:55:21PM +0100, demerphq wrote:
> The attack that this is intended to defuse is that where an attacker
> constructs a series of string which are known to collide and then
> manages to feed them to a Perl process which uses them to construct a
> hash. All further access to the hash then becomes a search against an
> un-ordered linked list. This attack is more than a theoretical
> possibility because of  the fact that Perl has by default used a
> compile time determined constant and poorly chosen hash seed for its
> hash algorithm. Meaning that one can use a perl on one box to attack a
> perl on another box.

(/me puts his paranoid hat on)

For an attack on a long lived process, if the process ever returns the
contents of a hash in hashed order, could this be used to determine
the process hash seed?

If so, it could be used to perform the attack we're trying to prevent.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About