Re: A worst case for qsort
| От | John Cochran |
|---|---|
| Тема | Re: A worst case for qsort |
| Дата | |
| Msg-id | CAGQU3n7ZPPLN9C2pcXrp9UoOOFMm-Y4g0jFAVufCHEX8-L3-Zg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: A worst case for qsort (Fabien COELHO <coelho@cri.ensmp.fr>) |
| Ответы |
Re: A worst case for qsort
|
| Список | 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 по дате отправления: