Bug in GnuTLS 3.0.11 signature_algorithms extension and others

[Nikos Mavrogiannopoulos]

On 02/24/2012 11:33 PM, Matthew Hall wrote:

> Hello GnuTLS team,
> 
> I believe I found a problem in the server-side implementation of the TLS 1.2 
> Signature Algorithms extension in GnuTLS 3.0.11. Here I provide some source 
> code, gdb output, and gnutls-serv full debug output to explain what I believe 
> is happening.
> 
> When the client enables the signature_algorithms extension and sends the 
> supported_signature_algorithms list, the session negotiation will always fail 
> because GnuTLS's internal representation of its own 
> supported_signature_algorithms list is always empty (this is stored in 
> session->internals.priorities.sign_algo.algorithms).
> 
> This causes the TLS 1.2 negotiation to fail when checking the 
> CertificateVerify's DigitallySigned SignatureAndHashAlgorithm field because 
> GNUTLS_E_UNSUPPORTED_SIGNATURE_ALGORITHM will always be returned from 
> _gnutls_session_sign_algo_enabled.
> 
> My code and Wireshark notice that your CertificateRequest has a blank 
> supported_signature_algorithms field, which I'm assuming is also copied from 
> the session->internals.priorities.sign_algo.
> 
> The same client code successfully connects to Java 7 JDK / JRE JSSE TLS 1.2 
> implementation without any issue, and Java successfully supports the 
> extension. GnuTLS also works again, when I disable the extension. I think this 
> narrows down the problem area.
> 
> I think the code should either copy out the client algorithms which it also 
> supports and which are allowed according to the Cipher String into the 
> session->internals.priorities.sign_algo.algorithms.
> 
> Or it could fill this sign_algo structure with some static data about every 
> combination which it allows (this is what Java 7 does, when the user 
> initializes the Cipher Suites / Export Rules / SSL Context).
> 
> This will allow the handshake to proceed because something besides 
> GNUTLS_E_UNSUPPORTED_SIGNATURE_ALGORITHM will be returned.
> 
> I also have a second problem I cannot email publicly because I think it could 
> be used to create an exploit against the library. Do you have a PGP key I 
> could use to send this other bug, and where should I send it?
[...]


> (gdb) print session->internals.priorities
> $17 = {cipher = {priority = {4, 7, 93, 5, 8, 94, 3, 2, 1, 
>       0 <repeats 23 times>}, algorithms = 9}, mac = {priority = {3, 6, 7, 200, 
>       2, 0 <repeats 27 times>}, algorithms = 5}, kx = {priority = {13, 12, 3, 
>       2, 1, 0 <repeats 27 times>}, algorithms = 5}, compression = {priority = {
>       1, 0 <repeats 31 times>}, algorithms = 1}, protocol = {priority = {4, 3, 
>       2, 1, 5, 0 <repeats 27 times>}, algorithms = 5}, cert_type = {
>     priority = {0 <repeats 32 times>}, algorithms = 0}, sign_algo = {
>     priority = {0 <repeats 32 times>}, algorithms = 0}, supported_ecc = {
>     priority = {5, 1, 2, 3, 4, 0 <repeats 27 times>}, algorithms = 5}, 
>   no_extensions = 0, no_padding = 0, allow_large_records = 0, sr = SR_PARTIAL, 
>   ssl3_record_version = 0, server_precedence = 0, additional_verify_flags = 0}
> (gdb) 
> 
> GNUTLS-SERV DEBUG LOG:
> 
> /usr/local/bin/gnutls-serv --priority NONE:+CIPHER-ALL:+NULL:+KX-ALL:+MAC-ALL:+COMP-NULL:+VERS-TLS-ALL:+CURVE-ALL:%LATEST_RECORD_VERSION --dhparams /home/mhall/certs/dhparams.pem --port 31337 --x509certfile /home/mhall/certs/server-cert.pem --x509keyfile /home/mhall/certs/server-key.pem --nodb --noticket --debug 2147483647 --echo


Hello Matthew,
 I believe the issue you describe is because of the priority string you
set. If you include +SIGN-ALL to the priority string you shouldn't have
this issue. The predefined priority string names such as PERFORMANCE,
NORMAL should also include a list of signature algorithms. If the
documentation isn't clear on that, or if you still notice the issue
under those priority strings please let me know.

You can find our pgp keys at the bottom of
http://www.gnu.org/software/gnutls/download.html

regards,
NIkos