CVE-2014-3466 Memory corruption
This vulnerability affects the client side of the gnutls library. A server that a specially crafted ServerHello could corrupt the memory of a requesting client.
Recommendation: Upgrade to the latest gnutls version (3.1.25, 3.2.15 or 3.3.3)
Thank you for report K_F.
See also https://bugzilla.redhat.com/show_bug.cgi?id=1101734 re CVE-2014-3465
gnutls just released Version 3.3.4 (released 2014-05-31)
** libgnutls: Updated Andy Polyakov's assembly code. That prevents a
crash on certain CPUs.
So probably best to move directly to 3.3.4 skipping 3.3.3
2.x series is not affected by CVE-2014-3465 as the affected function was introduced in GnuTLS version 3.0: http://gnutls.org/manual/html_node/X509-certificate-API.html#gnutls_005fx509_005fdn_005foid_005fname-1
Still trying to confirm when CVE-2014-3466 was introduced.
At least 2.12.23 seems affected by CVE-2014-3466, upstream has fixed this with the two commits
https://www.gitorious.org/gnutls/gnutls/commit/688ea6428a432c39203d00acd1af0e7684e5ddfd and https://www.gitorious.org/gnutls/gnutls/commit/688ea6428a432c39203d00acd1af0e7684e5ddfd
and related https://www.gitorious.org/gnutls/gnutls/commit/1375d4e6d7bb969bf6c91ad78be41698073070f3
So a temporary work-around might be to backport those commits.
As the 2.x series use an embedded libtasn certain fixes needs to be applied to handle bug 511536 as well if backporting is used.
See also http://seclists.org/oss-sec/2014/q2/395
Arches, please stabilize
Targets: alpha amd64 arm hppa ia64 ppc ppc64 sparc x86
Since patches are backported to 2.x series this bug no longer depends on gnutls 3 stabilization
Stable for HPPA.
Added to existing glsa request.
Buffer overflow in the read_server_hello function in lib/gnutls_handshake.c
in GnuTLS before 3.1.25, 3.2.x before 3.2.15, and 3.3.x before 3.3.4 allows
remote servers to cause a denial of service (memory corruption) or possibly
execute arbitrary code via a long session id in a ServerHello message.
(In reply to Mikle Kolyada from comment #18)
> Added to existing glsa request.
> Cleanup, please!
This issue was resolved and addressed in
GLSA 201406-09 at http://security.gentoo.org/glsa/glsa-201406-09.xml
by GLSA coordinator Mikle Kolyada (Zlogene).