User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36 Steps to reproduce: Creating a small test harness passing a given input to icalparser_parse_string, I was able to find the attached input causes a heap overread in parser_get_next_char. This was tested against libical 0.47 from Thunderbird and libical latest. Unfortunately, I am unable to compile Thunderbird with ASan support in order to give a better idea of affected code paths. The affected code calling icalparser_parse_string can be found at: https://dxr.mozilla.org/comm-central/search?q=icalparser_parse_string Actual results: The ASan results are below ================================================================= ==2492==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60400000cacf at pc 0x0000004fa35b bp 0x7ffef5e63fd0 sp 0x7ffef5e63fc8 READ of size 1 at 0x60400000cacf thread T0 #0 0x4fa35a in parser_get_next_char (/root/tmp/new_parse/parse_string047_asan+0x4fa35a) #1 0x4f8541 in parser_get_param_name (/root/tmp/new_parse/parse_string047_asan+0x4f8541) #2 0x4f2d04 in icalparser_add_line (/root/tmp/new_parse/parse_string047_asan+0x4f2d04) #3 0x4efabe in icalparser_parse (/root/tmp/new_parse/parse_string047_asan+0x4efabe) #4 0x4f9c1f in icalparser_parse_string (/root/tmp/new_parse/parse_string047_asan+0x4f9c1f) #5 0x4eb7ef in main (/root/tmp/new_parse/parse_string047_asan+0x4eb7ef) #6 0x7ff0fac46a3f in __libc_start_main /build/glibc-ryFjv0/glibc-2.21/csu/libc-start.c:289 #7 0x444ae8 in _start (/root/tmp/new_parse/parse_string047_asan+0x444ae8) 0x60400000cacf is located 1 bytes to the left of 39-byte region [0x60400000cad0,0x60400000caf7) allocated by thread T0 here: #0 0x4cbab2 in malloc (/root/tmp/new_parse/parse_string047_asan+0x4cbab2) #1 0x5c443d in icalmemory_new_buffer (/root/tmp/new_parse/parse_string047_asan+0x5c443d) #2 0x4ed798 in make_segment (/root/tmp/new_parse/parse_string047_asan+0x4ed798) #3 0x4f8049 in parser_get_next_parameter (/root/tmp/new_parse/parse_string047_asan+0x4f8049) #4 0x4f2aac in icalparser_add_line (/root/tmp/new_parse/parse_string047_asan+0x4f2aac) #5 0x4efabe in icalparser_parse (/root/tmp/new_parse/parse_string047_asan+0x4efabe) #6 0x4f9c1f in icalparser_parse_string (/root/tmp/new_parse/parse_string047_asan+0x4f9c1f) #7 0x4eb7ef in main (/root/tmp/new_parse/parse_string047_asan+0x4eb7ef) #8 0x7ff0fac46a3f in __libc_start_main /build/glibc-ryFjv0/glibc-2.21/csu/libc-start.c:289 SUMMARY: AddressSanitizer: heap-buffer-overflow ??:0 parser_get_next_char Shadow bytes around the buggy address: 0x0c087fff9900: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c087fff9910: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c087fff9920: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c087fff9930: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c087fff9940: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =>0x0c087fff9950: fa fa fa fa fa fa fa fa fa[fa]00 00 00 00 07 fa 0x0c087fff9960: fa fa 00 00 00 00 00 fa fa fa 00 00 00 00 00 fa 0x0c087fff9970: fa fa 00 00 00 00 00 fa fa fa 00 00 00 00 00 05 0x0c087fff9980: fa fa 00 00 00 00 00 fa fa fa 00 00 00 00 00 00 0x0c087fff9990: fa fa 00 00 00 00 00 fa fa fa 00 00 00 00 00 fa 0x0c087fff99a0: fa fa 00 00 00 00 00 fa fa fa 00 00 00 00 00 fa 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 right 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 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==2492==ABORTING Expected results: Not read past the allocated space

I also believe this should be considered for the bug bounty.

Nominating for a bounty, but this doesn't have any symptoms in a release Thunderbird so it's hard to see where the exploit would be.

In the meantime, to provide more testcases for this bug that may take different paths through thunderbird in order to reach the vulnerable function (if indeed there is prior sanity checking that I haven't seen/found), perhaps these testcases will be useful for better reproing with an ASan-compiled version of thunderbird.

This is a "low" rated security issue so does not qualify for bounty and we have not seen verification that this directly affects Thunderbird. As a result, we are minusing this for bounty.

Debian seems to have assigned CVE-2016-5826 to this one https://lists.debian.org/debian-lts/2016/08/msg00192.html