Re: A worst case for qsort - Mailing list pgsql-hackers

From John Cochran
Subject Re: A worst case for qsort
Date
Msg-id CAGQU3n7ZPPLN9C2pcXrp9UoOOFMm-Y4g0jFAVufCHEX8-L3-Zg@mail.gmail.com
Whole thread Raw
In response to Re: A worst case for qsort  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: A worst case for qsort
List pgsql-hackers
I just browsed the paper linked by Peter and it looks like the attack has to be active against a currently executing qsort. In the paper, what happens is the comparison function is supplied by the attacker and effectively lies about the result of a comparison. It keeps the lies consistent in a very specific manner so that eventually qsort returns its input in a properly sorted fashion.

So it seems to me that the vulnerability only exits if an attacker supplied comparison function is permitted. For all other cases, assuming that only vetted comparison functions are permitted, the selection of a random pivot would make an attack on qsort using specially tailored input data improbable.




pgsql-hackers by date:

Previous
From: Bill Epstein
Date:
Subject: Questions on dynamic execution and sqlca
Next
From: Stephen Frost
Date:
Subject: Re: Questions on dynamic execution and sqlca