Subject: Re: bug#8427: [SECURITY] sql.el -- comint process passwords are leaked to ps(1) listing

From: Stefan Kangas <[email-masked]>
Date: Sun, 6 Oct 2019 05:28:00 +0200

Hi Andrew,

Andrew Hyatt <[email-masked]> writes:

> This is fairly easy to fix - mysql can check to see if the user entered
> a blank for the password prompt, and instead of not sending a password,
> send just the "--password" argument so the user can enter it into the
> process instead of the command line.  I have a fix ready to check in
> that works for mysql (I'm not sure which other products support that).

I think using an empty "--pasword" parameter sounds like the right fix.
That makes mysql prompt for the password, and we could supply it there
instead.  I guess that's what you meant?

Could you perhaps send your patch here for review?

> Alternatively, we can just have a variable that controls whether
> passwords are asked for on the command line at all (if sql-password is
> unset), which could default to nil, making the security better by
> default.

I'm not sure what this means, but I guess the above fix should be
enough.  Perhaps I'm missing something.

> BTW, I guess the attack here is that another user process can use
> something like strace to snoop on emacs's child processeses and obtain
> the mysql password?

Well, according to the threads linked earlier this can still be a
problem on Solaris, where the password is visible to all users if they
just run "ps".  Perhaps it's been fixed since whenever these comments
were written though...

> Stefan Monnier <[email-masked]> writes:
>
>>> Apparently, no they cannot, since mysql replaces the password characters
>>> with x's:
>>
>> Of course, that still leaves the chars exposed during a short time window.

And as Stefan explains here the password is still exposed during a
short time window even on GNU/Linux.  AFAIU, it's a possible race
attack which it would be nice to avoid.

Best regards,
Stefan Kangas