* Noteworthy changes in release 3.5 (released 2014-05-01)
- Correctly handle decoding of recursive CHOICE options.
- Allow deleting elements of SET OF. Patch by Jean-Louis Thekekara.
- Several small bug fixes found by coverity.
- Code improvements contributed by Kurt Roeckx.
* Noteworthy changes in release 3.6 (released 2014-05-25) [stable]
- Corrected an off-by-one error in ASN.1 DER tag decoding.
- Several improvements and new safety checks on DER decoding;
issues found using Codenomicon TLS test suite.
- Marked asn1_der_decoding_element() as deprecated. Use
Related CVEs for this version:
CVE-2014-3467 libtasn1: multiple boundary check issues
CVE-2014-3468 libtasn1: asn1_get_bit_der() can return negative bit length
And also CVE-2014-3469 libtasn1: asn1_read_value_type() NULL pointer dereference
libtasn1-3.6 in tree.
Maintainers, please advise when eBuilds have had enough testing, and are ready for stabilization.
(In reply to Yury German from comment #4)
> Maintainers, please advise when eBuilds have had enough testing, and are
> ready for stabilization.
no problems reported so far, so I think we can progress.
Arches please stabilize:
Targets: alpha amd64 arm arm64 hppa ia64 ppc ppc64 sparc x86
Stable for HPPA.
Stable on alpha.
The (1) asn1_read_value_type and (2) asn1_read_value functions in GNU
Libtasn1 before 3.6 allows context-dependent attackers to cause a denial of
service (NULL pointer dereference and crash) via a NULL value in an ivalue
The asn1_get_bit_der function in GNU Libtasn1 before 3.6 does not properly
report an error when a negative bit length is identified, which allows
context-dependent attackers to cause out-of-bounds access via crafted ASN.1
Multiple unspecified vulnerabilities in the DER decoder in GNU Libtasn1
before 3.6, as used in GnutTLS, allow remote attackers to cause a denial of
service (out-of-bounds read) via a crafted ASN.1 data.
Maintainer(s), please cleanup.
Security, please add it to the existing request, or file a new one.
We already have a GLSA draft for this. Cleanup done by alonbl.
This issue was resolved and addressed in
GLSA 201408-09 at http://security.gentoo.org/glsa/glsa-201408-09.xml
by GLSA coordinator Kristian Fiskerstrand (K_F).