helpGnuTLS - Support: sr #108321, crq_apis coredump on 32-bit build...

 
 

sr #108321: crq_apis coredump on 32-bit build due to _gnutls_strdatum_to_buf NULL buf handling

Submitted by:  None
Submitted on:  Mon 10 Jun 2013 12:47:15 PM UTC  
 
Category:  Core library Priority:  5 - Normal
Severity:  4 - Important Status:  Done
Privacy:  Public Assigned to:  Nikos Mavrogiannopoulos <nmav>
Originator Email:  -email is unavailable- Open/Closed:  Closed
Operating System:  GNU/Linux

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Mon 10 Jun 2013 01:01:52 PM UTC, comment #1:

Correction: it is obvious why it doesn't crash on x86-64: on that platform, it so happens that the stack frame is deep enough in the call within crq_apis that the size passed in is zero. This is obviously not something we can ever rely on! :)

(Sorry I can't log in: my username and password are stored encrypted and only my Emacs knows how to decrypt them. My Emacs won't start due to a lack of GnuTLS! though I have a build underway to fix that...)

Anonymous
Mon 10 Jun 2013 12:47:15 PM UTC, original submission:

[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@entry=0xffd0d7c8, buf=buf@entry=0x0, sizeof_buf=sizeof_buf@entry=0xffd0d81c) at common.c:1774
#2 0xf7705152 in gnutls_x509_crq_get_challenge_password (crq=crq@entry=0x9aa99c0, buf=buf@entry=0x0, sizeof_buf=sizeof_buf@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@entry=GNUTLS_CRT_PRINT_FULL, out=out@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.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by nmav (Updated the item)
  • -email is unavailable- added by None (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-07-23 nmav StatusNone => Done
        Assigned toNone => nmav
        Open/ClosedOpen => Closed
    2013-06-10 None Attached File- => Added 0001-A-NULL-buf-argument-to-_gnutls_strdatum_to_buf-shoul.patch, #28286

    Back to the top


    Powered by Savane 3.3