Navigation Bar Top Applications Support Documentation Vendors Search Index Top Top

gnupg -- remotely controllable function pointer

Description:

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.

References:

Affects:

portaudit: gnupg -- remotely controllable function pointer

Disclaimer: The data contained on this page is derived from the VuXML document, please refer to the the original document for copyright information. The author of portaudit makes no claim of authorship or ownership of any of the information contained herein.

If you have found a vulnerability in a FreeBSD port not listed in the database, please contact the FreeBSD Security Officer. Refer to "FreeBSD Security Information" for more information.


Oliver Eikemeier <eik@FreeBSD.org>