> On Mar 29, 2017, at 9:35 AM, Nikos Mavrogiannopoulos 
> <[email protected]> wrote:
> 
> Could you please provide a reproducer? The easiest to create it would
> be following decoding-invalid-pkcs7 lines in tests/

Let me see what I can do. It is easy to reproduce with FreeTDS, though.

Compile FreeTDS (https://github.com/FreeTDS/freetds 
<https://github.com/FreeTDS/freetds>) and preeny 
(https://github.com/zardus/preeny <https://github.com/zardus/preeny>)

You then use the preeny desock.so to force the FreeTDS binary tsql to read data 
from stdin instead of network IO.

export LD_PRELOAD=~/preeny/x86_64-linux-gnu/desock.so

~/tsql  -S 127.0.0.1 -U fdsa -P fdsa < file_to_repro_crash

Perhaps you could compile FreeTDS with a debug copy of GnuTLS/libtasn1 to make 
it easier to track down? I can also work on a reproducible test case in the 
mean time, but I am not sure at all how long this could take.

Do you want the file that reproduces the crash to be sent here on the list or 
separately?

> 
> On Wed, Mar 29, 2017 at 3:39 PM, Brandon Perry
> <[email protected]> wrote:
>> Hi, while fuzzing another piece of software (FreeTDS), I came across a crash 
>> that was in libtasn1, not the software I was fuzzing. It looks like a double 
>> free.
>> 
>> 
>> Faulting Frame:
>>   None @ 0x00007ffff512e22a: in /usr/lib/x86_64-linux-gnu/libtasn1.so.6.5.1
>> Disassembly:
>> Stack Head (13 entries):
>>   __GI_raise                @ 0x00007ffff6530428: in 
>> /lib/x86_64-linux-gnu/libc-2.23.so (BL)
>>   __GI_abort                @ 0x00007ffff653202a: in 
>> /lib/x86_64-linux-gnu/libc-2.23.so (BL)
>>   __libc_message            @ 0x00007ffff65727ea: in 
>> /lib/x86_64-linux-gnu/libc-2.23.so (BL)
>>   malloc_printerr           @ 0x00007ffff657b477: in 
>> /lib/x86_64-linux-gnu/libc-2.23.so (BL)
>>   _int_free                 @ 0x00007ffff657b477: in 
>> /lib/x86_64-linux-gnu/libc-2.23.so (BL)
>>   __GI___libc_free          @ 0x00007ffff657e98c: in 
>> /lib/x86_64-linux-gnu/libc-2.23.so (BL)
>>   None                      @ 0x00007ffff512e22a: in 
>> /usr/lib/x86_64-linux-gnu/libtasn1.so.6.5.1
>>   asn1_delete_structure2    @ 0x00007ffff512f418: in 
>> /usr/lib/x86_64-linux-gnu/libtasn1.so.6.5.1
>>   None                      @ 0x00007ffff720e27c: in 
>> /usr/lib/x86_64-linux-gnu/libgnutls.so.30.6.2
>>   _dl_fini                  @ 0x00007ffff7de7c17: in 
>> /lib/x86_64-linux-gnu/ld-2.23.so
>>   __run_exit_handlers       @ 0x00007ffff6534ff8: in 
>> /lib/x86_64-linux-gnu/libc-2.23.so (BL)
>>   __GI_exit                 @ 0x00007ffff6535045: in 
>> /lib/x86_64-linux-gnu/libc-2.23.so (BL)
>>   main                      @ 0x00000000004070bd: in 
>> /root/freetds/build/src/apps/tsql
>> Registers:
>> rax=0x0000000000000000 rbx=0x0000000000000067 rcx=0x00007ffff6530428 
>> rdx=0x0000000000000006
>> rsi=0x0000000000003221 rdi=0x0000000000003221 rbp=0x00007fffffffdb30 
>> rsp=0x00007fffffffd798
>> r8=0x0000000000000004  r9=0x0000000000000000 r10=0x0000000000000008 
>> r11=0x0000000000000206
>> r12=0x0000000000000067 r13=0x00007fffffffd948 r14=0x00007fffffffd948 
>> r15=0x0000000000000002
>> rip=0x00007ffff6530428 efl=0x0000000000000206  cs=0x0000000000000033  
>> ss=0x000000000000002b
>> ds=0x0000000000000000  es=0x0000000000000000  fs=0x0000000000000000  
>> gs=0x0000000000000000
>> 
>> 
>> Since this is potentially security sensitive, how can I get the details to 
>> the proper person/people?

Attachment: signature.asc
Description: Message signed with OpenPGP

Reply via email to