Question about the security of the GnuPG Agent with regard to cryptographic material scrubbing

[gnupg at raf.org]

Ciprian Dorin Craciun wrote:

> On Tue, Feb 26, 2019 at 12:58 PM Sarun Intaralawan
> <sarunint at sarunint.com> wrote:
> > I'm not able to answer your main question, but I believe it is you
> > explained. However, regarding the matter in P.S., I'm glad to inform
> > you that such a tool exists. It is called pass [1] and it is fully
> > integrated with GnuPG and Git. So you can backup your password like
> > a Git repository.
> 
> I know about that tool, however it is unfortunately written also in
> Bash, which as my own implementation has countless ways to
> (permanently) leak the password.
> 
> For example take the following commit:
>     https://git.zx2c4.com/password-store/commit/src/password-store.sh?id=367efa5846492e1b0898aad8a2c26ce94163ba24
> 
> Which has the following change:
> ~~~~
> - $GPG -e "${GPG_RECIPIENT_ARGS[@]}" -o "$passfile" "${GPG_OPTS[@]}"
> <<<"$password" || die "Password encryption aborted."
> + echo "$password" | $GPG -e "${GPG_RECIPIENT_ARGS[@]}" -o "$passfile"
> "${GPG_OPTS[@]}" || die "Password encryption aborted."
> ~~~~
> 
> In was committed in 2018, but the tool is from 2015, thus in the
> interim all the passwords were leaked into `$TMPDIR` and thus on the
> disk, which in most cases is actually the `rootfs`.  Thus without much
> effort, one can take out the HDD, and just run a file-system recovery
> tool to recover deleted files, or dump ASCII tokens, and thus get
> access to the used passwords.

The new version still leaks, just not as badly
(permanently). On Linux, for example, unless system
call tracing and arbitrary RAM reading has been
completely disabled, even for root, with "sysctl
kernel.yama.ptrace_scope=3", the password will appear
in ptrace/strace/ltrace output when $GPG reads stdin.

Admittedly, there needs to be an adversary with root
privileges (or the user's privileges) active on the
host at the time but it's still a potential leak. And
it might make its way to swap which might not be
encrypted.

Even with kernel.yama.ptrace_scope=3, systemtap or
dtrace (on hosts that have it) can probably see the
password.

It's probably impossible to completely avoid
(transient) leaks without hardware cryptographic
modules. But of course, that's no reason not to do
whatever you can to make it as difficult as possible
for an adversary.

> I'm not criticizing the `pass` tool, as I know myself how hard it is
> to write a tool that doesn't leak data, however any such tool should
> come with a big warning to its users.
> 
> Unfortunately on the project page there is no mention of its security
> weaknesses or any hint to the users about possible data leaks.
> 
> Ciprian.

[The rest is even more off-topic for this list]
 
To be fair, all software probably has unknown security
bugs. Warning users about the possibility before you
know that there's a problem might seem alarmist. But if
a security bug has been identified and fixed, users
should be notified if there's anything that they need
to do. Changelogs at least should highlight security
bug fixes.

In that commit, the author said that "Do not put
passwords in herestrings: Bash sometimes writes these
into temporary files, which isn't okay". If it is only
sometimes, maybe bash only uses temporary files for
here strings when they are large. If that's the case,
the passwords might never have been written to disk.
So it might be OK. However, it's not sometimes.
It's always:

  $ bash -c 'lsof -a -p $$ -d0' <<< Password1
  COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF    NODE NAME
  lsof    24183  raf    0r   REG  253,1       10 7864877 /tmp/zshz9mNt3 (deleted)

So the commit message wasn't alarmist enough. And there
doesn't seem to be a Changelog file for pass or a
news or security notices section on its website.

Maybe you could submit a bug report for the
passwordstore.org website about its lack of a news or
security notices section for notifying users about
security issues.

I suppose the remedy is to cryptographically shred free
space if users didn't already have full disk encryption
(and hope they don't have SSDs). It would be good if
pass users were notified of that.

cheers,
raf