Re: chkpass with RANDOMIZE_ALLOCATED_MEMORY - Mailing list pgsql-hackers

From Tom Lane
Subject Re: chkpass with RANDOMIZE_ALLOCATED_MEMORY
Date
Msg-id 28865.1423933010@sss.pgh.pa.us
Whole thread Raw
In response to chkpass with RANDOMIZE_ALLOCATED_MEMORY  (Asif Naeem <anaeem.it@gmail.com>)
Responses Re: chkpass with RANDOMIZE_ALLOCATED_MEMORY  (Amit Kapila <amit.kapila16@gmail.com>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: why does find_my_exec resolve symlinks?
Next
From: Andres Freund
Date:
Subject: Re: gcc5: initdb produces gigabytes of _fsm files