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 31, 2012 01:33
Subject:
Re: Eliminating the "rehash" mechanism for 5.18
Message ID:
CANgJU+W-0RE6pKNgP9qbc4HUWC0AWZMoGfaEOzuCWhehkSU9MQ@mail.gmail.com
On 30 October 2012 22:57, Eric Brine <ikegami@adaelis.com> wrote:
> On Tue, Oct 30, 2012 at 9:35 AM, Ed Avis <eda@waniasset.com> wrote:
>>
>> If the hash random seed isn't changed on forking, then
>
> ...there's a security weakness. Is it one we're willing to accept? Probably.

I agree if there is a security weakness there it is an acceptable
weakness. On the other hand we simply cannot change the hash seed on
forking without huge changes to Perl. All of perls internals are built
on top of hashes. If you change the seed mid run then every existing
hash will be broken.

> If you have a deamon written in Perl that forked off for every request, and
> that the response shows the output
>
>
>>
>> conceivably a privileged daemon could fork off child process which drop
>> their
>>
>> privileges or run as a different user account.
>
>
> Or perhaps if the child processes has outputs that are based on the hash
> order of inputs placed in a hash. How many hashes does one need to build to
> determine the seed?

The only ways that I can think you might do it would be in of
themselves denial of service attacks and be noticed long before the
attacker would have enough information to create a crafty request.

Its worth noting a couple of details here. The order a set of keys are
in a hash is determined by: hash seed + hash function, size of the
bucket array when they are inserted, insertion order, and the number
of bucket array resizes since they have been inserted.

A bucket array is always a power of two elements (K) large (starting
at 8), and we use the rightmost K bits of the hash value (a 32 bit
number), to map it into a bucket. On insert we insert into the top of
the bucket chain. If we put more than 2**k items in a hash we trigger
a resize, which doubles the size of the bucket array, we then walk the
first half of the bucket array, and for each element in a bucket that
needs to move we insert into the equivalent bucket in the second half
of the array. This means that if you had  "a" "b" "c" "d" (which
itself would be the result of inserting it as "d" "c" "b" "a"), and
"b" and "c" moved then they would end up in the new bucket as "c" and
"b" but the old bucket would contain "a" "d". Any further inserts
would then occur again at the top of the bucket chain.

So to me this would be a huge undertaking.

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