[gnutls-devel] [sr #108321] crq_apis coredump on 32-bit build due to _gnutls_strdatum_to_buf NULL buf handling

[anonymous]

URL:
  <http://savannah.gnu.org/support/?108321>

                 Summary: crq_apis coredump on 32-bit build due to
_gnutls_strdatum_to_buf NULL buf handling
                 Project: GnuTLS
            Submitted by: None
            Submitted on: Mon 10 Jun 2013 12:47:15 UTC
                Category: Core library
                Priority: 5 - Normal
                Severity: 4 - Important
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: nick.alcock at oracle.com
             Open/Closed: Open
         Discussion Lock: Any
        Operating System: GNU/Linux

    _______________________________________________________

Details:

[Set to important on the grounds that writing to null pointers in
security-sensitive code is a bad thing. Feel free to change it back if I
guessed wrong!]

This is a 32-bit build on a 64-bit SSSE3-capable host. We see:

Core was generated by `./crq_apis'.
Program terminated with signal 11, Segmentation fault.
#0  0xf75f697a in __memcpy_ssse3_rep () from /lib32/libc.so.6
(gdb) bt
#0  0xf75f697a in __memcpy_ssse3_rep () from /lib32/libc.so.6
#1  0xf76fedf6 in _gnutls_strdatum_to_buf (d=d at entry=0xffd0d7c8,
buf=buf at entry=0x0, sizeof_buf=sizeof_buf at entry=0xffd0d81c) at common.c:1774
#2  0xf7705152 in gnutls_x509_crq_get_challenge_password
(crq=crq at entry=0x9aa99c0, buf=buf at entry=0x0,
sizeof_buf=sizeof_buf at entry=0xffd0d81c) at crq.c:490
#3  0xf7713e0f in print_crq (format=GNUTLS_CRT_PRINT_FULL, cert=0x9aa99c0,
str=0xffd0d820) at output.c:2344
#4  gnutls_x509_crq_print (crq=0x9aa99c0,
format=format at entry=GNUTLS_CRT_PRINT_FULL, out=out at entry=0xffd0d91c) at
output.c:2486
#5  0x080495b8 in doit () at crq_apis.c:190
#6  0x08048f84 in main (argc=<optimized out>, argv=0xffd0da34) at utils.c:155

The immediate cause, obviously, is that 'buf' is NULL. The ultimate cause is
also obvious: print_crq() calls gnutls_x509_crq_get_challenge_password() with
a NULL buf argument and an uninitialized size. How this works at all, ever,
even on 64-bit platforms, is a mystery to me. A NULL buf is not documented as
working, but since it is passed in by the API testsuite as well as by
print_crq() it is clear that it's meant to work.

The obvious fix is to test buf for nullity in _gnutls_strdatum_to_buf(), as
well as checking the size for validity, and return
GNUTLS_E_SHORT_MEMORY_BUFFER and update the sizeof_buf if it's NULL as well as
if it's short. This means you can set the size by passing in any size at all
and a NULL buf, rather than requiring a zero size.

Fix attached.



    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Mon 10 Jun 2013 12:47:16 UTC  Name:
0001-A-NULL-buf-argument-to-_gnutls_strdatum_to_buf-shoul.patch  Size: 1kB  
By: None
Fix
<http://savannah.gnu.org/support/download.php?file_id=28286>

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?108321>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/