Re: [Srtp-users] global buffer overflow on libsrtp when using Address Sanitizer

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Which version of libsrtp are you using?  It looks like you might be
using older code.

On 01/30/2014 10:10 AM, Sergio Garcia Murillo wrote:
> I have created a dummy test program (just calling srtp_init()) and it 
> seems it is know (but unresolved) issue:
>
> root@mixer-1:/usr/local/src/test# gdb ./test
> GNU gdb (GDB) 7.4.1-debian
> Copyright (C) 2012 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from /usr/local/src/test/test...done.
> (gdb) break __asan_report_error
> Function "__asan_report_error" not defined.
> Make breakpoint pending on future shared library load? (y or [n]) y
> Breakpoint 1 (__asan_report_error) pending.
> (gdb) r
> Starting program: /usr/local/src/test/test
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>
> Breakpoint 1, __asan_report_error () at 
> ../../../../gcc-4.8.2/libsanitizer/asan/asan_report.cc:628
> 628     ../../../../gcc-4.8.2/libsanitizer/asan/asan_report.cc: No such 
> file or directory.
> (gdb) bt
> #0  __asan_report_error () at 
> ../../../../gcc-4.8.2/libsanitizer/asan/asan_report.cc:628
> #1  0x00007ffff4e607f4 in __asan_report_load1 () from /usr/lib/libasan.so.0
> #2  0x00000000004182b3 in v128_copy_octet_string () at 
> crypto/math/datatypes.c:247
> #3  0x000000000040e263 in aes_icm_context_init () at 
> crypto/cipher/aes_icm.c:170
> #4  0x000000000040ab0c in cipher_type_self_test () at 
> crypto/cipher/cipher.c:120
> #5  0x000000000041a28f in crypto_kernel_load_cipher_type () at 
> crypto/kernel/crypto_kernel.c:310
> #6  0x000000000041afc2 in crypto_kernel_init () at 
> crypto/kernel/crypto_kernel.c:154
> #7  0x0000000000406429 in srtp_init () at srtp/srtp.c:1082
> #8  0x00000000004012a4 in main ()
> (gdb) up
> #1  0x00007ffff4e607f4 in __asan_report_load1 () from /usr/lib/libasan.so.0
> (gdb) up
> #2  0x00000000004182b3 in v128_copy_octet_string () at 
> crypto/math/datatypes.c:247
> 247               x->v8[14] = s[14];
> (gdb) list
> 242               x->v8[9]  = s[9];
> 243               x->v8[10] = s[10];
> 244               x->v8[11] = s[11];
> 245               x->v8[12] = s[12];
> 246               x->v8[13] = s[13];
> 247               x->v8[14] = s[14];
> 248               x->v8[15] = s[15];
> 249       }
> 250     #ifdef ALIGNMENT_32BIT_REQUIRED
> 251       else
> (gdb) up
> #3  0x000000000040e263 in aes_icm_context_init () at 
> crypto/cipher/aes_icm.c:170
> 170       v128_copy_octet_string(&c->counter, key + 16);
> (gdb) list
> 165
> 166       /* set counter and initial values to 'offset' value */
> 167       /* FIX!!! this assumes the salt is at key + 16, and thus that 
> the */
> 168       /* FIX!!! cipher key length is 16!  Also note this copies past the
> 169                 end of the 'key' array by 2 bytes! */
> 170       v128_copy_octet_string(&c->counter, key + 16);
> 171       v128_copy_octet_string(&c->offset, key + 16);
> 172
> 173       /* force last two octets of the offset to zero (for srtp 
> compatibility) */
> 174       c->offset.v8[14] = c->offset.v8[15] = 0;
>
>
> Any chance to get this fixed to be able to check the whole library with 
> the addess sanitizer?
>
> Best regards
> Sergio
> El 30/01/2014 15:58, Sergio Garcia Murillo escribió:
>> Hi all,
>>
>> I was trying to debug a server crash with via gcc 4.8.2 address 
>> sanitizer and it pointed down to the libsrtp. I tried to debug it 
>> deeper by  instrumentalizing the libsrtp, so I donwloaded latest srtp 
>> lib and compiled by changing:
>>
>> CFLAGS  = -Wall -O4 -fexpensive-optimizations -funroll-loops 
>> -fsanitize=address -fno-omit-frame-pointer -g
>> LIBS    =
>> LDFLAGS =  -L. -fsanitize=address
>>
>> I tried to run again the server but the address sanitizer detects a 
>> global overflow in srtp_init. So I tried to run the libsrtp tests and 
>> still got the same error:
>>
>> Build done. Please run 'make runtest' to run self tests.
>> running libsrtp test applications...
>> crypto/test/cipher_driver -v >/dev/null
>> =================================================================
>> ==23348== ERROR: AddressSanitizer: global-buffer-overflow on address 
>> 0x00000062553e at pc 0x414343 bp 0x7fff8e302d40 sp 0x7fff8e302d38
>> READ of size 1 at 0x00000062553e thread T0
>>     #0 0x414342 
>> (/usr/local/src/medooze/srtp/crypto/test/cipher_driver+0x414342)
>>     #1 0x407762 
>> (/usr/local/src/medooze/srtp/crypto/test/cipher_driver+0x407762)
>>     #2 0x403d6b 
>> (/usr/local/src/medooze/srtp/crypto/test/cipher_driver+0x403d6b)
>>     #3 0x401d07 
>> (/usr/local/src/medooze/srtp/crypto/test/cipher_driver+0x401d07)
>>     #4 0x401731 
>> (/usr/local/src/medooze/srtp/crypto/test/cipher_driver+0x401731)
>>     #5 0x2b3b3001feac (/lib/x86_64-linux-gnu/libc-2.13.so+0x1eeac)
>>     #6 0x401ac4 
>> (/usr/local/src/medooze/srtp/crypto/test/cipher_driver+0x401ac4)
>> 0x00000062553e is located 34 bytes to the left of global variable 
>> 'aes_icm_description (crypto/cipher/aes_icm.c)' (0x625560) of size 25
>>   'aes_icm_description (crypto/cipher/aes_icm.c)' is ascii string 'aes 
>> integer counter mode'
>> 0x00000062553e is located 0 bytes to the right of global variable 
>> 'aes_icm_test_case_0_key (crypto/cipher/aes_icm.c)' (0x625520) of size 30
>> Shadow bytes around the buggy address:
>>   0x0000800bca50: 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9 00 04 f9 f9
>>   0x0000800bca60: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 00
>>   0x0000800bca70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>   0x0000800bca80: 00 00 00 00 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9
>>   0x0000800bca90: 00 00 00 00 00 00 00 00 f9 f9 f9 f9 00 00 00 00
>> =>0x0000800bcaa0: f9 f9 f9 f9 00 00 00[06]f9 f9 f9 f9 00 00 00 01
>>   0x0000800bcab0: f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9 00 00 00 00
>>   0x0000800bcac0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>   0x0000800bcad0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>   0x0000800bcae0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>   0x0000800bcaf0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> Shadow byte legend (one shadow byte represents 8 application bytes):
>>   Addressable:           00
>>   Partially addressable: 01 02 03 04 05 06 07
>>   Heap left redzone:     fa
>>   Heap righ redzone:     fb
>>   Freed Heap region:     fd
>>   Stack left redzone:    f1
>>   Stack mid redzone:     f2
>>   Stack right redzone:   f3
>>   Stack partial redzone: f4
>>   Stack after return:    f5
>>   Stack use after scope: f8
>>   Global redzone:        f9
>>   Global init order:     f6
>>   Poisoned by user:      f7
>>   ASan internal:         fe
>> ==23348== ABORTING
>> make: *** [runtest] Error 1
>>
>> I have tried to parse the code with the asan_symbolize.py but I was 
>> not lucky, so not sure where exactly the problem is.
>>
>> Best regards
>> Sergio
>>
>
> ------------------------------------------------------------------------------
> WatchGuard Dimension instantly turns raw network data into actionable 
> security intelligence. It gives you real-time visual feedback on key
> security issues and trends.  Skip the complicated setup - simply import
> a virtual appliance and go from zero to informed in seconds.
> http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
> _______________________________________________
> Srtp-users mailing list
> Srt...@li...
> https://lists.sourceforge.net/lists/listinfo/srtp-users
> .
>