CVE fixes of package readline and gnupg

The following changes since commit 505a6b696ae990442de720e5e1135a3e44d5f75c:

bitbake: fetcher: fix BB_STRICT_CHECKSUM datatype check (2014-10-06 16:09:53 +0100)

are available in the git repository at:

git://git.pokylinux.org/poky-contrib kangkai/CVEs
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=kangkai/CVEs

Kai Kang (3):
readline: Security Advisory - readline - CVE-2014-2524
gnupg: CVE-2013-4242
gnupg_1.4.7: add package config libusb

 .../readline/readline-6.3/readline63-003           | 43 +++++++++++++++
 meta/recipes-core/readline/readline_6.3.bb         |  2 +
 .../gnupg/gnupg-1.4.7/CVE-2013-4242.patch          | 62 ++++++++++++++++++++++
 meta/recipes-support/gnupg/gnupg_1.4.7.bb          |  2 +
 4 files changed, 109 insertions(+)
 create mode 100644 meta/recipes-core/readline/readline-6.3/readline63-003
 create mode 100644 meta/recipes-support/gnupg/gnupg-1.4.7/CVE-2013-4242.patch

1.9.1

The _rl_tropen function in util.c in GNU readline before 6.3 patch 3 allows local users to create or overwrite arbitrary files via a symlink attack on a /var/tmp/rltrace.[PID] file.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-2524

---
 .../readline/readline-6.3/readline63-003           | 43 ++++++++++++++++++++++
 meta/recipes-core/readline/readline_6.3.bb         |  2 +
 2 files changed, 45 insertions(+)
 create mode 100644 meta/recipes-core/readline/readline-6.3/readline63-003

new file mode 100644
index 0000000..98a9d81
@@ -0,0 +1,43 @@
+readline: Security Advisory - readline - CVE-2014-2524
+
+Upstream-Status: Backport
+
+Signed-off-by: Yue Tao <[email protected]>
+
+			   READLINE PATCH REPORT
+			   =====================
+
+Readline-Release: 6.3
+Patch-ID: readline63-003
+
+Bug-Reported-by:
+Bug-Reference-ID:
+Bug-Reference-URL:
+
+Bug-Description:
+
+There are debugging functions in the readline release that are theoretically
+exploitable as security problems.  They are not public functions, but have
+global linkage.
+
+Patch (apply with `patch -p0'):
+
+*** ../readline-6.3/util.c	2013-09-02 13:36:12.000000000 -0400
+--- util.c	2014-03-20 10:25:53.000000000 -0400
+***************
+*** 477,480 ****
+--- 479,483 ----
+  }
+  
++ #if defined (DEBUG)
+  #if defined (USE_VARARGS)
+  static FILE *_rl_tracefp;
+***************
+*** 539,542 ****
+--- 542,546 ----
+  }
+  #endif
++ #endif /* DEBUG */
+  
+  
+

index aa30f66..2ae73ea 100644
@@ -1,5 +1,7 @@
 require readline.inc
 
+SRC_URI_append = " file://readline63-003"
+
 SRC_URI[archive.md5sum] = "33c8fb279e981274f485fd91da77e94a"
 SRC_URI[archive.sha256sum] = "56ba6071b9462f980c5a72ab0023893b65ba6debb4eeb475d7a563dc65cafd43"
 

1.9.1

Answering my own question, whilst the CVE report says it affects 5.3, the vulnerable function isn't in 5.2.

Ross

OK. I'll send V2.

Thanks,
Kai

Regards,
Neil | Kai Kang

Just notice that you have done it. Thanks.

--Kai

Regards,
Neil | Kai Kang

Hi Kai,

I played around with the new meta-security-isafw layer and the cve-check-tool. In readline the cve CVE-2014-2524 is marked as 'missing' by the framework and I was confused to start with, since I saw that this commit was included. But after looking at the actual patch I realized that it only contains a report and not the patch itself. My question is if that is with purpose and due to some decision that the CVE isn't really causing any harm or if it's by mistake?

BR Petter

Petter Mabäcker

Technux
<[email protected]>
www.technux.se

2014-10-16 11:48 skrev Kai Kang:

The _rl_tropen function in util.c in GNU readline before 6.3 patch 3

allows local users to create or overwrite arbitrary files via a symlink

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-2524 [1]

<[email protected]>

.../readline/readline-6.3/readline63-003 | 43 ++++++++++++++++++++++

meta/recipes-core/readline/readline_6.3.bb | 2 +

insertions(+)

meta/recipes-core/readline/readline-6.3/readline63-003

a/meta/recipes-core/readline/readline-6.3/readline63-003 b/meta/recipes-core/readline/readline-6.3/readline63-003

100644

b/meta/recipes-core/readline/readline-6.3/readline63-003

@@

as security problems. They are not public functions, but have

linkage.

2014-03-20 10:25:53.000000000 -0400

defined (USE_VARARGS)

+*** 539,542 ****

DEBUG */

a/meta/recipes-core/readline/readline_6.3.bb
b/meta/recipes-core/readline/readline_6.3.bb

100644

b/meta/recipes-core/readline/readline_6.3.bb

readline.inc

SRC_URI[archive.sha256sum] = "56ba6071b9462f980c5a72ab0023893b65ba6debb4eeb475d7a563dc65cafd43"

Links:
------
[1]
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-2524

As can be seen at
http://lists.gnu.org/archive/html/bug-readline/2014-03/msg00057.html the CVE patch is simply adding a #if defined (DEBUG), which is in the patch included in oe-core master as readline-6.3/readline63-003.

The tool is probably reporting it as missing as -- if i recall correctly -- it identifies CVE patches by filename.

Ross

Petter Mabäcker

Technux
<[email protected]>
www.technux.se

2015-10-06 12:06 skrev Burton, Ross:

the cve-check-tool. In readline the cve CVE-2014-2524 is marked as 'missing' by the framework and I was confused to start with, since I saw that this commit was included. But after looking at the actual patch I realized that it only contains a report and not the patch itself. My question is if that is with purpose and due to some decision that the CVE isn't really causing any harm or if it's by mistake?

seen at
http://lists.gnu.org/archive/html/bug-readline/2014-03/msg00057.html [1] the CVE patch is simply adding a #if defined (DEBUG), which is in the patch included in oe-core master as readline-6.3/readline63-003.

The tool is probably reporting it as missing as -- if i recall correctly -- it identifies CVE patches by filename.

Hi Ross,

That is
correct that the isafw layer assumes that it's named *cve*.patch in order to understand that it's patched in a separate step. But what I really meant was that the file readline63-003 just contains information about the CVE and how to patch the source. It will never be applied on the source, it is just copied to the WORKDIR.

$ pwd

~BUILDDIR/tmp/work/core2-64-poky-linux/readline/6.3-r0 $ls

build
configure-fix.patch norpath.patch readline63-003 temp
config-dirent-symbols.patch configure.sstate readline-6.3 readline-dispatch-multikey.patch

$ grep DEBUG readline-6.3/util.c
$ echo
$?
1

The patch must be applied by something/someone.. For example
Debian solves it by doing their own .diff patch
(http://http.debian.net/debian/pool/main/r/readline6/readline6_6.3-8.debian.tar.xz).
I can send a suggestion about how to solve this in a proper way.

BR
Petter

Links:
------
[1]
http://lists.gnu.org/archive/html/bug-readline/2014-03/msg00057.html

Whoops, the file wasn't renamed to .patch and even after being renamed, it isn't actually a properly formatted patch. I'll fix this up now.

Thanks for noticing!

Ross

2015-10-06 14:58 skrev Burton, Ross:

applied by something/someone.. For example Debian solves it by doing their own .diff patch
(http://http.debian.net/debian/pool/main/r/readline6/readline6_6.3-8.debian.tar.xz
[1]). I can send a suggestion about how to solve this in a proper way.

renamed, it isn't actually a properly formatted patch. I'll fix this up now.

Great. As you will notice also when formatted properly it will not apply due to that readline63-001 and readline63-002 isn't applied so 'patchlevel' is incorrect. That makes me wondering what the patching strategy is? In my opinion we should consider adding the official readline-6.3 patches as well. Should I add a bug report for that or leave it as is (depending on the strategy...)?

BR Petter

for noticing!

Links:
------
[1]
http://http.debian.net/debian/pool/main/r/readline6/readline6_6.3-8.debian.tar.xz

Adding the rest of the patches would have been a sensible thing to do. Right now, we're frozen as we're about to release 2.0, but a bug or patches post-release would be much appreciated.

Ross

2015-10-06 16:08 skrev Burton, Ross:

notice also when formatted properly it will not apply due to that readline63-001 and readline63-002 isn't applied so 'patchlevel' is incorrect. That makes me wondering what the patching strategy is? In my opinion we should consider adding the official readline-6.3 patches as well. Should I add a bug report for that or leave it as is (depending on the strategy...)?

sensible thing to do. Right now, we're frozen as we're about to release 2.0, but a bug or patches post-release would be much appreciated.

Ross

I have created a defect and assigned myself
(https://bugzilla.yoctoproject.org/show_bug.cgi?id=8451) and will send something up when the normal integration is open again.

BR Petter

Sorry for late reply that we had The National Day vacation. I can help for this defect if you please.

Regards,
Neil | Kai Kang

2015-10-08 04:13 skrev Kang Kai:

apply due to that readline63-001 and readline63-002 isn't applied so 'patchlevel' is incorrect. That makes me wondering what the patching strategy is? In my opinion we should consider adding the official readline-6.3 patches as well. Should I add a bug report for that or leave it as is (depending on the strategy...)?

of the patches would have been a sensible thing to do. Right now, we're frozen as we're about to release 2.0, but a bug or patches post-release would be much appreciated.

and assigned myself
(https://bugzilla.yoctoproject.org/show_bug.cgi?id=8451 [1]) and will send something up when the normal integration is open again.

Petter

I can help for this defect if you please.

It's OK, I can send something
up for this. See the discussion with Marko within the same thread about a recommended way forward
(http://lists.openembedded.org/pipermail/openembedded-core/2015-October/111353.html).
If you have any requirements for the verification of the bug please update the bug report with this info.

BR Petter

Neil | Kai Kang

Petter Mabäcker

Technux
<[email protected]>
www.technux.se

Links:
------
[1]
https://bugzilla.yoctoproject.org/show_bug.cgi?id=8451

The strategy I introduced in 30a38ea1ee933fb134a5ee9000298703cab93692
was not to add the patches, but to fetch them as upstream source.
That was dropped when readline was updated to 6.3 (maybe there was no
patches for it at the time):
66bc6f4127e88db18e260c71d181aecfd58c7999

- ML

2015-10-08 06:31 skrev Marko Lindqvist:

Great. As you will notice also when formatted properly it will not apply due to that readline63-001 and readline63-002 isn't applied so 'patchlevel' is incorrect. That makes me wondering what the patching strategy is? In my opinion we should consider adding the official readline-6.3 patches as well. Should I add a bug report for that or leave it as is (depending on the strategy...)?

patches would have been a sensible thing to do. Right now, we're frozen as we're about to release 2.0, but a bug or patches post-release would be much appreciated. Ross

30a38ea1ee933fb134a5ee9000298703cab93692

but to fetch them as upstream source.

was updated to 6.3 (maybe there was no

66bc6f4127e88db18e260c71d181aecfd58c7999

Hello Marko,

When
looking at the dates for the 6.3 integration my guess is that no patches existed for 6.3 yet (compared to the dates for the patches..). I will give it a try to use your 5.2 strategy when applying the 6.3 patches to make it looks the same for both versions. Thanks for pointing this out!

BR Petter

Petter Mabäcker

Technux
<[email protected]>
www.technux.se

GnuPG before 1.4.14, and Libgcrypt before 1.5.3 as used in GnuPG 2.0.x and possibly other products, allows local users to obtain private RSA keys via a cache side-channel attack involving the L3 cache, aka Flush+Reload.

Patch from commit e2202ff2b704623efc6277fb5256e4e15bac5676 in
git://git.gnupg.org/libgcrypt.git

---
 .../gnupg/gnupg-1.4.7/CVE-2013-4242.patch          | 62 ++++++++++++++++++++++
 meta/recipes-support/gnupg/gnupg_1.4.7.bb          |  1 +
 2 files changed, 63 insertions(+)
 create mode 100644 meta/recipes-support/gnupg/gnupg-1.4.7/CVE-2013-4242.patch

new file mode 100644
index 0000000..c9addca
@@ -0,0 +1,62 @@
+From e2202ff2b704623efc6277fb5256e4e15bac5676 Mon Sep 17 00:00:00 2001
+From: Werner Koch <[email protected]>
+Date: Thu, 25 Jul 2013 11:17:52 +0200
+Subject: [PATCH] Mitigate a flush+reload cache attack on RSA secret
+ exponents.
+
+commit e2202ff2b704623efc6277fb5256e4e15bac5676 from
+git://git.gnupg.org/libgcrypt.git
+
+* mpi/mpi-pow.c (gcry_mpi_powm): Always perfrom the mpi_mul for
+exponents in secure memory.
+
+Upstream-Status: Backport
+
+Signed-off-by: Kai Kang <[email protected]>
+--
+
+The attack is published as http://eprint.iacr.org/2013/448 :
+
+Flush+Reload: a High Resolution, Low Noise, L3 Cache Side-Channel
+Attack by Yuval Yarom and Katrina Falkner. 18 July 2013.
+
+  Flush+Reload is a cache side-channel attack that monitors access to
+  data in shared pages. In this paper we demonstrate how to use the
+  attack to extract private encryption keys from GnuPG.  The high
+  resolution and low noise of the Flush+Reload attack enables a spy
+  program to recover over 98% of the bits of the private key in a
+  single decryption or signing round. Unlike previous attacks, the
+  attack targets the last level L3 cache. Consequently, the spy
+  program and the victim do not need to share the execution core of
+  the CPU. The attack is not limited to a traditional OS and can be
+  used in a virtualised environment, where it can attack programs
+  executing in a different VM.
+
+Index: gnupg-1.4.7/mpi/mpi-pow.c
+===================================================================
+--- gnupg-1.4.7.orig/mpi/mpi-pow.c
++++ gnupg-1.4.7/mpi/mpi-pow.c
+@@ -212,7 +212,13 @@ mpi_powm( MPI res, MPI base, MPI exponen
+ 		tp = rp; rp = xp; xp = tp;
+ 		rsize = xsize;
+ 
+-		if( (mpi_limb_signed_t)e < 0 ) {
++            /* To mitigate the Yarom/Falkner flush+reload cache
++             * side-channel attack on the RSA secret exponent, we do
++             * the multiplication regardless of the value of the
++             * high-bit of E.  But to avoid this performance penalty
++             * we do it only if the exponent has been stored in secure
++             * memory and we can thus assume it is a secret exponent.  */
++		if (esec || (mpi_limb_signed_t)e < 0) {
+ 		    /*mpihelp_mul( xp, rp, rsize, bp, bsize );*/
+ 		    if( bsize < KARATSUBA_THRESHOLD ) {
+ 			mpihelp_mul( xp, rp, rsize, bp, bsize );
+@@ -227,6 +233,8 @@ mpi_powm( MPI res, MPI base, MPI exponen
+ 			mpihelp_divrem(xp + msize, 0, xp, xsize, mp, msize);
+ 			xsize = msize;
+ 		    }
++		}
++		if ( (mpi_limb_signed_t)e < 0 ) {
+ 
+ 		    tp = rp; rp = xp; xp = tp;
+ 		    rsize = xsize;

index ddcc2c2..7be56fd 100644
@@ -17,6 +17,7 @@ SRC_URI = "ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-${PV}.tar.bz2 \
            file://curl_typeof_fix_backport.patch \
            file://CVE-2013-4351.patch \
            file://CVE-2013-4576.patch \
+           file://CVE-2013-4242.patch \
 	  "
 
 SRC_URI[md5sum] = "b06a141cca5cd1a55bbdd25ab833303c"

1.9.1

If build gnupg 1.4.7 after libusb-compat, it shows warning:

WARNING: QA Issue: gnupg rdepends on libusb-compat, but it isn't a build dependency? [build-deps]

Add package config libusb to fix it.

---
 meta/recipes-support/gnupg/gnupg_1.4.7.bb | 1 +
 1 file changed, 1 insertion(+)

index 7be56fd..aef515d 100644
@@ -99,3 +99,4 @@ FILES_${PN}-dbg += "${libexecdir}/${BPN}/.debug"
 
 PACKAGECONFIG ??= ""
 PACKAGECONFIG[curl] = "--with-libcurl=${STAGING_LIBDIR},--without-libcurl,curl"
+PACKAGECONFIG[libusb] = "--with-libusb=${STAGING_LIBDIR},--without-libusb,libusb-compat"

1.9.1