D318: 659_0002-build-use-pkg.m4-for-pkg-config-usage.patch

The security issue with emacs pinentry is that emacs is handling the passphrase
and it isn't very careful with it. For instance, try typing C-h l
(view-lossage) in emacs. This will show you your recent keystrokes. Emacs is
also a huge program (operating system?), which doesn't provide any isolation to
speak of. So, having it handle the passphrase adds a huge chunk of code to the
user's trusted computing base. Because of this concern, emacs doesn't enable
this by default (the user has to add pinentry-start to his or her .emacs files).

Emacs support in pinentry of course adds some complexity to pinentry and a
minuscule amount of additional complexity to gpg agent (it needs to pass through
a few more environment variables).

You propose an attack in which an attacker has access to the gpg-agent socket
and some other socket. pinentry is wired to use /tmp/emacs<UID>/pinentry. So I
guess this is the other socket that you mean. Note: before using it, pinentry
makes sure that the socket is owned by UID.

As far as I can see there are two weaknesses. First, the attacker can try to
brute force the password. This is a minor problem, I think, but worth
addressing given the recent efforts to prevent this type of attack. Based on
how unlikely and difficult this attack is, I think the best thing to do is for
gpg-agent to rate limit pinentry. Second, the attacker could exploit a weakness
in the gpg-agent/pinentry API. My sense here is that there are probably easier
attack vectors. As Werner likes to say: there are many local exploits. Once
the attacker has your UID, he or she can just ptrace your gpg-agent or copy your
private key (assuming it is saved on disk).

I propose the following:

• Add a command line option to pinentry that disables emacs support
• Change gpg-agent to support passing command line options to pinentry
• Rate limit password attempts by pinentry.
• Document pinentry-emacs and related functionality in the pinentry manual.

Is this reasonable?

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.

pinentry-emacs does not need to be distributed. You just need to distribute the
usual pinentry programs with emacs support. Similar to the fallback-curses
mode, if these programs see that INSIDE_EMACS is set AND they can talk to an
emacs instance with the pinentry module loaded, then they speak the emacs
protocol. Otherwise, they do their usual thing.

I'll update the documentation in the near future.

What abuse of INSIDE_EMACS are you referring to?

Thanks

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).

chdiza: In the future, please open one issue per bug report. FWIW, I've also
fixed this new bug.

Given that this bug has existed since forever on Max OS X, I don't think this
issue is important enough to immediately do a release. However, there should be
a new release within the month.

Also, the OSX community would much appreciate it if you guys would cut a release
containing this fix as soon as possible. We aren't any less likely to misenter our own
passwords than anyone else :)

Neal: It works!

However you should be aware that I had to manually --disable-pinentry-emacs, or else
I got this:

-----8<-----------------------------
Making all in emacs
gcc -DHAVE_CONFIG_H -I. -I.. -I/usr/local/Cellar/gnoopeegee/1.8.0/include -
I/usr/local/Cellar/gnoopeegee/1.8.0/include -I../pinentry -Wall -g -O2 -Wall -
Wcast-align -Wshadow -Wstrict-prototypes -Wformat -Wno-format-y2k -Wformat-security
-W -Wno-sign-compare -Wno-missing-field-initializers -Wdeclaration-after-statement -
Wno-pointer-sign -Wpointer-arith -MT pinentry-emacs.o -MD -MP -MF .deps/pinentry-
emacs.Tpo -c -o pinentry-emacs.o pinentry-emacs.c
mv -f .deps/pinentry-emacs.Tpo .deps/pinentry-emacs.Po
make[2]: * No rule to make target ../assuan/libassuan.a', needed by pinentry-
emacs'. Stop.
make[1]: * [all-recursive] Error 1
make: *** [all] Error 2
------------8<----------------------------

I myself don't use emacs, but probably there are some OSX users who'd want pinentry-
emacs.

Looks to me like it just fails silently.

chdiza: Thanks for your help! I'm sorry about the confusion. I overlooked your
previous message. I've change pinentry-curses to recognize 0xf7 (127) as
backspace (6ce1d0c curses: Recognize ASCII DEL as backspace.) If this change
didn't fix the issue, please reopen.

Thanks for this report: you are absolutely right, we need to check if the actual
secret service is usable and not only if the library is available.

How exactly does pinentry fail? Does it just silently fail to save the
password? Does it still return the entered password to gpg-agent?

Thanks.

Can you still try building with the supplied patch and sending me the scancodes

for delete.

Sorry, I don't understand. I did build with the supplied patch, as I reported below,
and I included the output of /tmp/pinentry-curses-output.txt as instructed.

If get back as far as 0.9.1 and the bug is still present, then it wasn't
introduced by recent changes. That's good to know.

Can you still try building with the supplied patch and sending me the scancodes
for delete.

Thanks.

I attempted to bisect, but when I when back to version 0.8.1, I could not build. I get
stuff I don't understand and don't know how to fix, like:

config.status: error: cannot find input file: `gtk/Makefile.in'

And other stuff that seems related to older checkouts needing different versions of
autoconf/automake. I simply don't have the expertise to deal with that, or the time to
curate multiple versions of autotools. So I can't git bisect.

I did however find that the oldest release version of pinentry that I could build on my
system was 0.7.1, and it also had broken backspace/delete/whatever.

I also tried on OSX 10.5.8, same thing.

I suspect pinentry was always broken on OSX.

It sounds like you are missing some build dependencies. Perhaps something

related to iconv?

Well, I don't know. I'm not a programmer. I am not missing any deps when I build the
released versions of pinentry. I don't know what's different about the git repo
versions.

I made sure gettext was in my path and tried again, having applied your patch. It
compiled.

I then followed your original instructions. I typed:

onetwo<the-key-called-Delete-on-Mac>

and hit OK.

The contents of pinentry-curses-output.txt was:
6f
6e
65
74
77
6f
7f

Needless to say, "backspacing" still failed.

It sounds like you are missing some build dependencies. Perhaps something
related to iconv?

Looking at the keyboard, that appears to be the backspace key. (The last Mac I
used was an Apple 2E in school.) The backspace key works fine for me and I
don't have access to a Mac to debug the issue, so I'm going to need help. It
would be great if you could get pinentry to compile and used git bisect to find
the change that caused the problem (I'm assuming that the bug didn't exist at
some point).

Thanks.

The delete key never did anything, because the cursor is always at the end of

the line. (Delete deletes the character in front of the cursor.) Perhaps you
mean the backspace key.

I mean the key which has the word "delete" on it, as seen in the gallery here:
https://www.apple.com/keyboard/. It is in the same spot, and is labeled "delete",
on all Mac keyboards, not just the model shown in that gallery. They key in
question is the one that Mac users press to simultaneously back up the cursor and
delete whatever char was in the arrive-at position.

Probably now someone will tell me that the key is improperly labeled by Apple :)

The delete key never did anything, because the cursor is always at the end of

the line. (Delete deletes the character in front of the cursor.) Perhaps you
mean the backspace key.

I had to clone the git repo first. Once there, I applied the patch and I ran
autogen.sh. I can't get the resulting configure script to work. Both "./configure"
and "./configure --enable-maintainer-mode" result in the following:

---8<-----------------------------------
checking for ncursesw... no
checking for ncurses... no
checking for initscr in -lncursesw... no
checking for initscr in -lncurses... yes
checking for ncurses include dir... none
./configure: line 8466: syntax error near unexpected token `iconv'
./configure: line 8466: ` AC_LIB_LINKFLAGS_BODY(iconv)'
---8<-----------------------------------

D313: 647_0001-Add-debuging-output.patch

The delete key never did anything, because the cursor is always at the end of
the line. (Delete deletes the character in front of the cursor.) Perhaps you
mean the backspace key.

Please apply the following patch. The run: build-dir/curses/pinentry-curses and
type getpin. You'll be prompted for a pin. Type in some text and then press
"delete". Then please reply to this issue with the exact text that you typed
and the file /tmp/pinentry-curses-output.txt

Thanks.

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?

Hi Brian,

I tried it in PuTTY without screen and it was not skewed. The line draw
characters looked funny (which I'm assuming is a Unicode thing), but they
were in a rectangle.

bjmgeek: ping

I've now applied the 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 :/

D305: 627_0001-secmem-When-clearing-memory-don-t-clear-beyond-the-e.patch

Well, that's embarrassing. It looks like it was my bug. The attached patch
seems to fix the problem.

I've been debugging this issue for about an hour and I tentatively came to the
same conclusion.

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.

OK, I'll try that too.

I will try this afternoon.

Also, see if you can reproduce the problem without screen. Thanks.

I tried your screen configuration and I couldn't reproduce the problem.

Perhaps putty is configuring something differently. Can you reproduce the
problem when putty is not used (e.g., directly on the console or ssh'ing from a
GNU/Linux box)?

On Tue, Jun 2, 2015, 11:19 PM Neal Walfield via BTS <gnupg@bugs.g10code.com>
wrote:

Here is my .screenrc

#change the hardstatus settings to give
an window list at the bottom of the
#screen, with the time and date and with
the current window highlighted
hardstatus alwayslastline
hardstatus string '%{= bK}%-Lw%{=
KW}%50>%n%f* %t%{= bK}%+Lw%< %{= kG}%-=%D
%d %M %Y %c:%s%{+b y} %H %l'

deflogin on
shell /usr/bin/bash
vbell on

Thanks for your quick reply. I meant: what program were you running on your
Debian box in screen? I doubt you directly called pinentry. Were you running
mutt? Were you running gpg?

Thanks.

I was using PuTTY 6.4 on Windows 7 64 bit.

dkg: Thanks for pointing that out. I need to fix my git config on this machine.

I just tried running pinentry-curses under screen on debian in an
xfce4-terminal. (You can run it directly from the command line by running
pinentry-curses and then typing 'getpin'.) I wasn't able to reproduce what I
saw in your screenshot. Also, I saw the proper symbolic characters to paint the
widget's borders (see screenshot).

I've make some changes to pinentry-curses recently. Perhaps you can try that
version (git). If you get the same results, does hitting control-L correctly
repaint the screen?

What program were you running? Perhaps it messed with the terminal settings.

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>"

After chatting with Werner, we decided to apply the patch. If Andre has any
objections, he is still welcome to voice them.

I don't know much about Qt / KDE so I have a difficult time evaluating this
patch. However, given that this problem has persisted for a long time (since
2010); that Fedora has been distributing this patch; and that Felix still sees
this problem without the patch, but doesn't see it with the patch, I'm inclined
to apply it.

I've added Andre to the nosy list. He has much more experience with Qt and KDE
than I do. If he also thinks it is reasonable to apply the patch, then I'll
apply it.

P.S. Feel free to add me to any bug that you think I could help on.

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)

We implemented support for the GTK_IM_MODULE ebvar before 2007 thus I think this
is more likely a regression. In fact I recall that Marcus once showed me a
problem with his SCIM installation while using Pinentry.

Oh well, resizing the buttons to a new fixed size would be a job in the source
of 10 minutes or so. However, this makes an very ugly Pinentry for every day's
use (i.e. entering a passphrase for an existing key). So, sorry, I won't take
that patch.

With native Windows code I mean native Windows code for GUIs instead of relying
on MFC or whatever is the latest GUI framework MS uses. This is similar to xlib
programm vs. GTK+ programming

Anyway, thanks for looking into this. I will retitle the bug to keep it open.
Maybe eventually someone starts to hack on it.

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

I also added support for control-h (backspace) and control-l.

Thanks!
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=pinentry.git;a=blobdiff;f=pinentry/pinentry-curses.c;h=183fdb4f3ddef8535a8890178a610ac56a8880ae;hp=e7220094fce3375ddfefbe7353a36c998d406ef5;hb=d3c52a144b5b23d0d841a99a310090dcafe2074b;hpb=1d3583a2562e83496ac515276e9bd63a7f1abbc7

I don't have a definite authoritative list of escape codes, but those seem to be
the most common ones with use cases in pinentry.

It uses GTK features not availabale on my version. With some replacement macros
you should be abale to aplly it anyway.

D271: 610_0001-Using-a-simple-GtkEntry-instead-of-our-custom-implem.patch

If I disable the secure entry widget (see patch) and start pinentry as follows:

  GTK_IM_MODULE=scim gtk+-2/pinentry-gtk-2

then I'm able to enter text in the same way as with gedit.

This means that the problem is not due to grabing the keyboard, but most likely
due to our secure entry widget. Note: the secure entry widget is based on a
2004 copy of GtkEntry so it's not surprising that it doesn't support some modern
features.

I tested your pkg-config patch on Debian Jessie and everything still compiles
fine. I've applied the pkg-config patch. If gentoo is now using a newer
version of this patch, please let me know. Thanks.

I'm having trouble reproducing this issue. When I su, root doesn't suddenly own
the terminal:

  $ su -
  Password: 
  # ls -l $(tty)
  crw------- 1 neal tty 136, 4 May 16 22:52 /dev/pts/4
  #

Can you provide a minimal example that illustrates the problem? Thanks. I
realize this issue is very old.

Fixed in edd9a88.