FreshPorts - VuXML

This page displays vulnerability information about FreeBSD Ports.

The last vuln.xml file processed by FreshPorts is:

Revision:  371321
Date:      2014-10-21
Time:      13:58:33Z
Committer: madpilot

List all Vulnerabilities, by package

List all Vulnerabilities, by date

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

VuXML IDDescription
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/
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/
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