Re: Password leakage avoidance

On 1/6/24 13:16, Sehrope Sarkuni wrote:
> On Sat, Jan 6, 2024 at 12:39 PM Joe Conway <mail(at)joeconway(dot)com
> <mailto:mail(at)joeconway(dot)com>> wrote:
>
> The only code specific comments were Tom's above, which have been
> addressed. If there are no serious objections I plan to commit this
> relatively soon.
>
>
> One more thing that we do in pgjdbc is to zero out the input password
> args so that they don't remain in memory even after being freed. It's
> kind of odd in Java as it makes the input interface a char[] and we have
> to convert them to garbage collected Strings internally (which kind of
> defeats the purpose of the exercise).
>
> But in libpq could be done via something like:
>
> memset(pw1, 0, strlen(pw1));
> memset(pw2, 0, strlen(pw2));

That part is in psql not libpq

> There was some debate on our end of where to do that and we settled on
> doing it inside the encoding functions to ensure it always happens. So
> the input password char[] always gets wiped regardless of how the
> encoding functions are invoked.
>
> Even if it's not added to the password encoding functions (as that kind
> of changes the after effects if anything was relying on the password
> still having the password), I think it'd be good to add it to the
> command.c stuff that has the two copies of the password prior to freeing
> them.

While that change might or might not be worthwhile, I see it as
independent of this patch.

--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com