D295: 667_0002-enforce-std-gnu-11-to-avoid-breakage-with-gcc5.patch

the attached patch is a minimal patch to make older versions of pinentry-qt4
build cleanly with newer gcc.

so far, the proposed mechanisms for getting at gpg-agent's memory from a peer
process running as the same user are:

a) ptrace (e.g. via /usr/bin/gcore or /usr/bin/strace)
b) /proc/$PID/mem, which is owned by the user and mode 0600

DarkStarSword's patch effectively closes (a) (by rejecting ptrace connections)
and appears on my GNU/Linux system to close (b) as well: /proc/$PID/mem is
root-owned when the patch is applied instead of being user-owned.

Are there other channels for per-process memory access that we should be
thinking about?

I agree with Werner and Neal that the UNIX model is probably insufficient to
close all the holes easily, but i also don't think that's a good reason to avoid
closing those holes we can close.

If there are other ways that another process by the same user can get at the
RAM, please point them out and i'll look into ways to address them too.

In the meantime, i'll also look into ways to facilitate running the process as a
separate user account entirely.

D128: 666_0003-Avoid-simple-memory-dumps-via-ptrace.patch

I'm going to introduce the prctl(SET_DUMPABLE, 0) change to main in
agent/gpg-agent.c in the debian 2.1.x series as of 2.1.7-1, using the patch i'm
attaching here.

I make no representations that this solves all possible memory leakages, but it
does address one specific and relatively straightforward attack.

As to Werner's legitimate concerns about making debugging harder, there remain
at least two options: ptrace as the superuser, and launching gpg-agent itself
under gdb directly.

If this experiment proves disastrous somehow (i'm not seeing how), we can always
revert the patch.

I agree with you that the standard UNIX model is generally insufficient here.

Perhaps the distros could weigh in with mechanisms to facilitate
secondary-account creation for agents and the like. I've opened
https://bugs.debian.org/794667 about this.

However, i don't think the weak UNIX permissions model is a reason to avoid a
small piece of code like that offered by DarkStarSword below. Closing off one
avenue of attack is still worthwhile, even if other avenues remain. As werner
said, gpg-agent won't create a coredump (even though other avenues of attack are
possible).

Is there something about the complexity of prctl(PR_SET_DUMPABLE, 0); that makes
it undesirable?

fwiw, i'd be fine with enabling protection against ptrace for gpg-agent, even if
that doesn't fix all the other ways a process can be attacked from another process.

if there are multiple holes, we should plug the ones we can plug, to increase
the pressure to make the other ones fixable.

If pinentry-emacs doesn't need to be distributed, why do we even have it as a
separate target (emacs/pinentry-emacs) that is enabled by default?

my concern about abuse of INSIDE_EMACS is as i said "vague" -- sorry, i hope
it's not FUD! here's a rough sketch:

pinentry is a sensitive program. its job is to protect sensitive data (secret
key material, passphrases) from unintended use. each hook that we put into
pinentry to allow an attacker to probe its contents, or to execute commands, or
to control the UI/UX of what is presented to the user, is another hook that can
be used to violate the protection we want gpg-agent to afford its users.

Consider an attacker who has access only to the gpg-agent socket, and to one
other socket on the system. If they can convince gpg-agent to talk to them on
that one other socket by setting INSIDE_EMACS during a communication to
gpg-agent, this seems like a risk. furthermore, it's an unnecessary risk for
users who have no intention of interacting with gpg-agent through emacs in this
way. (e.g. users of emacs under X11 sessions may prefer to use a graphical
agent, or users of emacs from a terminal may prefer pinentry-curses). it's not
clear if there's a way to tell gpg-agent at runtime to avoid this additional
communications vector either.

So the implication here is that users who want to use XDG_RUNTIME_DIR can do:

echo '%Assuan%' > ~/.gnupg/S.gpg-agent
echo '${XDG_RUNTIME_DIR}/S.gpg-agent' >> ~/.gnupg/S.gpg-agent

and it will Just Work for those with an NFS homedir?

Even on non-NFS volumes, this has the nice property that gpg-agent's
"check-own-socket" feature should be able to close down the gpg-agent process
when it's no longer needed by an active session.

What would the failure conditions be if that variable isn't actually set,
though? I guess it would be the same as specifying /S.gpg-agent, which should
result in permission denied, which means a failed gpg-agent. Is that right?

Will 1.4.x or 2.0.x respect such a redirection if they find it in the socket
they're trying to talk to, or is this a 2.1.x-only feature?

Looks to me like it just fails silently.

We can already do a dummy signature, but it feels sloppy for several reasons:

• it's not clear exactly what to sign with a dummy signature -- should you sign

static text or a dynamic (random) block?

• it's not clear what to do with the signatures after creation. It's

concievable that a dummy signature could be abused/misused if the material being
signed turns out to have some other meaning.

• gpg-agent can be configured to log to an append-only file as a means of

monitoring what signatures have ever been made by a given key. Dummy signatures
introduce spurious signing events that are indistinguishable from real
signatures in this log

• the creation of arbitrary signatures takes more time than testing passphrase

and returning feedback.

Hm, you make a good point about this being undesirable in the general case --
access to a normal gpg-agent shouldn't provide an attacker with a way to guess
passwords silently.

However, consider the mailpile case -- where gpg-agent is running on the
webserver, and the login webpage wants to verify a given user based on the
password for the user's secret key (and wants to avoid keeping some extra
/etc/shadow-equivalent file lying around).

Maybe such an application would start gpg-agent in a different/simpler mode? Or
should we recommend that such an application test the provided passphrase in
some other way, without using gpg-agent at all?

D306: 630_0001-gpg-Avoid-cluttering-stdout-with-trustdb-info-in-ver-STABLE-1-4.patch

And here is a backport to STABLE-BRANCH-1-4

I think Werner addressed this on 2.1 with:

b03a2647299a6c8764a2574590cbaccdff9e497d

Attached is a backport of this patch to STABLE-BRANCH-2-0.

D307: 629_0001-gpg-Avoid-cluttering-stdout-with-trustdb-info-in-ver.patch

ah, right! the other option is to pass mb->size instead of size in the memset call.

We should really synchronize secmem.c between libgcrypt:src/secmem.c,
pinentry:secmem/secmem.c, and gpg-STABLE-BRANCH-1-4:util/secmem.c :/

OK, something is definitely wrong with the secmem allocators.

I applied this patch:

diff --git a/secmem/secmem.c b/secmem/secmem.c
index 9a478cf..bf97a2a 100644

• a/secmem/secmem.c

+++ b/secmem/secmem.c
@@ -381,11 +381,16 @@ secmem_realloc( void *p, size_t newsize )

mb = (MEMBLOCK*)((char*)p - ((size_t) &((MEMBLOCK*)0)->u.aligned.c));
size = mb->size;

+ printf("A: %d\n", mb->size);

    if( newsize < size )
	return p; /* it is easier not to shrink the memory */

+ printf("B: %d\n", mb->size);

a = secmem_malloc( newsize );

+ printf("C: %d\n", mb->size);

memcpy(a, p, size);

+ printf("D: %d\n", mb->size);

memset((char*)a+size, 0, newsize-size);

+ printf("E: %d\n", mb->size);

secmem_free(p);
return a;

}

and ran pinentry-gtk-2 with "getpin" as an input and typed in 32 characters for
the dialog box. at character 16, it printed:

A: 32
B: 32
C: 32
D: 32
E: 32

and at character 32 it printed:

A: 0
B: 0
C: 0
D: 0
E: 0

I'm beginning to suspect that this allocator never worked quite right, and that
1d3583a2562e83496ac515276e9bd63a7f1abbc7 just exposes a flaw in the addressing.

Tracking this down further, it appears to be caused by
1d3583a2562e83496ac515276e9bd63a7f1abbc7.

If i revert that commit, the problem goes away.

This makes me think something is wrong with secmem_realloc or secmem_malloc.

thanks, neal. I see this committed as eab03a469d82018e53380f26390594f47bb4c5c8,
with a committer of "us <us@chu.huenfield.org>" -- since huenfield.org is
registered to you, i assume that's you? I'm used to seeing your commits as
coming from "Neal H. Walfield <neal@gnu.org>"

on the debian bug report, Felix Geyer notes:

This issue is still present.
Tested on current Debian unstable [0.9.2-1] with KDE4 and Ubuntu 15.04 with

KDE Plasma 5.

The patch from the Fedora package fixes the problem.

I note that this isn't yet applied upstream as of
55ea554b2020b1e7b0996bd9f7bb38c8af2b03f3 -- maybe this can be considered before
the next release?

(neal, i'm adding you to the "nosy list" here and assigning this ticket to you,
because of all your work on pinentry lately. I hope that's not overstepping any
boundaries! please let me know if you'd rather i didn't do that directly)

So what should we do about this? Do we need to keep gtksecentry.* in sync with
upstream's gtkentry somehow?

On a debian system, i did:

   apt install --no-install-recommends scim scim-gtk-immodule

Here is a transcript of pinentry being invoked: there is additional scim-related
output:

0 dkg@alice:~$ GTK_IM_MODULE=scim pinentry-gtk-2
OK Your orders please
GETPIN
Loading simple Config module ...
Creating backend ...
Loading socket FrontEnd module ...
Starting SCIM as daemon ...
Loading socket Config module ...
Creating backend ...
Loading x11 FrontEnd module ...
GTK Panel of SCIM 1.4.15

Starting SCIM as daemon ...

at this point, no keyboard entry works in the module at all.

This is https://bugs.debian.org/750521

pinentry GTK-2 is still failing to accept any keyboard input when invoked with
GTK_IM_MODULE=scim

D303: 609_559936.patch

the reporter noted the same problem in 0.9.0, not just 0.7.6.

still, a re-test with 0.9.2 would be useful

sorry, that should be https://bugs.debian.org/581617 instead.

D302: 608_0001-Fix-qt4-pinentry-window-created-in-the-background.patch

Yes, auto-detection in dirmngr-client would be great, thanks!

The original reporter was on 2.1.0.

It looks like I can confirm this on 2.1.3.

This is still an issue with pinentry 0.9.1

I can confirm that this is resolved in 2.1.3 with .kbx files. Thanks for the fix!

I can confirm that this is resolved in 2.1.3:

0 dkg@alice:~$ gpgconf --launch dirmngr
gpgconf: error running '/usr/bin/gpg-connect-agent': exit status 1
gpgconf: error running '/usr/bin/gpg-connect-agent --dirmngr NOP': General error
1 dkg@alice:~$

the error message isn't particularly helpful at directing the user to the source
of the problem (a bad dirmngr.conf), but at least it does return a non-zero
error code.

I would like to see this happen. It would be great if dirmngr could make
parcimonie obsolete, for example.

(should this be "category: dirmngr" instead of just adding it as a topic?)

I'm seeing this behavior as well. For a test keyring with 13 keys, 49 User
IDs, and 7227 signatures, stored on a tmpfs on linux kernel 3.16, gpg2
--list-sigs with a pubring.kbx takes over 3 seconds (mostly kernelspace), but
with an old-style pubring.gpg takes 0.6 seconds (mostly userspace)

Maybe it makes more sense to mmap the keybox rather than trying to seek and read
inside it?

I'm also seeing this extreme delay from gpg --list-sigs 2.1.2 on a large
keyring, particularly when using kbx. It seems likely that there is a bug here.

This shows up elsewhere too:

http://forum.yubico.com/viewtopic.php?f=26&t=1171

says:

For some inexplicable reason, GnuPG cannot extract the public key from a
smartcard except during generation. That means that to use the key from
another computer, you either have to copy the public key from the original
computer's GnuPG keyring, or you need to set the URL attribute to a file
which contains the PGP public key block. Otherwise, the token is effectively
locked to a single computer, and unuseable if you happen to trash your
keyring unless you regenerate a key.

It would be nice to streamline this case.