From ${URL} : Two vulnerabilities have been reported in libmicrohttpd, where one has an unknown impact and the other one can be exploited by malicious people to cause a DoS (Denial of Service) or potentially compromise an application using the library. 1) A boundary error when unescaping strings can be exploited to trigger an out-of-bound read. 2) A boundary error when handling authentication headers can be exploited to cause a stack-based buffer overflow by providing an overly long authentication header. Successful exploitation of this vulnerability may allow execution of arbitrary code, but requires the application to explicitly raise memory limits and use MHD_digest_auth_check. The vulnerabilities are reported in versions prior to 0.9.32. Solution: Update to version 0.9.32. Provided and/or discovered by: The vendor credits Florian Weimer. @maintainer(s): since the fixed package is already in the tree, please let us know if it is ready for the stabilization or not.
*libmicrohttpd-0.9.32 (03 Dec 2013) 03 Dec 2013; Anthony G. Basile <blueness@gentoo.org> +libmicrohttpd-0.9.32.ebuild: Version bump
Arches, please test and mark stable: =net-libs/libmicrohttpd-0.9.32 Target Keywords : "amd64 arm ppc ppc64 x86"
amd64 stable
x86 stable
ppc stable
ppc64 stable
arm stable. Maintainer(s), please cleanup. Security, please add it to the existing request, or file a new one.
CVE-2013-7039 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-7039): Stack-based buffer overflow in the MHD_digest_auth_check function in libmicrohttpd before 0.9.32, when MHD_OPTION_CONNECTION_MEMORY_LIMIT is set to a large value, allows remote attackers to cause a denial of service (crash) or possibly execute arbitrary code via a long URI in an authentication header. CVE-2013-7038 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-7038): The MHD_http_unescape function in libmicrohttpd before 0.9.32 might allow remote attackers to obtain sensitive information or cause a denial of service (crash) via unspecified vectors that trigger an out-of-bounds read.
Thanks for your work. GLSA vote: yes
GLSA vote: yes. glsa request filed.
This issue was resolved and addressed in GLSA 201402-01 at http://security.gentoo.org/glsa/glsa-201402-01.xml by GLSA coordinator Mikle Kolyada (Zlogene).