Are you using an Ed25519 key? There was a regression in 2.1.8 which has
meanwhile be fixed in the repo. See also T2096.

c) Run gpg-agent under gdb
d) Run a modified gpg-agent (rm ~/S.gpg-agent; my-gpg-agent --daemon)
e) Hook into the tty and use pinentry-curses
f) scp ~/.gnupg/private-keys-v1.d/* mybox: and sniff the passphrase.

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.

I am closing this.

BTW: I can't share DarkStarSword's fear about prioritizing ease of debugging
over security - I would never do that for a real security problem; Neal and me
both explained why this proposed fix does can't help against an attack.

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.

Glad I was able to help get one bug fixed at least :)

The in-memory encryption will definitely help in this scenario (that is, a
casual attack by e.g. a colleague or another student having a laugh as their
friend left their screen unlocked... real attack - I should know, I've done it,
and had it done to me, as had several of my friends back in uni (to be fair -
that was on Firefox password manager, but it could just as easily have been
gpg-agent)... This is not about stopping a motivated attacker with physical
access to the system as they could always subvert the system in other ways e.g.
adding a shell alias to run a trojaned gpg-agent instead of the real thing,
install a key logger, etc).

I'm still not super happy that a casual attacker could walk away with a core
file containing the encrypted passphrase and the key to decrypt it. What started
as a casual attack for a laugh could later transform into a more serious attack
given that they can hold onto this information indefinitely. I'm not a motivated
attacker, but that would tempt the hell out of me if I was even slightly so
inclined. I should know, because I've been in a similar situation in the past
where I obtained an unshadowed passwd file (through a purely casual attack when
I was looking up a friend's uid and discovered the passwd file was not
shadowed... so of course I made a copy). I could have left it alone, but it
tempted the hell out of me and I ended up running john over it for two straight
weeks (never did much with the result, but that's not the point)!

I would hope that the developers of any security product learns to think like an
attacker.

I must say I am deeply troubled by the priority seeming to be on the ease of
debugging a security product which has the sole purpose of keeping a passphrase
safe. As the saying goes security is always a trade-off, but given that
gpg-agent is a security product and not a word processor, this particular trade
off does not sit right with me. I would expect the development team to have root
access on their own systems, which avoids the issue as the root user can always
attach a debugger with or without this change - is there truly a reason that
they need to attach to a running gpg-agent on a system they don't have root on?
And what about the thousands of gpg-agents running on other systems in the wild
that should never need to attach a debugger (and if they do... sudo)?

The information about FIPS mode and SELinux is good to know, at least for people
running distributions that support and enable them by default. But from what I
can gather FIPS mode is a RHEL only feature (I may be wrong - I'm not all that
familiar with it), and SELinux is still either not enabled, or in permissive
mode in many distributions by default (including Debian and Ubuntu).

As I mentioned in the original report, an alternative way to protect the memory
of gpg-agent is to install it with the setgid bit set (ssh-agent does both the
prctl() and setgid for example - now there's some developers I applaud). Unlike
SELinux and FIPS mode this works in every distribution and has been supported
for donkeys years.

This identified another bug: To be prepared for FIPS evaluation,
gpg-agent does not store the cached passphrases in the clear but
encrypts them in memory. Right this is security by obscurity but if
we ever have a way to store that key in a secured RAM (e.g. TPM, ARM
TrustZone) we can indeed limit the time a passphrase is available in
the clear to the period it is really needed. This all seems to work
but your tests shows that libassuan does not clear its internal line
buffers so that you can actually find the passphrase in the core
file. I just pushed a fix for this.

IIRC, FIPS mode in Linux inhibits all access to process memory system
wide. Changing this just a for a single user process does not make
much sense.

Further, being able to attach to a running processing is one of the
best debug methods we have. Giving up on this without for a perceived
extra protection is not going to work. There are too many ways to get
the passphrase using other ways. Linux can't protect a user to get
data belonging to him. Iff gpg-agent were a system daemon things
would be different and extra protection would make sense as a
fallback.

Without this I can do gcore pidof gpg-agent and QUITE CLEARLY see my
passphrase in the produced dump:

ian@draal~ [i]> gcore (pidof gpg-agent)
0x00007fb8f8849293 in __select_nocancel () at

../sysdeps/unix/syscall-template.S:81

81      ../sysdeps/unix/syscall-template.S: No such file or directory.
warning: target file /proc/1560/cmdline contained unexpected null characters
warning: Memory read failed for corefile section, 8192 bytes at 0x7ffce0a12000.
Saved corefile core.1560
0x00007f2dd583c293 in __select_nocancel () at

../sysdeps/unix/syscall-template.S:81

81      ../sysdeps/unix/syscall-template.S: No such file or directory.
warning: target file /proc/1540/cmdline contained unexpected null characters
warning: Memory read failed for corefile section, 8192 bytes at 0x7ffccfbe3000.
Saved corefile core.1540
ian@draal~ [i]> strings core.1560 | grep pass
passwd
This is my ultra secure passphrase - I definitely expect any program that

manages this to take reasonable steps to keep it safe even if I accidentally
leave my screen unlocked one day!

Invalid passphrase; please try again
You need a passphrase to unlock the secret key for user:%0A"test123

<test@test.com>"%0A2048-bit RSA key, ID DE3A7EAB, created 2015-08-06 (main key
ID F459B571)%0A

    SETERROR Invalid passphrase; please try again
    his is my ultra secure passphrase - IQ
    ian@draal~ [i]>

With this one line change I cannot do the above - that's the definition of
reducing the attack surface last time I checked.

You absolutely can still use gdb to debug it - you just have to start it under
gdb as opposed to attaching to an existing process, or attach the debugger as
root. You could also just disable the syscall in a debug build.

It does not reduce the attack surface. And yes, it complicates things
because you can't anymore debug the process without changing the code
or using other tricks (aka attack). I have not tested the SELinux
feature for quite some time but gnupg supports SELinux if configured
with --enable-selinux-support. If you want some protection better use
that.

dkg: We disable core dumps for the simple reason that we do not want
to see core files on disk. Disk sectors have a longer lifetime than a
process and a user session - thus avoiding core files is a real world
threat mitigation.

So a single syscall to demonstrably reduce the attack surface really complicates
things does it?

News to me.

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?

dkg: The problem is that the underlying architecture is broken. Unix's stock
permission model is about protecting users from other users, not protecting
processes from other processes. Thus, I don't think it makes any sense to
complicate the code by implementing these effectively useless protections.

FWIW, a widely used practical system that does a much better job at this is
Android. Android runs every program under its own uid. We could do the same
thing with gpg-agent. In fact, this is currently possible with a little help
from ssh. Unfortunately, this requires a fair amount of work by the user to set
up. In particular, the user needs to create a secondary account. It would be
nice if distributions provided a simply way for an unprivileged user to allocate
additional uids, but this is probably a lot of work.

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.

Done with commit 9bca96d. Here is how to use it:

  $ gpg-connect-agent 
  > passwd --verify 2C1103C5C84AAD061B5E3221C048A93D878F7EEE
  OK
  > passwd --verify 2C1103C5C84AAD061B5E3221C048A93D878F7EEE
  ERR 83886179 Operation cancelled <Pinentry>
  > passwd --verify 2C1103C5C84AAD061B5E3221C048A93D878F7EEE
  ERR 67108875 Bad passphrase <GPG Agent>

For the OK I entered the correct passpharse, for the bad passpharse I entered a
bad passphrase three times in a row.

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.

Why not doing a dummy signing then?

Just checked:

  /* Reset the pinentry (in case of popup messages). */
  agent_reset_query (ctrl);

Thus the pinentry is only closed if it is used as a simple popup winode (e.g.
"Insert card with serial number xxx") but not for a regular Pinentry.

Actually there should be no need for gpg to notigy gpg-agent and thus pinentry
about a Ctrl-C. Due to Ctrl-C the gpg process dies and thus the connection to
gpg-agent receives an EOF/SIGPIPE and gpg-agent will shuot it down. Thus the
connection cleanup handler of gpg-agent needs to kill an open pinentry - I
tought this is already done.

Or is it the case that gpg does not see the Ctrl-C?

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?

Hi dkg,

On the mailing list and in T1928, we discussed
why it shouldn't be possible for a program to pass the passphrase to gpg agent.
This feature request is at odds with the conclusion drawn there. Should this
issue be closed as WONTFIX?

Thanks,

:) Neal

It's fixed in 2.0.18 (as the T1203 was closed).

The patch is a work for problem somewhere in the PC/SC implementaion. I am also
not sure whether a pthread_cancel for a buggy PC/SC library is a good idea.
Terminating the process seems to be a better solution.

If gpgtools wants to apply this pacth, they might of course do so but I don't
want to apply it upstream in particular not to an older version (2.1 is current).

As I wrote to #712744, distribution nowadays is conservative enough for its
default kernel settings, and it doesn't require each application to have special
settings.

I think that we will be able to close this soon.

Thanks werner -- I've filed an upstream issue to bring awareness of the change
to the software I use that was affected (duply/duplicity), I'm sure this is
going to pop up for others as 2.1 becomes more widely adopted. Maybe add
something to the release notes or docs for '--passphrase-fd 0' so folks know a
config change is needed in their apps and gpg-agent? Regardless, I appreciate
your help.

(marking as resolved)

If you add it to gpg.conf the Pinentry won't be used and there are fir sure
cases where things won't work. In an unattended use I can't see a problem right
now.

We can't change the behaviour of --passpharse-fd; it is widely used and:

  if ( !opt.batch && opt.pinentry_mode != PINENTRY_MODE_LOOPBACK)
    { /* Not used but we have to do a dummy read, so that it won't end
         up at the begin of the message if the quite usual trick to
         prepend the passphtrase to the message is used. */

think would break or - worse - may insert the passphrase into the message.

The passphrase is still used for symmetric only encryption in batch mode.

Roger that, thanks - I've tested it on a VM with my keys and things seem "like
they used to be" for scripting an automated passphrase entry. I specified them
in my ~/.gnupg/pgp.conf and ~/.gnupg/gpg-agent.conf since editing many
individual softwares is not possible at this time, it needs to be backwards
compatible.

What side affects (breaking things?) does having these options permanently
enabled in configs are there? Having the allow in gpg-agent.conf is harmless,
but what about the client side gpg.conf?

If client gpg '--passphrase-fd 0' is useless without '--pinentry-mode loopback',
why not make this an automatic added option (internally) if '--passphrase-fd 0'
is specified? Of what use with gnupg-2.1.x is '--passphrase-fd 0' without
'--pinentry-mode loopback'?

I double-checked the official docs, there's no mention of needing these new
loopback settings in the section for --passphrase-fd 0:

https://www.gnupg.org/documentation/manuals/gnupg/GPG-Esoteric-Options.html#GPG-Esoteric-Options

"If you use 0 for n, the passphrase will be read from STDIN." (but as we know
here, it's not unless the new loopback options are added)

Like gpgsm has done from its very beginnong, gpg now also does not pknow
anything about the secret keys. This is all delagted to gpg-agent. This means
that telling gpg a passphrase is useless.

But wait. There is a workaround: gpg has the new option

   --pinentry-mode mode
          Set the pinentry mode to mode.  Allowed values for mode are:

          default
                 Use the default of the agent, which is ask.

          ask    Force the use of the Pinentry.

          cancel Emulate use of Pinentry's cancel button.

          error  Return a Pinentry error (``No Pinentry'').

          loopback

                 Redirect Pinentry queries to the caller.  Note that
                 in contrast to Pinentry the user is not prompted
                 again if he enters a bad pass- word.

Thus by using

  gpg --pinentry-mode=loopback

you can do basically the same as with 1.4. It is well tested and
slighly different than in 1.4. Uou also need to configure gpg-agent
with

  --allow-loopback-pinentry

       Allow clients to use the loopback pinentry features; see the
       option pinentry-mode for details.

A few Arch users are reporting the same regression/breakage, thread here:

https://bbs.archlinux.org/viewtopic.php?pid=1479136

Documented in master. Will be used by 2.0 as weel.

What is the threat model for this? If you are able to ptrace a process you can
do all other kind of stuff, like replacing gpg with your own code. If the box
has been taken over, we are in game-over state.

Disabling core dumps is a different issue because a core dump leaves traces of
the process on the disk.

I think that original reporter's intention is to prevent attaching by ptrace.
By PR_SET_DUMPABLE disabled, ptrace PTRACE_ATTACH won't work any more.
This would be better if we care about kernel compatibility.
In http://bugs.debian.org/714107, I found that setrlimit64 doesn't work reliably
for 2.6.34 or older. PR_SET_DUMPABLE seems to work for even 2.4.x.

I just backported the new ssh-agent code from master to the 2.0 branch. Thus
2.0.21 will have this support.

Hello Werner,

GnuPG uses setrlimit do disable core dumps. It has always done so. See
common/sysutils.c:disable_core_dumps. Do you have a test case which shows that
it does not work?

This is not a bug. The description of --max-cache-ttl reads:

  Set the maximum time a cache entry is valid to @var{n} seconds.  After
  this time a cache entry will be expired even if it has been accessed
  recently.  The default is 2 hours (7200 seconds).

Thus even if you set the cache-ttl-ssh > max-cache-ttl, it will expire after
max-cache-ttl seconds.

Would be great to have included if 2.1 is the ecc release.

I would love to just have 1 agent for everything.

There is no ECC support for the agent, yet. The ssh protocol is different from
the OpenPGP Protocol. It should be easy to add support, though.

Please re-open if you still see this problem.

Meanwhile even 2.0.18 is out. Closing it.

Fixed for 2.0 and 2.1. Thanks.

Wint 2.1 the protect-tools has been dropped. Thus we won't fix it in 2.0.

Note: T1190 is a bug report regarding this.