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@joeconway.com 
> <mailto:mail@joeconway.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