[mod_gnutls-devel] Certificates not always exported to environment

[Benny Baumann]

Hi Daniel,

Am 21.02.2014 11:35, schrieb Daniel Kahn Gillmor:
> Hi Benny--
>
> On 02/18/2014 03:59 AM, Benny Baumann wrote:
>
>> while skimming through the code I noticed a minor bug (which I currently
>> could not yet trigger due to lack of a sufficiently large certificate
>> (and getting such one shouldn't be too hard) which causes mod_gnutls to
>> fail exporting the server and client certificate when the PEM encoding
>> of the certificate is more than 10 KiB.
> hm, i see the concern.  thanks for bringing this up.
I somehow have a hand to find such limits in software.
>> What happens: If you supply a certificate large enough to not fit into
>> the buffer (about 7KiB, which should possible to do with a well-crafted
>> 16kRSA key with non-standard exponent) or 40k RSA with standard exponent
>> OR a CA putting LOTS of extensions in you can cause mod_gnutls to skip
>> exporting this certificate to a client process like fcgi. If the client
>> process relies on the certificate to be present it will see that a
>> certificate was supplied (by the means of the ther variables in the
>> environment) but wont see the actual certificate and thus might fail
>> authentication or other functions relying on the presence of the
>> exported certificate.
> fwiw, the buffer is 10KiB, which is quite a lot:
>
>  char cert_buf[10 * 1024];
>
> 16Kib RSA keys are quite large and expensive to use.  There is a point
> of diminishing returns with RSA: as the keys get larger, the resistance
> to an attacker doesn't scale proportionally.  Note that a 16Kib RSA
> public key itself (regardless of the certificate around it) takes up
> 2KiB, which doesn't even fit in a normal TCP packet (the typical MTU is
> ~1.5KB).  And the key signature (for DHE key exchanges) or encrypted
> premaster secret (for RSA-style key exchanges) will be just as large as
> the key itself; so we're talking at least several packets just to
> transmit these parts of the handshake.  if the CA that issued the cert
> also uses a 16Kibit key, then the cert size doubles (because a cert
> contains both a pubkey and a signature), and then the intermediate CA's
> cert itself is a contributing large factor.  So the handshakes here
> could get very very large.
>
> as another point of reference: using GnuTLS's certtool, the
> configuration "--sec-param ULTRA" only generates 15Kib keys.
I'm currently using 8K RSA keys which equals a handshake footprint of
about 7.5 KiB without and 9.5KiB with OCSP stapling (server to client).
The client in both cases gives another 0.5 to 1KiB - although here the
number of packets is more interesting.
>> What should happen: Use a dynamic buffer which is allocated using the
>> size returned by the function exporting the certificate so that the
>> buffer is always large enough.
> I don't think we want to allow a client with an arbitrary-sized
> certificate to exhaust the RAM of the server.  There needs to be a limit
> somewhere based on reasonable criteria.  What do you think the limit
> should be?
What about allowing the admin to choose but defaulting to 64KiB on the
server if not set.

Furthermore you should be aware that by the time you ask to export the
certificate you already have it loaded by GnuTLS in memory. Therefore
resulting in a "memory usage amplification attack" with factor ~2.4
which requires the client to send you megabytes of data beforehand. I'm
not sure of the record structure of TLS regarding the Client and Server
Hello frames, but IIRC they might be limited in size - and thus probably
mitigating the attack forreally big certificates.
>> Implications: The current buffer is allocated on stack and thus might be
>> an attack vector if the GnuTLS routine used was prone to a buffer overrun.
> Overrunning a dynamic buffer on the heap is also potentially an issue
> (though i grant that stack smashing has a richer history); we need to
> rely on GnuTLS to not overrun a buffer if we tell it the size of the
> buffer, i think.
Granted. And if we really wouldn't trust the underlaying implementation
we still could create red-zones in the allocated buffer.
>
> All that said, I'm open to concrete suggestions that don't open the
> module to a RAM exhaustion attack; arbitrarily dropping a 10KiB buffer
> on the stack definitely seems a little weird.
>
> What do you think?
Suggestion: Ask for required size for export, check against (per-vhost)
setting for the maximum exportable size, allocate a buffer large enough
to hold the exported value and export a value indicating size
restriction violation otherwise. That way all the initially raised
concerns should be properly addressed.
>
> 	--dkg
>
BenBE.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20140221/8d8f3a62/attachment.sig>