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

Re: Eliminating the "rehash" mechanism for 5.18

Thread Previous | Thread Next
From:
demerphq
Date:
October 30, 2012 00:08
Subject:
Re: Eliminating the "rehash" mechanism for 5.18
Message ID:
CANgJU+XwHABqLaSSQkqhJqU2_DQ-NZ_Fqn0-40OVvCvZNpUsBg@mail.gmail.com
On Tuesday, 30 October 2012, Tony Cook wrote:

> 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
>

I think that would be very unlikely to work out well. Hash order is a
function of insertion order, bucket array size and hash value combined so i
am doubtful that the key list would expose enough information to an
attacker.

Also once these patches are in there will always be the possibility that
the hash algorithm in use is different from the default.

Yves


-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About