Latest CVE-2014-5270 patch breaks ElGamal keys of 16k

Bug #1371766 reported by Ciaby on 2014-09-19
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gnupg (Debian)
Fix Released
gnupg (Ubuntu)

Bug Description

I'm currenty using Ubuntu 12.04.5 LTS, 32-bit.

This is what i get with GnuPG version 1.4.11-3ubuntu2.6 using Enigmail (correct behavior):

2014-09-19 13:44:09.630 [CONSOLE] enigmail> /usr/bin/gpg --charset utf-8 --display-charset utf-8 --batch --no-tty --status-fd 2 -a -t --encrypt --encrypt-to 0x135C7291 -
r 0x0B7D1987135C7291 -u 0x135C7291
2014-09-19 13:44:40.545 [DEBUG] enigmailCommon.jsm: encryptMessageEnd: uiFlags=16, sendFlags=00000142, outputLen=5768
2014-09-19 13:44:40.545 [DEBUG] enigmailCommon.jsm: parseErrorOutput: status message:
gpg: 0x0B7D1987135C7291: skipped: public key already present

2014-09-19 13:44:40.548 [DEBUG] enigmailCommon.jsm: parseErrorOutput: statusFlags = 80000000
2014-09-19 13:44:40.549 [DEBUG] enigmailMsgComposeOverlay.js: Enigmail.msg.keySelection(): return toAddrStr="0x0B7D1987135C7291" bccAddrStr=""
2014-09-19 13:44:40.550 [DEBUG] enigmailMsgComposeOverlay.js: hasAttachments = false
2014-09-19 13:44:40.551 [DEBUG] enigmailMsgComposeOverlay.js: Enigmail.msg.editorGetContentAs
2014-09-19 13:44:40.551 [DEBUG] enigmailMsgComposeOverlay.js: Enigmail.msg.replaceEditorText:
2014-09-19 13:44:40.556 [DEBUG] enigmailMsgComposeOverlay.js: Enigmail.msg.editorInsertText
2014-09-19 13:44:40.569 [DEBUG] enigmailMsgComposeOverlay.js: Enigmail.msg.editorInsertText
2014-09-19 13:44:40.573 [DEBUG] enigmailMsgComposeOverlay.js: Enigmail.msg.editorGetContentAs
2014-09-19 13:44:40.574 [DEBUG] enigmailMsgComposeOverlay.js: Enigmail.msg.editorGetCharset
2014-09-19 13:44:40.574 [DEBUG] enigmailMsgComposeOverlay.js: Enigmail.msg.encryptMsg: charset=utf-8
2014-09-19 13:44:40.575 [DEBUG] enigmail.js: Enigmail.encryptMessage: 9 bytes from 0x135C7291 to 0x0B7D1987135C7291 (67)
2014-09-19 13:44:40.575 [DEBUG] enigmailCommon.jsm: encryptMessageStart: uiFlags=1, from 0x135C7291 to 0x0B7D1987135C7291, hashAlgorithm=null (00000043)
2014-09-19 13:44:40.575 [DEBUG] enigmailCommon.jsm: getEncryptCommand: hashAlgorithm=null
2014-09-19 13:44:40.577 enigmailCommon.jsm: execStart: command = /usr/bin/gpg --charset utf-8 --display-charset utf-8 --batch --no-tty --status-fd 2 -a -t --encrypt --sign --encrypt-to 0x135C7291 -r 0x0B7D1987135C7291 -u 0x135C7291, needPassphrase=1, domWindow=[object ChromeWindow], listener=[object Object]
2014-09-19 13:44:40.577 [DEBUG] enigmailCommon.jsm: getPassphrase:
2014-09-19 13:44:40.578 [CONSOLE] enigmail> /usr/bin/gpg --charset utf-8 --display-charset utf-8 --batch --no-tty --status-fd 2 -a -t --encrypt --sign --encrypt-to 0x135C7291 -r 0x0B7D1987135C7291 -u 0x135C7291 --use-agent
2014-09-19 13:45:15.448 [DEBUG] enigmailCommon.jsm: encryptMessageEnd: uiFlags=1, sendFlags=00000043, outputLen=5906
2014-09-19 13:45:15.448 [DEBUG] enigmailCommon.jsm: parseErrorOutput: status message:
[GNUPG:] USERID_HINT 0B7D1987135C7291 Ciaby <email address hidden>
[GNUPG:] NEED_PASSPHRASE 0B7D1987135C7291 0B7D1987135C7291 17 0
gpg: 0x0B7D1987135C7291: skipped: public key already present
[GNUPG:] SIG_CREATED S 17 10 01 1411152280 D0178161A8FA6E506BD07C000B7D1987135C7291

This is what i get with GnuPG version 1.4.11-3ubuntu2.7 using Enigmail (incorrect behavior):

2014-09-18 22:41:19.504 [CONSOLE] enigmail> /usr/bin/gpg --charset utf-8 --display-charset utf-8 --batch --no-tty --status-fd 2 -a -t --encrypt --sign --encrypt-to 0x135
C7291 -r 0x834AC0577A169C63 -u 0x135C7291 --use-agent
2014-09-18 22:41:37.732 [DEBUG] enigmailCommon.jsm: encryptMessageEnd: uiFlags=1, sendFlags=00000043, outputLen=0
2014-09-18 22:41:37.733 [DEBUG] enigmailCommon.jsm: parseErrorOutput: status message:
[GNUPG:] USERID_HINT 0B7D1987135C7291 Ciaby <email address hidden>
[GNUPG:] NEED_PASSPHRASE 0B7D1987135C7291 0B7D1987135C7291 17 0
gpg: out of secure memory while allocating 2048 bytes
gpg: (this may be caused by too many secret keys used simultaneously or due to excessive large key sizes)

Obviously, the latest security patch breaks ElGamal encryption with large keys (in this case, 16384 bytes).
Although GnuPG doesn't allow to generate these keys, the PGP standard (and GnuPG itself) supports large key sizes.
Please review the latest patch and make sure that all key sizes are supported.

Ciaby (ciaby) on 2014-09-19
information type: Private Security → Public
Marc Deslauriers (mdeslaur) wrote :

This is an upstream decision. In fact, they've now limited the size of ElGamal keys to 4096 with the following commit:;a=commit;h=aae7ec516b79e20938c56fd48fc0bc9d2116426c

Another relevant Debian bug:

Changed in gnupg (Ubuntu):
status: New → Confirmed
Ciaby (ciaby) wrote :

Well, the first commit just limits the key generation size. I'm fine with that, but breaking GnuPG for _currently_ used keys it's a totally different matter. I have been using this key for a while (let's say, a year and a half?) without any problems.
This, for me, is clearly a regression.
The second bug doesn't really explain anything about this specific case, as the Ubuntu package broke only with the latest security update. So, my question is:
is there a way to fix CVE-2014-5270 _and_ retain compatibility with currently used keys?

Seth Arnold (seth-arnold) wrote :

Ciaby, perhaps try raising your max locked memory resource limit. See setrlimit(2) and limits.conf(5) manpages for details.

Changed in gnupg (Debian):
status: Unknown → New
Ciaby (ciaby) wrote :

These are the current limits:

ciaby@lila:~$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 23805
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 95
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 23805
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited

Max locked memory is set to unlimited, so that's not the problem here.
I'm currently rebuilding the latest package with this line:

    got_secmem=secmem_init( 262144 );

Instead of this line:

    got_secmem=secmem_init( 32768 );

I'll let you know in a bit if it fixes the problem.

Ciaby (ciaby) wrote :

...and it works. So, the problem is:
with the latest patch, the usual amount of secure memory (32768 bytes) is not sufficient anymore. I just raised it to another arbitrary number (262144) and it works fine.
Wouldn't it be sufficient to just raise secmem_init() in g10/gpg.c ?

Ciaby (ciaby) wrote :

So, what's the deal with this?

Marc Deslauriers (mdeslaur) wrote :

Please report this issue to the gnupg project at the following link, and link the bug here:

Ciaby (ciaby) wrote :

Small update on the upstream issue I opened:
there is no way for GnuPG to support keys larger than 4k, although it's a one-line patch. Please read the explanation in the link above.
I see two possible outcomes of this:
1) Just add a tiny patch which increase the secure memory to 128k, keep the 16k keys working.
2) Don't do anything, piss off some people, make upstream happy.
What do you think?
By the way, the best way to do 1) would be to add the patch directly into Debian, so that Ubuntu receive it automatically instead of patching it in Ubuntu and leaving Debian uncovered.

Changed in gnupg (Debian):
status: New → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gnupg - 1.4.18-6ubuntu1

gnupg (1.4.18-6ubuntu1) vivid; urgency=medium

  * Resynchronise with Debian (LP: #1371766). Remaining changes:
    - Disable mlock() test since it fails with ulimit 0 (on buildds).
    - Set gpg (or gpg2) and gpgsm to use a passphrase agent by default.
    - Only suggest gnupg-curl and libldap; recommendations are pulled into
      minimal, and we don't need the keyserver utilities in a minimal Ubuntu
    - Remove the Win32 build.
    - Build using dh-autoreconf.
    - Disable inline assembler for ppc64el.
    - Enable SHA-512 support in gpgv-udeb.

gnupg (1.4.18-6) unstable; urgency=medium

  * revert to debhelper 7
  * simplify upstream doc synchronization.

gnupg (1.4.18-5) unstable; urgency=medium

  [ Daniel Kahn Gillmor ]
  * move to debhelper 9
  * add build and runtime support for larger RSA keys (Closes: #739424)
  * fix runtime errors on bad input (Closes: #771987)
  * deprecate insecure one-argument variant for gpg --verify of detached
    signatures (Closes: #771992)
  * sync documentation with upstream.
  * Standards-Version: bump to 3.9.6 (no changes needed).

  [ David Prévot ]
  * Update POT and PO files, and ensure the translations get rebuild
  * Update French translation (Closes: #769571)
  * Update Danish Translation, thanks to Joe Hansen
  * Update Ukrainian translation, thanks to Yuri Chornoivan
  * Update Russian translation, thanks to Ineiev
  * Update Chinese (traditional) translation, thanks to Jedi Lin
  * Update Italian translation, thanks to Milo Casagrande
  * Update Polish translation, thanks to Jakub Bogusz
  * Update Spanish translation, thanks to Manuel "Venturi" Porras Peralta
    (Closes: #770726)
  * Update Dutch translation, thanks to Frans Spiesschaert (Closes: #770816)
  * Update Czech translation, thanks to Roman Pavlik
 -- Colin Watson <email address hidden> Tue, 20 Jan 2015 17:20:15 +0000

Changed in gnupg (Ubuntu):
status: Confirmed → Fix Released
Marc Deslauriers (mdeslaur) wrote :

This should now be fixed in stable releases also in this update:

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.