Re: chkpass with RANDOMIZE_ALLOCATED_MEMORY

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: chkpass with RANDOMIZE_ALLOCATED_MEMORY
Дата
Msg-id 28865.1423933010@sss.pgh.pa.us
обсуждение исходный текст
Ответ на chkpass with RANDOMIZE_ALLOCATED_MEMORY  (Asif Naeem <anaeem.it@gmail.com>)
Ответы Re: chkpass with RANDOMIZE_ALLOCATED_MEMORY
Список pgsql-hackers
Asif Naeem <anaeem.it@gmail.com> writes:
> It is been observed on RANDOMIZE_ALLOCATED_MEMORY enabled PG95 build that
> chkpass is failing because of uninitialized memory and seems showing false
> alarm.

It's not a false alarm, unfortunately, because chkpass_in actually does
give different results from one call to the next.  We could fix the aspect
of that involving failing to zero out unused bytes (which it appears was
introduced by sloppy replacement of strncpy with strlcpy).  But we can't
really do anything about the dependency on random(), because that's part
of the fundamental specification of the data type.  It was a bad idea,
no doubt, to design the input function to do this; but we're stuck with
it now.

> I think these uninitialized memory areas are false alarms. Along with this
> there seems another issue that makes chkpass troubling
> RANDOMIZE_ALLOCATED_MEMORY comparison logic is that crypt() function is
> being passed with random salt value for DES based result. PFA patch, to
> generate consistent results, it uses constant salt value.

This is a seriously awful idea.  You can't break the fundamental behavior
of a data type (especially not in a way that introduces a major security
hole) just for the convenience of some debugging option or other.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: why does find_my_exec resolve symlinks?
Следующее
От: Andres Freund
Дата:
Сообщение: Re: gcc5: initdb produces gigabytes of _fsm files