Closed Bug 1281043 (CVE-2016-5827) Opened 8 years ago Closed 2 years ago

Heap overread in libical icalparser_parse_string -> icaltime_from_string function

Categories

(Calendar :: Internal Components, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: bperry.volatile, Unassigned)

References

Details

(Keywords: reporter-external, sec-low)

Attachments

(2 files)

Attached file caltime.ics —
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 the icalparser_parse_string function, I found the attached testcase causes a heap overread in icaltime_from_string. This was tested against latest libical and 0.47 from Thunderbird.

Code calling icalparser_parse_string can be found here: https://dxr.mozilla.org/comm-central/search?q=icalparser_parse_string


Actual results:

=================================================================
==25313==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60300000ec03 at pc 0x000000602b21 bp 0x7ffd746ec2b0 sp 0x7ffd746ec2a8
READ of size 1 at 0x60300000ec03 thread T0
    #0 0x602b20 in icaltime_from_string (/root/tmp/new_parse/parse_string047_asan+0x602b20)
    #1 0x510498 in icalvalue_new_from_string_with_error (/root/tmp/new_parse/parse_string047_asan+0x510498)
    #2 0x512f76 in icalvalue_new_from_string (/root/tmp/new_parse/parse_string047_asan+0x512f76)
    #3 0x4f4773 in icalparser_add_line (/root/tmp/new_parse/parse_string047_asan+0x4f4773)
    #4 0x4efabe in icalparser_parse (/root/tmp/new_parse/parse_string047_asan+0x4efabe)
    #5 0x4f9c1f in icalparser_parse_string (/root/tmp/new_parse/parse_string047_asan+0x4f9c1f)
    #6 0x4eb7ef in main (/root/tmp/new_parse/parse_string047_asan+0x4eb7ef)
    #7 0x7f3162c68a3f in __libc_start_main /build/glibc-ryFjv0/glibc-2.21/csu/libc-start.c:289
    #8 0x444ae8 in _start (/root/tmp/new_parse/parse_string047_asan+0x444ae8)

0x60300000ec03 is located 2 bytes to the right of 17-byte region [0x60300000ebf0,0x60300000ec01)
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 0x4f7325 in parser_get_next_value (/root/tmp/new_parse/parse_string047_asan+0x4f7325)
    #4 0x4f42ca in icalparser_add_line (/root/tmp/new_parse/parse_string047_asan+0x4f42ca)
    #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 0x7f3162c68a3f in __libc_start_main /build/glibc-ryFjv0/glibc-2.21/csu/libc-start.c:289

SUMMARY: AddressSanitizer: heap-buffer-overflow ??:0 icaltime_from_string
Shadow bytes around the buggy address:
  0x0c067fff9d30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff9d40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff9d50: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff9d60: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff9d70: fa fa fa fa fa fa fa fa fa fa fa fa fa fa 00 00
=>0x0c067fff9d80:[01]fa fa fa 00 00 00 00 fa fa fd fd fd fd fa fa
  0x0c067fff9d90: fd fd fd fd fa fa 00 00 00 00 fa fa fd fd fd fd
  0x0c067fff9da0: fa fa fd fd fd fd fa fa 00 00 00 00 fa fa 00 00
  0x0c067fff9db0: 00 00 fa fa 00 00 00 00 fa fa 00 00 00 00 fa fa
  0x0c067fff9dc0: fd fd fd fd fa fa fd fd fd fd fa fa 00 00 00 00
  0x0c067fff9dd0: fa fa 00 00 00 00 fa fa 00 00 00 00 fa fa fd fd
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
==25313==ABORTING



Expected results:

Not overread the allocated buffer
Component: Untriaged → Internal Components
Product: Thunderbird → Calendar
I also believe this should be considered for the bug bounty.
Flags: sec-bounty?
Attached file icaltime.zip —
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.
Keywords: sec-low
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.
Flags: sec-bounty? → sec-bounty-
Debian seems to have assigned CVE-2016-5827 to this bug
https://lists.debian.org/debian-lts/2016/08/msg00192.html
Alias: CVE-2016-5827
Group: mail-core-security
While importing the caltime.ics (attached) file from the "Events and Tasks" menu option in Thunderbird 45 running on Fedora 24 under Valgrind, I see,

==31424== Invalid read of size 1
==31424==    at 0x3000E5D4: ??? (in /home/user/.thunderbird/pgbr034a.default/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}/components/libcalbasecomps.so)
==31424==    by 0x30011325: ??? (in /home/user/.thunderbird/pgbr034a.default/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}/components/libcalbasecomps.so)
==31424==    by 0x3000A159: ??? (in /home/user/.thunderbird/pgbr034a.default/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}/components/libcalbasecomps.so)
==31424==    by 0x3000A263: ??? (in /home/user/.thunderbird/pgbr034a.default/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}/components/libcalbasecomps.so)
==31424==    by 0x3000A361: ??? (in /home/user/.thunderbird/pgbr034a.default/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}/components/libcalbasecomps.so)
==31424==    by 0x30014EEC: ??? (in /home/user/.thunderbird/pgbr034a.default/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}/components/libcalbasecomps.so)
==31424==    by 0x834FDB0: NS_InvokeByIndex (in /usr/lib64/thunderbird/libxul.so)

Extension "{e2fda1a4-762b-4020-b5ad-a41df1933103}" is Lightning. So upstream Thunderbird seems to be affected by this CVE.
Flags: sec-bounty-hof-
See Also: → CVE-2016-5825

I'm pretty sure this was fixed in the libical 3.0 branch a long time ago.
if someone feels like trying a modern version, please use libical 3.0.8.

I am the libical maintainer and would like to know it it still happens.

libical has now been removed - bug 1787097.

Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: