[PATCH 0/3] CVE fixes of package readline and gnupg

[PATCH 0/3] CVE fixes of package readline and gnupg

[Kai Kang]

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

[PATCH 1/3] readline: Security Advisory - readline - CVE-2014-2524

[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
attack on a /var/tmp/rltrace.[PID] file.

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

Signed-off-by: Yue Tao <Yue.Tao@windriver.com>
Signed-off-by: Kai Kang <kai.kang@windriver.com>
---
 .../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

diff --git a/meta/recipes-core/readline/readline-6.3/readline63-003 b/meta/recipes-core/readline/readline-6.3/readline63-003
new file mode 100644
index 0000000..98a9d81
--- /dev/null
+++ b/meta/recipes-core/readline/readline-6.3/readline63-003
@@ -0,0 +1,43 @@
+readline: Security Advisory - readline - CVE-2014-2524
+
+Upstream-Status: Backport
+
+Signed-off-by: Yue Tao <yue.tao@windriver.com>
+
+			   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 */
+  
+  
+
diff --git a/meta/recipes-core/readline/readline_6.3.bb b/meta/recipes-core/readline/readline_6.3.bb
index aa30f66..2ae73ea 100644
--- a/meta/recipes-core/readline/readline_6.3.bb
+++ b/meta/recipes-core/readline/readline_6.3.bb
@@ -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

Re: [PATCH 1/3] readline: Security Advisory - readline - CVE-2014-2524

[Burton, Ross]

On 16 October 2014 10:48, Kai Kang <kai.kang@windriver.com> wrote:
> +++ b/meta/recipes-core/readline/readline_6.3.bb
> @@ -1,5 +1,7 @@
>  require readline.inc
>
> +SRC_URI_append = " file://readline63-003"

Doing SRC_URI += is the usual thing to do.  Does this CVE also apply
to readline 5.2 that we ship as a non-GPLv3 alternative?

Ross

Re: [PATCH 1/3] readline: Security Advisory - readline - CVE-2014-2524

[Burton, Ross]

On 16 October 2014 12:20, Burton, Ross <ross.burton@intel.com> wrote:
> Does this CVE also apply
> to readline 5.2 that we ship as a non-GPLv3 alternative?

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

Ross

Re: [PATCH 1/3] readline: Security Advisory - readline - CVE-2014-2524

[Kang Kai]

On 2014年10月16日 19:20, Burton, Ross wrote:
> On 16 October 2014 10:48, Kai Kang <kai.kang@windriver.com> wrote:
>> +++ b/meta/recipes-core/readline/readline_6.3.bb
>> @@ -1,5 +1,7 @@
>>   require readline.inc
>>
>> +SRC_URI_append = " file://readline63-003"
> Doing SRC_URI += is the usual thing to do.

OK. I'll send V2.

Thanks,
Kai

> Does this CVE also apply
> to readline 5.2 that we ship as a non-GPLv3 alternative?
>
> Ross
>
>


-- 
Regards,
Neil | Kai Kang

Re: [PATCH 1/3] readline: Security Advisory - readline - CVE-2014-2524

[Kang Kai]

On 2014年10月20日 11:15, Kang Kai wrote:
> On 2014年10月16日 19:20, Burton, Ross wrote:
>> On 16 October 2014 10:48, Kai Kang <kai.kang@windriver.com> wrote:
>>> +++ b/meta/recipes-core/readline/readline_6.3.bb
>>> @@ -1,5 +1,7 @@
>>>   require readline.inc
>>>
>>> +SRC_URI_append = " file://readline63-003"
>> Doing SRC_URI += is the usual thing to do.
>
> OK. I'll send V2.

Just notice that you have done it. Thanks.

--Kai

>
> Thanks,
> Kai
>
>> Does this CVE also apply
>> to readline 5.2 that we ship as a non-GPLv3 alternative?
>>
>> Ross
>>
>>
>
>


-- 
Regards,
Neil | Kai Kang

Re: [PATCH 1/3] readline: Security Advisory - readline - CVE-2014-2524

[Petter Mabäcker]

[-- Attachment #1: Type: text/plain, Size: 3160 bytes --]

 

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
<petter@technux.se>
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
> attack on a /var/tmp/rltrace.[PID] file.
> 
>
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-2524 [1]
> 
>
Signed-off-by: Yue Tao <Yue.Tao@windriver.com>
> Signed-off-by: Kai Kang
<kai.kang@windriver.com>
> ---
>
.../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
> 
> diff --git
a/meta/recipes-core/readline/readline-6.3/readline63-003
b/meta/recipes-core/readline/readline-6.3/readline63-003
> new file mode
100644
> index 0000000..98a9d81
> --- /dev/null
> +++
b/meta/recipes-core/readline/readline-6.3/readline63-003
> @@ -0,0 +1,43
@@
> +readline: Security Advisory - readline - CVE-2014-2524
> +
>
+Upstream-Status: Backport
> +
> +Signed-off-by: Yue Tao
<yue.tao@windriver.com>
> +
> + 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 */
> + 
> + 
> +
> diff --git
a/meta/recipes-core/readline/readline_6.3.bb
b/meta/recipes-core/readline/readline_6.3.bb
> index aa30f66..2ae73ea
100644
> --- a/meta/recipes-core/readline/readline_6.3.bb
> +++
b/meta/recipes-core/readline/readline_6.3.bb
> @@ -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
 

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

[-- Attachment #2: Type: text/html, Size: 3574 bytes --]

Re: [PATCH 1/3] readline: Security Advisory - readline - CVE-2014-2524

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 921 bytes --]

On 6 October 2015 at 09:11, Petter Mabäcker <petter@technux.se> wrote:

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

[-- Attachment #2: Type: text/html, Size: 1480 bytes --]

Re: [PATCH 1/3] readline: Security Advisory - readline - CVE-2014-2524

[Petter Mabäcker]

[-- Attachment #1: Type: text/plain, Size: 2057 bytes --]

 

Petter Mabäcker

Technux
<petter@technux.se>
www.technux.se

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


> On 6 October 2015 at 09:11, Petter Mabäcker <petter@technux.se>
wrote:
> 
>> 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?
> 
> As can be
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. 
> 
> Ross

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

[-- Attachment #2: Type: text/html, Size: 3614 bytes --]

Re: [PATCH 1/3] readline: Security Advisory - readline - CVE-2014-2524

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 528 bytes --]

On 6 October 2015 at 12:23, Petter Mabäcker <petter@technux.se> wrote:

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

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

[-- Attachment #2: Type: text/html, Size: 1112 bytes --]

Re: [PATCH 1/3] readline: Security Advisory - readline - CVE-2014-2524

[Petter Mabäcker]

[-- Attachment #1: Type: text/plain, Size: 1105 bytes --]

 

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

> On 6 October 2015 at 12:23,
Petter Mabäcker <petter@technux.se> wrote:
> 
>> 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
[1]). I can send a suggestion about how to solve this in a proper
way.
> 
> 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.

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 

> Thanks
for noticing! 
> 
> Ross
 

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

[-- Attachment #2: Type: text/html, Size: 2222 bytes --]

Re: [PATCH 1/3] readline: Security Advisory - readline - CVE-2014-2524

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 682 bytes --]

On 6 October 2015 at 14:43, Petter Mabäcker <petter@technux.se> wrote:

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

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

[-- Attachment #2: Type: text/html, Size: 1072 bytes --]

Re: [PATCH 1/3] readline: Security Advisory - readline - CVE-2014-2524

[Petter Mabäcker]

[-- Attachment #1: Type: text/plain, Size: 923 bytes --]

 

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

> On 6 October 2015 at 14:43,
Petter Mabäcker <petter@technux.se> wrote:
> 
>> 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...)?
> 
> 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

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 

[-- Attachment #2: Type: text/html, Size: 1822 bytes --]

Re: [PATCH 1/3] readline: Security Advisory - readline - CVE-2014-2524

[Kang Kai]

[-- Attachment #1: Type: text/plain, Size: 1207 bytes --]

On 2015年10月06日 23:30, Petter Mabäcker wrote:
>
> 2015-10-06 16:08 skrev Burton, Ross:
>
>>
>> On 6 October 2015 at 14:43, Petter Mabäcker <petter@technux.se 
>> <mailto:petter@technux.se>> wrote:
>>
>>     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...)?
>>
>>
>> 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
> 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


[-- Attachment #2: Type: text/html, Size: 2944 bytes --]

Re: [PATCH 1/3] readline: Security Advisory - readline - CVE-2014-2524

[Petter Mabäcker]

[-- Attachment #1: Type: text/plain, Size: 1701 bytes --]

 

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

> On 2015年10月06日 23:30, Petter
Mabäcker wrote: 
> 
>> 2015-10-06 16:08 skrev Burton, Ross: 
>> 
>>> On
6 October 2015 at 14:43, Petter Mabäcker <petter@technux.se> wrote:
>>>

>>>> 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...)?
>>> 
>>> 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
>> 
>> I have created a defect
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. 
>> 
>> BR
Petter
> 
> Sorry for late reply that we had The National Day vacation.
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 

> -- 
> Regards,
>
Neil | Kai Kang

Petter Mabäcker

Technux
<petter@technux.se>
www.technux.se
 

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

[-- Attachment #2: Type: text/html, Size: 3102 bytes --]

Re: [PATCH 1/3] readline: Security Advisory - readline - CVE-2014-2524

[Marko Lindqvist]

On 6 October 2015 at 17:08, Burton, Ross <ross.burton@intel.com> wrote:
>
> On 6 October 2015 at 14:43, Petter Mabäcker <petter@technux.se> wrote:
>>
>> 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...)?
>
>
> 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

 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

Re: [PATCH 1/3] readline: Security Advisory - readline - CVE-2014-2524

[Petter Mabäcker]

[-- Attachment #1: Type: text/plain, Size: 1524 bytes --]

 

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

> On 6 October 2015 at
17:08, Burton, Ross <ross.burton@intel.com> wrote:
> 
>> On 6 October
2015 at 14:43, Petter Mabäcker <petter@technux.se> wrote: 
>> 
>>>
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...)?
>> 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
> 
> 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

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
<petter@technux.se>
www.technux.se

 

[-- Attachment #2: Type: text/html, Size: 2269 bytes --]

[PATCH 2/3] gnupg: CVE-2013-4242

[Kai Kang]

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

Signed-off-by: Yong Zhang <yong.zhang@windriver.com>
Signed-off-by: Kai Kang <kai.kang@windriver.com>
---
 .../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

diff --git a/meta/recipes-support/gnupg/gnupg-1.4.7/CVE-2013-4242.patch b/meta/recipes-support/gnupg/gnupg-1.4.7/CVE-2013-4242.patch
new file mode 100644
index 0000000..c9addca
--- /dev/null
+++ b/meta/recipes-support/gnupg/gnupg-1.4.7/CVE-2013-4242.patch
@@ -0,0 +1,62 @@
+From e2202ff2b704623efc6277fb5256e4e15bac5676 Mon Sep 17 00:00:00 2001
+From: Werner Koch <wk@gnupg.org>
+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 <kai.kang@windriver.com>
+--
+
+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;
diff --git a/meta/recipes-support/gnupg/gnupg_1.4.7.bb b/meta/recipes-support/gnupg/gnupg_1.4.7.bb
index ddcc2c2..7be56fd 100644
--- a/meta/recipes-support/gnupg/gnupg_1.4.7.bb
+++ b/meta/recipes-support/gnupg/gnupg_1.4.7.bb
@@ -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

[PATCH 3/3] gnupg_1.4.7: add package config libusb

[Kai Kang]

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.

Signed-off-by: Kai Kang <kai.kang@windriver.com>
---
 meta/recipes-support/gnupg/gnupg_1.4.7.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-support/gnupg/gnupg_1.4.7.bb b/meta/recipes-support/gnupg/gnupg_1.4.7.bb
index 7be56fd..aef515d 100644
--- a/meta/recipes-support/gnupg/gnupg_1.4.7.bb
+++ b/meta/recipes-support/gnupg/gnupg_1.4.7.bb
@@ -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