FreshPorts - VuXML

This page displays vulnerability information about FreeBSD Ports.

The last vuln.xml file processed by FreshPorts is:

Revision:  363221
Date:      2014-07-28
Time:      18:38:13Z
Committer: cs

List all Vulnerabilities, by package

List all Vulnerabilities, by date

These are the vulnerabilities relating to the commit you have selected:

VuXML IDDescription
30394651-13e1-11dd-bab7-0016179b2dd5gnupg -- memory corruption vulnerability

Secunia reports:

A vulnerability has been reported in GnuPG, which can potentially be exploited to compromise a vulnerable system.

The vulnerability is caused due to an error when importing keys with duplicated IDs. This can be exploited to cause a memory corruption when importing keys via --refresh-keys or --import.

Successful exploitation potentially allows execution of arbitrary code, but has not been proven yet.


Discovery 2008-03-19
Entry 2008-04-26
Modified 2008-04-29
gnupg
ge 1.0.0 lt 1.4.9

ge 2.0.0 lt 2.0.9

28487
CVE-2008-1530
http://www.ocert.org/advisories/ocert-2008-1.html
http://secunia.com/advisories/29568
https://bugs.g10code.com/gnupg/issue894
4db1669c-8589-11db-ac4f-02e081235dabgnupg -- remotely controllable function pointer

Werner Koch reports:

GnuPG uses data structures called filters to process OpenPGP messages. These filters are used in a similar way as a pipelines in the shell. For communication between these filters context structures are used. These are usually allocated on the stack and passed to the filter functions. At most places the OpenPGP data stream fed into these filters is closed before the context structure gets deallocated. While decrypting encrypted packets, this may not happen in all cases and the filter may use a void contest structure filled with garbage. An attacker may control this garbage. The filter context includes another context used by the low-level decryption to access the decryption algorithm. This is done using a function pointer. By carefully crafting an OpenPGP message, an attacker may control this function pointer and call an arbitrary function of the process. Obviously an exploit needs to prepared for a specific version, compiler, libc, etc to be successful - but it is definitely doable.

Fixing this is obvious: We need to allocate the context on the heap and use a reference count to keep it valid as long as either the controlling code or the filter code needs it.

We have checked all other usages of such a stack based filter contexts but fortunately found no other vulnerable places. This allows to release a relatively small patch. However, for reasons of code cleanness and easier audits we will soon start to change all these stack based filter contexts to heap based ones.


Discovery 2006-12-04
Entry 2006-12-07
Modified 2006-12-15
gnupg
lt 1.4.6

CVE-2006-6235
http://lists.gnupg.org/pipermail/gnupg-announce/2006q4/000246.html
http://secunia.com/advisories/23245/
749b5587-2da1-11e3-b1a9-b499baab0cbegnupg -- possible infinite recursion in the compressed packet parser

Werner Koch reports:

Special crafted input data may be used to cause a denial of service against GPG (GnuPG's OpenPGP part) and some other OpenPGP implementations. All systems using GPG to process incoming data are affected..


Discovery 2013-10-05
Entry 2013-10-05
gnupg
lt 1.4.15

ge 2.0.0 lt 2.0.22

CVE-2013-4402
30394651-13e1-11dd-bab7-0016179b2dd5gnupg -- memory corruption vulnerability

Secunia reports:

A vulnerability has been reported in GnuPG, which can potentially be exploited to compromise a vulnerable system.

The vulnerability is caused due to an error when importing keys with duplicated IDs. This can be exploited to cause a memory corruption when importing keys via --refresh-keys or --import.

Successful exploitation potentially allows execution of arbitrary code, but has not been proven yet.


Discovery 2008-03-19
Entry 2008-04-26
Modified 2008-04-29
gnupg
ge 1.0.0 lt 1.4.9

ge 2.0.0 lt 2.0.9

28487
CVE-2008-1530
http://www.ocert.org/advisories/ocert-2008-1.html
http://secunia.com/advisories/29568
https://bugs.g10code.com/gnupg/issue894
4db1669c-8589-11db-ac4f-02e081235dabgnupg -- remotely controllable function pointer

Werner Koch reports:

GnuPG uses data structures called filters to process OpenPGP messages. These filters are used in a similar way as a pipelines in the shell. For communication between these filters context structures are used. These are usually allocated on the stack and passed to the filter functions. At most places the OpenPGP data stream fed into these filters is closed before the context structure gets deallocated. While decrypting encrypted packets, this may not happen in all cases and the filter may use a void contest structure filled with garbage. An attacker may control this garbage. The filter context includes another context used by the low-level decryption to access the decryption algorithm. This is done using a function pointer. By carefully crafting an OpenPGP message, an attacker may control this function pointer and call an arbitrary function of the process. Obviously an exploit needs to prepared for a specific version, compiler, libc, etc to be successful - but it is definitely doable.

Fixing this is obvious: We need to allocate the context on the heap and use a reference count to keep it valid as long as either the controlling code or the filter code needs it.

We have checked all other usages of such a stack based filter contexts but fortunately found no other vulnerable places. This allows to release a relatively small patch. However, for reasons of code cleanness and easier audits we will soon start to change all these stack based filter contexts to heap based ones.


Discovery 2006-12-04
Entry 2006-12-07
Modified 2006-12-15
gnupg
lt 1.4.6

CVE-2006-6235
http://lists.gnupg.org/pipermail/gnupg-announce/2006q4/000246.html
http://secunia.com/advisories/23245/
80771b89-f57b-11e2-bf21-b499baab0cbegnupg -- side channel attack on RSA secret keys

A Yarom and Falkner paper reports:

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.


Discovery 2013-07-18
Entry 2013-07-25
Modified 2013-07-26
gnupg
lt 1.4.14

http://eprint.iacr.org/2013/448
http://lists.gnupg.org/pipermail/gnupg-announce/2013q3/000330.html