Sorry, we won't do that.

(Please do not try to continue a discussion here but take it to gcrypt-devel
instead - but I doubt that you will convince us).

AESNI is enabled in the gnupg 2.1 installer which we will use with gpg4win 3.0

Did you mean:
In this case we should also return 0 ?

ANy news?

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.

re 1) ssh-rsa-cert-v01@openssh.com is the certifiate as used by sshd/ssh. The
agent protocols however uses an ssh-rsa-cert-v00@openssh.com format to send the
private key to the agent. We should be easy to support this if it is sufficient
to just get the private key from the ssh-rsa-cert-v00.

re 2) I need to look close on how this is handled by the ssh-agent protocol.

gpg-agent should not look for an ssh file directly because its API is based on
the ssh-agent protocol. Thus a modified ssh is required. I noticed an
ssh-agent object related to card - this needs futher investigations.

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.

The issue is not resolved: if "gpg --recv-keys" is not sufficient, then some
other step must be added to the instructions, as currently they do not work, at
least not for this non-expert user.

There are two problems:

1. This sentence does not make sense: "You should see a message indicating that

the signature is good and made by of the signing keys." (Maybe the solution is
as simple as deleting "of"?)

2. The following instructions are too brief: "Make sure that you have the right

key, either by checking the fingerprint of that key with other sources or by
checking that the key has been signed by a trustworthy other key." Someone who
is trying to download GnuPG as part of bootstrapping a secure environment for
the first time (e.g. so they can download other software such as Tor in a
trustworthy way), will not know how to follow either of those suggestions.
Concrete instructions are needed.

If I simply download the GPG sources and corresponding signature, and run the
gpg --verify command that is given, I get the following output:

gpg: directory `/home/rrt/.gnupg' created
gpg: new configuration file `/home/rrt/.gnupg/gpg.conf' created
gpg: WARNING: options in `/home/rrt/.gnupg/gpg.conf' are not yet active during
this run
gpg: keyring `/home/rrt/.gnupg/pubring.gpg' created
gpg: Signature made Wed 01 Jul 2015 13:56:58 BST using RSA key ID 4F25E3B6
gpg: Can't check signature: public key not found
gpg: Signature made Thu 02 Jul 2015 05:31:06 BST using RSA key ID 33BD3F06
gpg: Can't check signature: public key not found

In other words, it doesn't seem to do anything useful.

This is on purpose. --recv-key is not sufficient.

Please send mail and follow the instructions on the page.

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.

With my tests it works with keyrings when specified using --keyring.

However, gpgv should also work with a keybox by default. This is now
implemented:

trustedkeys.kbx is now the default. If that does not exists gpgv also tries to
use trustedkeys.gpg (keybox or keyring) for backward compatibility. Right there
is a minor backward compatibility problem if a file "trustedkeys.kbx" alread
exists and you migrate to 2.1 - but I do not think that this is a real world
problem.

I am not sure how to to this in gpg and gpgme, thus for now only the gpg-agent part.

Okay, I added a --force option to gpg-agent.

gpg-connect-agent 'DELETE_KEY --force <KEYGRIP>' /bye

Does now do the same as

rm ~/.gnupg/private-keys-v1.d/<KEYGRIP>.key

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.

The problem is that the same secret key may be used for OpenPGP, S/MIME, Ssh,
and possible other cleints directly accessing gpg-agent.

Thus I am not sure how to best do it. The direct gpg-agent interface of gpgme
could be used to delete a key if we add a --force option to the agent's
DELETE_KEY command.

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.

This has since been handled in: T1691
It is fixed in Gpg4win.

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.

The Mail you show is a so called PGP/MIME mail.

We are well aware that GpgOL for Outlook 2010 and later versions only provides a
very basic OpenPGP support and no PGP/MIME Support. It is mentioned on the
website and in the documentation.

We are hoping to develop this but this is a huge Feature and very problematic to
implement given Outlook's extension API.

This was done with 26ab44b.

I'm now using pinentry-qt5 as my main pinentry but I doubt that there will be
any problems. After dropping the "Secure widgets" There were no code changes
necessary to support Qt5.

Solution is fine for me from a usability point of view.

For other users, it is not fine because they will first have to find this
solution, which probably will not happen before having fallen into the pit. So I
would prefer a changed default behavior.

I will try to convince the authors of the OpenPGP standard to remove some of the
complexity of the standard as well as the resulting issues.

So your solution is fine and produces the same result as a new option. Okay to
close?

What about adding an option to not embed the filename even if a file name was
given? It can be hard to convince other tools (e.g. enigmail) to use pipes for
just some of the operations ("cat %f | gnupg" for encryption, but not for
decryption). My workaround with --set-filename "" did not lead to problems yet,
so maybe this is good enough, from a usability point of view. Also, I just had a
look into RFC4880, and it seems that zero-length filenames are perfectly OK:
"This may be a zero-length string."

1.4 won't handle such a redirection because it does not use libassuan.

2.0 should follow such a redirection but the 2.0 agent is not able to setup a
socket in this way. If there is a real need it can be backported.

Thanks for the feedback. Closing.

Looks like the actual issue was that gpg-agent wasn't running.

Works fine now. Thanks for your help.

gpg agent already handles caching passwords in memory; Gnome keyring is just
used to cache the passwords on stable storage. Thus, I think the current
behavior is correct. If you disagree, please reopen and describe the behavior
that you expect.

Note: to have gpg agent cache passwords for a long time, set default-cache-ttl
and max-cache-ttl in your gpg-agent.conf to large values. To make sure the
cache is cleared when you log out, use 'gpgconf --reload gpg-agent' (or use send
SIGHUP to the right gpg-agent).

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?

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?

Thr redirect feature has not yet been documented. You can create a regular file
with the name of the socket file using this format

   %Assuan%
   socket=NAME

   where NAME is the actual socket to use.  No white spaces are
   allowed, both lines must be terminated by a single LF, extra lines
   are not allowed.  Environment variables are interpreted in NAME if
   given in "${VAR} notation; no escape characters are defined, if
   "${" shall be used verbatim, you need to use an environment
   variable with that content.

   The use of an absolute NAME is strongly suggested.  The length of
   the file is limited to 511 bytes which is more than sufficient for
   that common value of 107 for sun_path.

and to be clear, I'm not suggesting not using ~/.gnupg at all anymore. I'm only
saying that using that as a default location for gpg-agent socket is bad for some
use-cases (like nfs $HOME)

what is this "redirect feature" you mention? how would that help a user logging
into multiple computers using the same (nfs) $HOME ?

Using ~/.gnupg as gnupg's home directory predates XDG by many years and thus
would be an incompatible change. NFS is not a problem due to thre redirect feature.

Thanks for forwarding.

Followup details about XDG_RUNTIME_DIR if you're not familiar, see:
http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

"$XDG_RUNTIME_DIR defines the base directory relative to which user-specific non-
essential runtime files and other file objects (such as sockets, named pipes,
...) should be stored. The directory MUST be owned by the user, and he MUST be
the only one having read and write access to it. Its Unix access mode MUST be
0700.

The lifetime of the directory MUST be bound to the user being logged in. It MUST
be created when the user first logs in and if the user fully logs out the
directory MUST be removed. If the user logs in more than once he should get
pointed to the same directory, and it is mandatory that the directory continues
to exist from his first login to his last logout on the system, and not removed
in between. Files in the directory MUST not survive reboot or a full logout/login
cycle.

The directory MUST be on a local file system and not shared with any other
system. The directory MUST by fully-featured by the standards of the operating
system. More specifically, on Unix-like operating systems AF_UNIX sockets,
symbolic links, hard links, proper permissions, file locking, sparse files,
memory mapping, file change notifications, a reliable hard link count must be
supported, and no restrictions on the file name character set should be imposed.
Files in this directory MAY be subjected to periodic clean-up. To ensure that
your files are not removed, they should have their access time timestamp modified
at least once every 6 hours of monotonic time or the 'sticky' bit should be set
on the file.

If $XDG_RUNTIME_DIR is not set applications should fall back to a replacement
directory with similar capabilities and print a warning message. Applications
should use this directory for communication and synchronization purposes and
should not place larger files in it, since it might reside in runtime memory and
cannot necessarily be swapped out to disk."