CVE-2016-7444

What it actually does

The gnutls_ocsp_resp_check_crt function fails to verify the serial length of an OCSP response, permitting trailing bytes left by gnutls_malloc to bypass certificate validation.

Why it matters to the business

Attackers could intercept encrypted connections and impersonate trusted endpoints, exposing sensitive data in transit across any systems relying on the vulnerable library.

How an attack unfolds

An attacker intercepts a TLS handshake involving GnuTLS, supplies a crafted OCSP response containing extra trailing bytes after the serial number, and causes the library to accept an otherwise invalid certificate without raising an error.

How to fix it

Upgrade GnuTLS to a build containing commit 964632f37dfdfb914ebc5e49db4fa29af35b1de9, equivalent to versions 3.4.15 or 3.5.4 and later.

How to confirm the fix worked

Confirm installed GnuTLS version meets or exceeds 3.4.15 or 3.5.4; review lib/x509/ocsp.c for addition of explicit serial-length verification before the check_crt call.

Typical attack path

1. Position as a network intermediary capable of observing or altering TLS traffic
2. Craft an OCSP response with an incorrectly terminated serial number padded by extra bytes
3. Return the response during online certificate status checks performed by GnuTLS
4. Complete the TLS handshake with validation bypassed

How to detect it

Search application and system logs for TLS handshake events that completed despite OCSP responses containing unexpected lengths; inspect network captures for OCSP replies with anomalous serial fields near the time of suspected incidents.

What your security team should do

• Apply the fixed GnuTLS commit or newer releases to all affected hosts and containers
• Inventory applications that link against GnuTLS and prioritize updates for those performing OCSP checks
• Test certificate validation behavior after upgrade to ensure OCSP responses are now strictly validated