Bug 1275400 (CVE-2016-5824)

Handful use-after-free crashes in libical (used in Thunderbird)

RESOLVED FIXED in 6.6
(Needinfo from 2 people)

Status

RESOLVED FIXED
3 years ago
27 days ago

People

(Reporter: bperry.volatile, Assigned: MakeMyDay, NeedInfo)

Tracking

(Depends on: 1 bug)

unspecified
Bug Flags:
sec-bounty -

Details

Attachments

(3 attachments, 3 obsolete attachments)

(Reporter)

Description

3 years ago
Created attachment 8756033 [details]
Handful of use-after-free crashes in libical

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36

Steps to reproduce:

Hello,

After fuzzing libical for a bit (tested against 1.0, 1.0.1 from http://www.citadel.org/doku.php/documentation:featured_projects:libical and from libical git master), I have a small handful of use-after-free crashes, but are likely the same root cause. These might fall under the bug bounty, they might not. Thunderbird does use libical for parsing, however. Let me know if this is an improper place to submit this bug report.

http://mxr.mozilla.org/comm-central/search?string=icalcomponent_as_ical_string&find=%2F&findi=&filter=%5E%5B%5E%5C0%5D*%24&hitlimit=&tree=comm-central

With any of the above mentioned versions, you can go from the root of the project, and make a directory called 'build', then cd to this directory and run cmake to compile with ASan.

cmake -DCMAKE_CXX_FLAGS="-fsanitize=address -fno-omit-frame-pointer" -DCMAKE_EXE_LINKER_FLAGS="-fsanitize=address" -DCMAKE_CXX_COMPILER="clang++" ..

After compiling, while still in the build directory, the src/test/parser binary should be usable to reproduce my results. Simply pass the file to parse as an argument to the file.

I submitted a brief issue on github for the libical project (https://github.com/libical/libical/issues/235), looking for a secure way to get these files to the devs, but have gotten no response back.


Actual results:

Below is one of the stack traces from ASan. As you can see, the crash is the library for libical.

==2461==ERROR: AddressSanitizer: heap-use-after-free on address 0x60200000ee95 at pc 0x7f89bc50d649 bp 0x7fffb8f9f920 sp 0x7fffb8f9f098
READ of size 1 at 0x60200000ee95 thread T0
    #0 0x7f89bc50d648  (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x60648)
    #1 0x7f89bc50e5a5 in __interceptor_vsnprintf (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x615a5)
    #2 0x7f89bc50e811 in snprintf (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x61811)
    #3 0x7f89bc280b30 in icalreqstattype_as_string_r (/root/libical_asan/build/lib/libical.so.2+0x4fb30)
    #4 0x7f89bc28347b in icalvalue_as_ical_string_r (/root/libical_asan/build/lib/libical.so.2+0x5247b)
    #5 0x7f89bc27208c in icalproperty_as_ical_string_r (/root/libical_asan/build/lib/libical.so.2+0x4108c)
    #6 0x7f89bc268132 in icalcomponent_as_ical_string_r (/root/libical_asan/build/lib/libical.so.2+0x37132)
    #7 0x7f89bc267fd1 in icalcomponent_as_ical_string (/root/libical_asan/build/lib/libical.so.2+0x36fd1)
    #8 0x400cd4 in main (/root/libical_asan/build/src/test/parser+0x400cd4)
    #9 0x7f89bbe87a3f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x20a3f)
    #10 0x400ae8 in _start (/root/libical_asan/build/src/test/parser+0x400ae8)

0x60200000ee95 is located 5 bytes inside of 6-byte region [0x60200000ee90,0x60200000ee96)
freed by thread T0 here:
    #0 0x7f89bc5456aa in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x986aa)
    #1 0x7f89bc26d667 in icalmemory_free_buffer (/root/libical_asan/build/lib/libical.so.2+0x3c667)
    #2 0x7f89bc2710d7 in icalparser_add_line (/root/libical_asan/build/lib/libical.so.2+0x400d7)
    #3 0x400cbd in main (/root/libical_asan/build/src/test/parser+0x400cbd)
    #4 0x7f89bbe87a3f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x20a3f)

previously allocated by thread T0 here:
    #0 0x7f89bc5459aa in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x989aa)
    #1 0x7f89bc26d5d3 in icalmemory_new_buffer (/root/libical_asan/build/lib/libical.so.2+0x3c5d3)
    #2 0x7f89bc26f44c in make_segment (/root/libical_asan/build/lib/libical.so.2+0x3e44c)
    #3 0x7f89bc26f82d in icalparser_get_value (/root/libical_asan/build/lib/libical.so.2+0x3e82d)
    #4 0x7f89bc270eb6 in icalparser_add_line (/root/libical_asan/build/lib/libical.so.2+0x3feb6)
    #5 0x400cbd in main (/root/libical_asan/build/src/test/parser+0x400cbd)
    #6 0x7f89bbe87a3f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x20a3f)

SUMMARY: AddressSanitizer: heap-use-after-free ??:0 ??
Shadow bytes around the buggy address:
  0x0c047fff9d80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9d90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9da0: fa fa fa fa fa fa fa fa fa fa fd fd fa fa fd fd
  0x0c047fff9db0: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fd
  0x0c047fff9dc0: fa fa fd fa fa fa fd fd fa fa fd fa fa fa fd fd
=>0x0c047fff9dd0: fa fa[fd]fa fa fa fd fd fa fa fd fd fa fa fd fd
  0x0c047fff9de0: fa fa fd fa fa fa 00 07 fa fa fd fd fa fa 04 fa
  0x0c047fff9df0: fa fa fd fa fa fa fd fa fa fa fd fd fa fa fd fa
  0x0c047fff9e00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9e10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9e20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 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
==2461==ABORTING



Expected results:

Not crash.

Let me know if the stack traces are insufficient for reproduction.
Flags: sec-bounty?
Philipp: do you have contacts with the libical team, or do we just grab their source. We'll need to figure out if these could be triggered in Thunderbird/Lightning, but even if they can't we need to let the libical maintainers know about them.

If you don't have contacts let the security team know and we'll reach out through our more general OSS security contacts.
Component: Untriaged → General
Flags: needinfo?(philipp)
Product: Thunderbird → Calendar
Lightning uses an older version of libical actually, I believe it is a derivative of 0.47. We are somewhat aware that there are issues with this older version, but as we are aiming to get rid of it we haven't taken action.

I've been in contact with Allen Winter before, although it has been a while. Per github his email is allen.winter@kdab.com. I have better contact to Ken Murchison, while he does not belong to the github org around libical, he is the #2 contributor for the project.

Let me know if you want me to introduce you to Ken or Allen, or if you want me to convey something.
Flags: needinfo?(philipp)
(Reporter)

Comment 3

3 years ago
Using my crashes against libical 0.47 yields even more results actually. They are attached.

id:000030,sig:11,sync:fuzzer6,src:000826.asan:==19555==ERROR: AddressSanitizer: heap-use-after-free on address 0x60200000ee93 at pc 0x7f59a7f57649 bp 0x7ffd54ad5be0 sp 0x7ffd54ad5358
id:000034,sig:06,sync:fuzzer6,src:001091.asan:==22222==ERROR: AddressSanitizer: heap-use-after-free on address 0x60200000ee75 at pc 0x7ff8859b1649 bp 0x7ffe54e12520 sp 0x7ffe54e11c98
id:000083,sig:11,src:000192+002306,op:splice,rep:8.asan:==14873==ERROR: AddressSanitizer: attempting free on address which was not malloc()-ed: 0x602000010390 in thread T0
id:000090,sig:11,src:000009+001525,op:splice,rep:128.asan:==18374==ERROR: AddressSanitizer: attempting free on address which was not malloc()-ed: 0x602000002cb0 in thread T0
id:000140,sig:11,src:000088+001265,op:splice,rep:16.asan:==18887==ERROR: AddressSanitizer: attempting free on address which was not malloc()-ed: 0x60200002c310 in thread T0
id:000161,sig:11,src:000653+002322,op:splice,rep:64.asan:==32030==ERROR: AddressSanitizer: attempting free on address which was not malloc()-ed: 0x60200002c610 in thread T0
id:000186,sig:11,src:000841+001496,op:splice,rep:128.asan:==16908==ERROR: AddressSanitizer: attempting free on address which was not malloc()-ed: 0x602000003670 in thread T0
id:000195,sig:11,src:001658+001377,op:splice,rep:8.asan:==26452==ERROR: AddressSanitizer: attempting free on address which was not malloc()-ed: 0x602000010f50 in thread T0
id:000196,sig:11,src:001563+001383,op:splice,rep:64.asan:==27121==ERROR: AddressSanitizer: attempting free on address which was not malloc()-ed: 0x60200000f910 in thread T0
id:000200,sig:11,src:000541+002389,op:splice,rep:8.asan:==30280==ERROR: AddressSanitizer: attempting free on address which was not malloc()-ed: 0x60200000fd90 in thread T0
id:000238,sig:11,src:000865+001517,op:splice,rep:128.asan:==26032==ERROR: AddressSanitizer: attempting free on address which was not malloc()-ed: 0x6020000231f0 in thread T0
id:000630,orig:dd74deb4-170c-11e6-8f22-07ec6c8ef5ef.min.radamsa.92.min.min.asan==22805==ERROR: AddressSanitizer: heap-use-after-free on address 0x60200000ef53 at pc 0x7fc548eb8649 bp 0x7fff97022d40 sp 0x7fff970224b8
id:000946,orig:id:001204,sync:fuzzer1,src:000584.min.asan:==23055==ERROR: AddressSanitizer: heap-use-after-free on address 0x60200000ef53 at pc 0x7fc37f1a7649 bp 0x7ffd125935d0 sp 0x7ffd12592d48
id:001201,sync:fuzzer1,src:000157.asan:==23380==ERROR: AddressSanitizer: heap-use-after-free on address 0x60200000e8f5 at pc 0x7fe91e5b4649 bp 0x7fff3f284e70 sp 0x7fff3f2845e8
id:001436,src:000014+001065,op:splice,rep:2.asan:==23710==ERROR: AddressSanitizer: heap-use-after-free on address 0x60200000ef35 at pc 0x7fdba5345649 bp 0x7ffecbefce10 sp 0x7ffecbefc588
id:001497,src:000600+001051,op:splice,rep:2.asan:==23956==ERROR: AddressSanitizer: heap-use-after-free on address 0x60200000ee94 at pc 0x7f2ef10dc649 bp 0x7ffe2493a9f0 sp 0x7ffe2493a168
id:001637,src:001342+000602,op:splice,rep:8.asan:==24262==ERROR: AddressSanitizer: heap-use-after-free on address 0x60200000eef5 at pc 0x7f199bc6a649 bp 0x7ffdb7ddca20 sp 0x7ffdb7ddc198
id:001639,src:001342+000602,op:splice,rep:2.asan:==24644==ERROR: AddressSanitizer: heap-use-after-free on address 0x60200000ee95 at pc 0x7f0536faa649 bp 0x7ffeb0aba500 sp 0x7ffeb0ab9c78
id:001694,src:000630+001636,op:splice,rep:8.asan:==24893==ERROR: AddressSanitizer: heap-use-after-free on address 0x60200000ef53 at pc 0x7f7bd79b0649 bp 0x7fff1eb4c6f0 sp 0x7fff1eb4be68
(Reporter)

Comment 4

3 years ago
Created attachment 8756639 [details]
Crashes focused on libical 0.47
If you find different crashes with different causes, you will need to open up a bug for each. They cannot all go into the same bug as it muddies up fixing things then because some may get fixed and the others lost.
(Reporter)

Comment 6

3 years ago
Yes, sorry about that. Since this was originally opened with use-after-free in the title, I will keep those here and open a new bug report with the other crashes.
(Reporter)

Comment 7

3 years ago
Created attachment 8756650 [details]
Use-after-free specific crashes and stack traces for libical 0.47
Attachment #8756033 - Attachment is obsolete: true
Attachment #8756639 - Attachment is obsolete: true
Each use-after-free, if they are a different crash and a different cause, should be in its own bug.
(Reporter)

Comment 9

3 years ago
I believe they are the same bug, just with different paths being used to reach it.
Hi Brandon,

Thanks for the bug report. I am unable to reproduce the crash using commit af48b97b12f8d61bbaad3cd40d3a122a602a8648.

Did you happen to make local changes to the source before fuzzing? Also can you please up date to the latest commit and attach a single test case that will reproduce the crash as well as a matching ASan log with line numbers?
(Reporter)

Comment 11

3 years ago
I've made no source changes. I tested against 0.47, 1.0, and master from 5 days ago (https://github.com/libical/libical/issues/235). The commit you are testing is from 3 days ago.

However, with the latest commit, I am able to still repro the issue with the testcase I will attach soon.

# git log | head
commit af48b97b12f8d61bbaad3cd40d3a122a602a8648
Author: Allen Winter <allen.winter@kdab.com>
Date:   Tue May 24 10:14:54 2016 -0400

    CMakeLists.txt - remove -Wpedantic




The errors persist after remaking the master branch:

# grep "ERROR: Add" *.asan 
id:000030,sig:11,sync:fuzzer6,src:000826.asan:==11557==ERROR: AddressSanitizer: heap-use-after-free on address 0x60200000ee93 at pc 0x7fdfb3f36649 bp 0x7ffc80615310 sp 0x7ffc80614a88
id:000630,orig:dd74deb4-170c-11e6-8f22-07ec6c8ef5ef.min.radamsa.92.min.min.asan:==23122==ERROR: AddressSanitizer: heap-use-after-free on address 0x60200000ef53 at pc 0x7f30bfdc7649 bp 0x7ffdcda056f0 sp 0x7ffdcda04e68
id:000946,orig:id:001204,sync:fuzzer1,src:000584.min.asan:==23469==ERROR: AddressSanitizer: heap-use-after-free on address 0x60200000ef53 at pc 0x7f5e59bc9649 bp 0x7ffc3b9ebb20 sp 0x7ffc3b9eb298
id:001201,sync:fuzzer1,src:000157.asan:==23857==ERROR: AddressSanitizer: heap-use-after-free on address 0x60200000e8f5 at pc 0x7f4a401f4649 bp 0x7ffe96c97170 sp 0x7ffe96c968e8
id:001436,src:000014+001065,op:splice,rep:2.asan:==24289==ERROR: AddressSanitizer: heap-use-after-free on address 0x60200000ef35 at pc 0x7f5cb0d43649 bp 0x7ffc44f15440 sp 0x7ffc44f14bb8
id:001497,src:000600+001051,op:splice,rep:2.asan:==24691==ERROR: AddressSanitizer: heap-use-after-free on address 0x60200000eeb4 at pc 0x7f9404ced649 bp 0x7ffe055e13c0 sp 0x7ffe055e0b38
id:001637,src:001342+000602,op:splice,rep:8.asan:==25111==ERROR: AddressSanitizer: heap-use-after-free on address 0x60200000eef5 at pc 0x7f64745cb649 bp 0x7ffd8f31d330 sp 0x7ffd8f31caa8
id:001639,src:001342+000602,op:splice,rep:2.asan:==25508==ERROR: AddressSanitizer: heap-use-after-free on address 0x60200000ee95 at pc 0x7f5a40bb2649 bp 0x7ffc374cb6b0 sp 0x7ffc374cae28
id:001694,src:000630+001636,op:splice,rep:8.asan:==25881==ERROR: AddressSanitizer: heap-use-after-free on address 0x60200000ef53 at pc 0x7ff127fdf649 bp 0x7ffd2726a880 sp 0x7ffd27269ff8


Example:
# cat id\:000030\,sig\:11\,sync\:fuzzer6\,src\:000826
BEGIN:VCAR
0:
X;0: 0000
REQUEST-STATUS:2;;
REQUEST-STATUS:2;;
REQUEST-STATUS:2.0;;
REQUEST-STATUS:2;;
REQUEST-STATUS:2.0;;
REQUEST-STATUS:2;;
REQUEST-STATUS:2.0;;
REQUEST-STATUS:2;;
REQUEST-STATUS:2.0;;
REQUEST-STATUS:2;;
REQUEST-STATUS:10;
REQUEST-STATUS:2;;
REQUEST-STATUS:2.0;;
REQUEST-STATUS:2;;
REQUEST-STATUS:2.0;;
REQUEST-STATUS:2;;
REQUEST-STATUS:2.0;;
REQUEST-STATUS:2;;
REQUEST-STATUS:2.-10
REQUEST-STATUS:2;;
REQUEST-STATUS:00;
REQUEST-STATUS:2.0;;
REQUEST-STATUS:2.0;;
REQUEST-STATUS:20
0000;
REQUEST-STATUS:0090
REQUEST-STATUS:2.0;;
REQUEST-STATUS:2.0;;
0000:0
REQUEST-STATUS:2.0;;
REQUEST-STATUS:2.0;;
REQUEST-STATUS:2.0;;
REQUEST-STATUS:2.0;;
REQUEST-STATUS:2.0;;
REQUEST-STATUS:2.0;;
REQUEST-STATUS:2.0;;
REQUEST-STATUS:2.2147483649;;
REQUEST-STATUS:2.0;;
REQUEST-STATUS:2.0;;
REQUEST-STATUS:2.0000
PRODID:00000\,000000000000000000000000000
00000000000000000000000000000000000000000000000000
000000000000:0000
SUMMARY:0
00000:0000
000:00
END:0000

BEGIN:000000000
0:00
root@w00den-fuzzer:~/syncdir/new_crashes# ~/libical_asan/build/src/test/parser ./id:000030,sig:11,sync:fuzzer6,src:000826 
=================================================================
==24960==ERROR: AddressSanitizer: heap-use-after-free on address 0x60200000ee93 at pc 0x7f064bc15649 bp 0x7fffb740e2e0 sp 0x7fffb740da58
READ of size 2 at 0x60200000ee93 thread T0
    #0 0x7f064bc15648  (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x60648)
    #1 0x7f064bc165a5 in __interceptor_vsnprintf (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x615a5)
    #2 0x7f064bc16811 in snprintf (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x61811)
    #3 0x7f064b988b72 in icalreqstattype_as_string_r (/root/libical_asan/build/lib/libical.so.2+0x4fb72)
    #4 0x7f064b98b4bd in icalvalue_as_ical_string_r (/root/libical_asan/build/lib/libical.so.2+0x524bd)
    #5 0x7f064b97a08c in icalproperty_as_ical_string_r (/root/libical_asan/build/lib/libical.so.2+0x4108c)
    #6 0x7f064b970132 in icalcomponent_as_ical_string_r (/root/libical_asan/build/lib/libical.so.2+0x37132)
    #7 0x7f064b96ffd1 in icalcomponent_as_ical_string (/root/libical_asan/build/lib/libical.so.2+0x36fd1)
    #8 0x400cd4 in main (/root/libical_asan/build/src/test/parser+0x400cd4)
    #9 0x7f064b58fa3f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x20a3f)
    #10 0x400ae8 in _start (/root/libical_asan/build/src/test/parser+0x400ae8)

0x60200000ee94 is located 0 bytes to the right of 4-byte region [0x60200000ee90,0x60200000ee94)
freed by thread T0 here:
    #0 0x7f064bc4d6aa in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x986aa)
    #1 0x7f064b975667 in icalmemory_free_buffer (/root/libical_asan/build/lib/libical.so.2+0x3c667)
    #2 0x7f064b9790d7 in icalparser_add_line (/root/libical_asan/build/lib/libical.so.2+0x400d7)
    #3 0x400cbd in main (/root/libical_asan/build/src/test/parser+0x400cbd)
    #4 0x7f064b58fa3f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x20a3f)

previously allocated by thread T0 here:
    #0 0x7f064bc4d9aa in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x989aa)
    #1 0x7f064b9755d3 in icalmemory_new_buffer (/root/libical_asan/build/lib/libical.so.2+0x3c5d3)
    #2 0x7f064b97744c in make_segment (/root/libical_asan/build/lib/libical.so.2+0x3e44c)
    #3 0x7f064b97782d in icalparser_get_value (/root/libical_asan/build/lib/libical.so.2+0x3e82d)
    #4 0x7f064b978eb6 in icalparser_add_line (/root/libical_asan/build/lib/libical.so.2+0x3feb6)
    #5 0x400cbd in main (/root/libical_asan/build/src/test/parser+0x400cbd)
    #6 0x7f064b58fa3f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x20a3f)

SUMMARY: AddressSanitizer: heap-use-after-free ??:0 ??
Shadow bytes around the buggy address:
  0x0c047fff9d80: fa fa fd fa fa fa fd fd fa fa fd fa fa fa fd fd
  0x0c047fff9d90: fa fa fd fa fa fa fd fd fa fa fd fa fa fa fd fd
  0x0c047fff9da0: fa fa fd fa fa fa fd fd fa fa fd fa fa fa fd fd
  0x0c047fff9db0: fa fa fd fa fa fa fd fd fa fa fd fa fa fa fd fd
  0x0c047fff9dc0: fa fa fd fa fa fa fd fd fa fa fd fa fa fa fd fd
=>0x0c047fff9dd0: fa fa[fd]fa fa fa fd fd fa fa 05 fa fa fa fd fa
  0x0c047fff9de0: fa fa fd fa fa fa 02 fa fa fa 02 fa fa fa fd fa
  0x0c047fff9df0: fa fa 04 fa fa fa fd fa fa fa fd fa fa fa fd fa
  0x0c047fff9e00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9e10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9e20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 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
==24960==ABORTING
(Reporter)

Comment 12

3 years ago
Created attachment 8757553 [details]
Testcase demonstrating use after free in libical commit af48b97b12f8d61bbaad3cd40d3a122a602a8648
Hmm still no luck on my side. I'm not saying there isn't bug, only that I can't confirm it. You may need to contact Ken or Allen as suggested by Philipp (see comment 2) if you are not already in contact with them.

I did notice that the default build is not a static build. Perhaps you are using an old version of the lib from some where else on your system? Shot in the dark here, but hey I've done it before. First clear out build directly completely then try:

cmake -DCMAKE_CXX_FLAGS="-fsanitize=address -fno-omit-frame-pointer" -DCMAKE_EXE_LINKER_FLAGS="-fsanitize=address" -DSTATIC_ONLY=true -DCMAKE_CXX_COMPILER="clang++" ..

The only addition I've made is -DSTATIC_ONLY=true so we get a static build and we know the code we are testing is in that binary. If you can still reproduce the issue after that I'll have to leave it up to the devs to investigate.

Updated

3 years ago
Depends on: 1160990
(Reporter)

Comment 14

3 years ago
In the linked secret github gist, the entire process of rm'ing the build, rebuilding, then running the input to produce the use-after-free has been documented against the latest git commit.

https://gist.github.com/brandonprry/9208ebd0bd4b79a6b2e98c92c8994f0a

The issue still persists. If you don't believe that Thunderbird is vulnerable to this, that's OK. I knew going in what I was testing wasn't exactly what shipped with Thunderbird, but I didn't know what version it used (until just recently when 0.47 was mentioned). It's difficult to test against exactly what Thunderbird has, but if you have any suggestions, I will try them.
Ha got it! Compiler versions :) Thanks for the gist looking at the diff helped.

FWIW: I am was using clang 3.7.1 now I'm using clang 3.8.0.
Please also note that the version of libical that Lightning uses has some patches on top of 0.47, so there may be slight differences to the release version and maybe the one or other case less than in the github release.
(Reporter)

Comment 17

3 years ago
I was able to copy the libical source code from the Lightning source tree into my libical 0.47 source tree, replacing any files that were changed with the Lightning copy. I was still able to reproduce the use after free.
Great, thanks for checking!
(Reporter)

Comment 19

3 years ago
Any updates to this? Tyson, were you able to repro the issue with the Thunderbird source code for libical?

Thanks
Can you look at this, Philipp?
Flags: needinfo?(philipp)
Yes, I'll take a look at these on the weekend. Leaving needinfo so I don't forget.
Putting Ken and Allen on CC for the record. tl;dr; these issues also apply to the latest libical on github. If you also have time to take a look I would certainly appreciate, of course I'd take care of the backport myself.
(Reporter)

Comment 23

3 years ago
Hi, were we able to confirm these affect Lightning/Thunderbird?
(Reporter)

Comment 24

3 years ago
If there is any other information required to determine whether this affects Lightning/Thunderbird, please ask. In the original bug report, I provided the source code I believed to be vulnerable in Thunderbird.

http://mxr.mozilla.org/comm-central/search?string=icalcomponent_as_ical_string&find=%2F&findi=&filter=%5E%5B%5E%5C0%5D*%24&hitlimit=&tree=comm-central
Unfortunately I didn't get around this due to day job. There is a work week next week so things will probably be slow, but this is on my todo list.
(Reporter)

Comment 26

3 years ago
Ok no worries. Thanks for the update. I am currently traveling for work through next week. I will swing back when I get back home.
(Reporter)

Comment 27

3 years ago
I am back from traveling. Please let me know if there is anything I can do to help speed this up a bit.
(Reporter)

Comment 28

2 years ago
In an effort to provide more information, I have spent the day attempting to build Thunderbird + calendar with ASan to prove the code path I linked is viable, but I am unable to build thunderbird + calendar with ASan.

Building without ASan builds as expected but I don't get clear crashes. The line below will build Thunderbird + calendar successfully.

export CC=clang CXX=clang++ CFLAGS="" CXXFLAGS="" LDFLAGS=""; make -f client.mk


This one fails to build, and I am not sure why at this point. 

export CC=clang CXX=clang++ CFLAGS="-fsanitize=address" CXXFLAGS="" LDFLAGS="-fsanitize=address"; make -f client.mk
(Reporter)

Comment 29

2 years ago
So, after having dug in to this a bit more, it looks like an attacker may not be able to directly control the ical data being used through the vector I have pointed out, but I am not 100%.

However, while going through the source code, I noticed the ical function used to parse untrusted ical data is actually icalparser_parse_string(), which I have actually fuzzed and have a few bugs in as well. I will open these separately this evening after triaging.
(Reporter)

Comment 30

2 years ago
Since there is no traction on any of these bugs related to libical, I've gone ahead and just made my research into libical public. I won't be updating these bug reports anymore.

Feel free to do whatever you would like with the bug reports I have opened.

https://github.com/brandonprry/ical-fuzz
None of your bugs but one were shown to affect Thunderbird, which is what this is the bugzilla for (other than Firefox). Did you report these issues upstream to libical directly?
Flags: sec-bounty? → sec-bounty-
Group: mail-core-security
Debian seems to have assigned CVE-2016-5824 to this one
https://lists.debian.org/debian-lts/2016/08/msg00192.html
Alias: CVE-2016-5824

Comment 33

2 years ago
While importing the https://bugzilla.mozilla.org/attachment.cgi?id=8757553 (attached to this bug) file from the "Events and Tasks" menu option in Thunderbird 45 running on Fedora 24 under Valgrind, I see,

==5430== Invalid read of size 1
==5430==    at 0x5B4AFB4: vfprintf (in /usr/lib64/libc-2.23.so)
==5430==    by 0x5C11505: __vsnprintf_chk (in /usr/lib64/libc-2.23.so)
==5430==    by 0x5C11467: __snprintf_chk (in /usr/lib64/libc-2.23.so)
==5430==    by 0x30410227: ??? (in /home/user/.thunderbird/cupk658m.default/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}/components/libcalbasecomps.so)
==5430==    by 0x30410E61: ??? (in /home/user/.thunderbird/cupk658m.default/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}/components/libcalbasecomps.so)
==5430==    by 0x3040B1D3: ??? (in /home/user/.thunderbird/cupk658m.default/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}/components/libcalbasecomps.so)
==5430==    by 0x30408285: ??? (in /home/user/.thunderbird/cupk658m.default/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}/components/libcalbasecomps.so)
==5430==    by 0x30408372: ??? (in /home/user/.thunderbird/cupk658m.default/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}/components/libcalbasecomps.so)
==5430==    by 0x30415ED7: ??? (in /home/user/.thunderbird/cupk658m.default/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}/components/libcalbasecomps.so)
==5430==    by 0x30415F45: ??? (in /home/user/.thunderbird/cupk658m.default/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}/components/libcalbasecomps.so)
==5430==    by 0x834FDB0: NS_InvokeByIndex (in /usr/lib64/thunderbird/libxul.so)
==5430==    by 0x8771493: ??? (in /usr/lib64/thunderbird/libxul.so)
==5430==  Address 0x2f2e84c3 is 3 bytes inside a block of size 4 free'd
==5430==    at 0x4C2CD5A: free (vg_replace_malloc.c:530)
==5430==    by 0x3040A19D: ??? (in /home/user/.thunderbird/cupk658m.default/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}/components/libcalbasecomps.so)
==5430==    by 0x3040A263: ??? (in /home/user/.thunderbird/cupk658m.default/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}/components/libcalbasecomps.so)
==5430==    by 0x3040A361: ??? (in /home/user/.thunderbird/cupk658m.default/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}/components/libcalbasecomps.so)

Extension "{e2fda1a4-762b-4020-b5ad-a41df1933103}" is Lightning. So upstream Thunderbird seems to be affected by this CVE.
Component: General → Internal Components

Comment 34

2 years ago
Here is a better backtrace for the same action as above,

==20811== Invalid read of size 1
==20811==    at 0x5B4AFB4: vfprintf (in /usr/lib64/libc-2.23.so)
==20811==    by 0x5C11505: __vsnprintf_chk (in /usr/lib64/libc-2.23.so)
==20811==    by 0x5C11467: __snprintf_chk (in /usr/lib64/libc-2.23.so)
==20811==    by 0x30110227: UnknownInlinedFun (stdio2.h:64)
==20811==    by 0x30110227: icalreqstattype_as_string_r (icaltypes.c:198)
==20811==    by 0x30110E61: icalvalue_as_ical_string_r (icalvalue.c:1200)
==20811==    by 0x3010B1D3: icalproperty_as_ical_string_r (icalproperty.c:499)
==20811==    by 0x30108285: icalcomponent_as_ical_string_r (icalcomponent.c:351)
==20811==    by 0x30108372: icalcomponent_as_ical_string (icalcomponent.c:301)
==20811==    by 0x30115ED7: calIcalComponent::Serialize(char**) (calICSService.cpp:1033)
==20811==    by 0x30115F45: calIcalComponent::SerializeToICS(nsACString&) (calICSService.cpp:981)
==20811==    by 0x8350076: NS_InvokeByIndex (xptcinvoke_x86_64_unix.cpp:176)
==20811==    by 0x8771895: Invoke (XPCWrappedNative.cpp:2097)
==20811==    by 0x8771895: Call (XPCWrappedNative.cpp:1414)
==20811==    by 0x8771895: XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) (XPCWrappedNative.cpp:1381)
==20811==  Address 0x36164f03 is 3 bytes inside a block of size 4 free'd
==20811==    at 0x4C2CD5A: free (vg_replace_malloc.c:530)
==20811==    by 0x3010A19D: icalparser_add_line (icalparser.c:1103)
==20811==    by 0x3010A263: icalparser_parse (icalparser.c:623)
==20811==    by 0x3010A361: icalparser_parse_string (icalparser.c:1250)
==20811==    by 0x30114EEC: calICSService::ParseICS(nsACString const&, calITimezoneProvider*, calIIcalComponent**) (calICSService.cpp:1257)
==20811==    by 0x8350076: NS_InvokeByIndex (xptcinvoke_x86_64_unix.cpp:176)
==20811==    by 0x8771895: Invoke (XPCWrappedNative.cpp:2097)
==20811==    by 0x8771895: Call (XPCWrappedNative.cpp:1414)
==20811==    by 0x8771895: XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) (XPCWrappedNative.cpp:1381)
==20811==    by 0x8776BDD: XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) (XPCWrappedNativeJSOps.cpp:1115)
==20811==    by 0xA221897: CallJSNative (jscntxtinlines.h:240)
==20811==    by 0xA221897: js::Invoke(JSContext*, JS::CallArgs const&, js::MaybeConstruct) (Interpreter.cpp:444)
==20811==    by 0xA21C5E4: Interpret(JSContext*, js::RunState&) (Interpreter.cpp:2766)
==20811==    by 0xA221550: js::RunScript(JSContext*, js::RunState&) (Interpreter.cpp:391)
==20811==    by 0xA2217F6: js::Invoke(JSContext*, JS::CallArgs const&, js::MaybeConstruct) (Interpreter.cpp:462)
==20811==  Block was alloc'd at
==20811==    at 0x4C2BBAD: malloc (vg_replace_malloc.c:299)
==20811==    by 0x30108E76: icalmemory_new_buffer (icalmemory.c:266)
==20811==    by 0x301093FB: make_segment (icalparser.c:224)
==20811==    by 0x3010A11D: icalparser_add_line (icalparser.c:1072)
==20811==    by 0x3010A263: icalparser_parse (icalparser.c:623)
==20811==    by 0x3010A361: icalparser_parse_string (icalparser.c:1250)
==20811==    by 0x30114EEC: calICSService::ParseICS(nsACString const&, calITimezoneProvider*, calIIcalComponent**) (calICSService.cpp:1257)
==20811==    by 0x8350076: NS_InvokeByIndex (xptcinvoke_x86_64_unix.cpp:176)
==20811==    by 0x8771895: Invoke (XPCWrappedNative.cpp:2097)
==20811==    by 0x8771895: Call (XPCWrappedNative.cpp:1414)
==20811==    by 0x8771895: XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) (XPCWrappedNative.cpp:1381)
==20811==    by 0x8776BDD: XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) (XPCWrappedNativeJSOps.cpp:1115)
==20811==    by 0xA221897: CallJSNative (jscntxtinlines.h:240)
==20811==    by 0xA221897: js::Invoke(JSContext*, JS::CallArgs const&, js::MaybeConstruct) (Interpreter.cpp:444)
==20811==    by 0xA21C5E4: Interpret(JSContext*, js::RunState&) (Interpreter.cpp:2766)
==20811==

Comment 35

3 months ago
(In reply to Philipp Kewisch [:Fallen] [:πŸ“†] from comment #2)
> Lightning uses an older version of libical actually, I believe it is a
> derivative of 0.47. We are somewhat aware that there are issues with this
> older version, but as we are aiming to get rid of it we haven't taken action.

Philipp, does that make this bug wontfix?


(In reply to [PTO until Aug 28] from comment #31)
> None of your bugs but one were shown to affect Thunderbird, which is what
> this is the bugzilla for (other than Firefox). Did you report these issues
> upstream to libical directly?

https://github.com/libical/libical/issues/235 was filed, then quickly closed. 

https://github.com/libical/libical/issues/286 was opened Jan 20, 2017 as a followup, then closed. Near the end of that bug only https://github.com/libical/libical/issues/253 was still open, and that was closed fixed ~May 28, 2017. (winterz had other bugs open, that I have not cited here, according to https://github.com/libical/libical/issues/286#issuecomment-275700312 )

(https://lists.debian.org/debian-lts/2016/08/msg00192.html has not been updated )

Comment 36

3 months ago
all those bugs have been squashed since libical3.0.0

the libical team has done its part in this.
(Assignee)

Comment 37

2 months ago
Created attachment 9009439 [details] [diff] [review]
PortUseAfterFreeFixesForLibical-V1.diff

This patch backports four upstream commits I identified based on the previous comments to our version of libical:

* Issue 253 / Commit 6b9438d746cec6e4e632d78c5244f4be6314d1c9
* Issue 251 / Commit 38757abb495ea6cb40faa5418052278bf75040f7
* Issue 251 / Commit 04d84749e53db08c71ed0ce8b6ba5c11082743cd
* Issue 251 / Commit 830d9530817516377c2bc3b532798ce2c6b4765a

This is compiling and working locally for me, but I neither haven't done a try push so far nor have I investigated whether this would prevent the reported crashes.

Allen, can you confirm that I catched all upstream commits associated to CVE-2016-5824 since not all of them are clearly referenced in the issues?
Assignee: nobody → makemyday
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Flags: needinfo?(winter)
Attachment #9009439 - Flags: review?(philipp)
Comment on attachment 9009439 [details] [diff] [review]
PortUseAfterFreeFixesForLibical-V1.diff

Review of attachment 9009439 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks for looking through these. Codewise this looks ok. Can you do a try run? I hope these don't depend on other upstream changes.
Attachment #9009439 - Flags: review?(philipp) → review+
(Assignee)

Comment 39

2 months ago
(In reply to Philipp Kewisch [:Fallen] [:πŸ“†] from comment #38)
> Thanks for looking through these. Codewise this looks ok. Can you do a try
> run? I hope these don't depend on other upstream changes.

I currently have problems to push, so if anybody else can do a try push before I fixed my issue, that would be appreciated.
(Assignee)

Comment 40

2 months ago
Created attachment 9012583 [details] [diff] [review]
PortUseAfterFreeFixesForLibical-V2.diff

I have removed the change to parser_get_next_char in icalparser.c from the previous version of the patch since that led to test failures due to a different behaviour including to fail to parse an attendee at all if its CN has double dquotes (like CN=""some name"") instead of just having an attendee without a valid CN in this case. Maybe some more backports would have been needed to make it work as before or it's an upstream issue.

But since that change (upstream commit 04d84749e53db08c71ed0ce8b6ba5c11082743cd) is technically not needed beacause our code is different from upstream for that function and the upstream fix corrects something we don't have, we can omit this backport entirely here.

My try push for this patch doesn't have any releated failures: https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&selectedJob=201941490&revision=d753c49aa747091057455a35ee1224d24bd73d0a
Attachment #9009439 - Attachment is obsolete: true
Attachment #9012583 - Flags: review+
(Assignee)

Updated

2 months ago
Keywords: checkin-needed
(Assignee)

Comment 41

2 months ago
Comment on attachment 9012583 [details] [diff] [review]
PortUseAfterFreeFixesForLibical-V2.diff

Since backing on c-c probably won't bring any findings (since ical.js is the default) and I have been running the patched version for some time now without an issue, we should consider an early uplift.
Attachment #9012583 - Flags: approval-calendar-esr?(philipp)
Attachment #9012583 - Flags: approval-calendar-beta?(philipp)

Comment 42

2 months ago
Comment on attachment 9012583 [details] [diff] [review]
PortUseAfterFreeFixesForLibical-V2.diff

Review of attachment 9012583 [details] [diff] [review]:
-----------------------------------------------------------------

::: calendar/libical/src/libical/icaltime.c
@@ +522,2 @@
>      } else if ((size == 16) || (size == 20)) { /* UTC time, ends in 'Z'*/
> +        if ((str[size-1] != 'Z'))

This line is the only change here, all the rest of the changes in this hunk are white-space changes that change tabs to spaces. Is that intentional? Personally, I'd only change that one line given that the entire library is riddled with white-space issues.

Updated

2 months ago
Flags: needinfo?(makemyday)
(Assignee)

Comment 43

2 months ago
Yes, the whitespace changes are intended. Please land the patch as is.
Flags: needinfo?(makemyday)

Comment 44

2 months ago
Pushed by mozilla@jorgk.com:
https://hg.mozilla.org/comm-central/rev/4a2171ca49da
Porting upstream fixes for use-after-free vulnerability of libical. r=philipp DONTBUILD
Status: ASSIGNED → RESOLVED
Last Resolved: 2 months ago
Keywords: checkin-needed
Resolution: --- → FIXED

Updated

2 months ago
Target Milestone: --- → 6.6

Comment 45

27 days ago
Comment on attachment 9012583 [details] [diff] [review]
PortUseAfterFreeFixesForLibical-V2.diff

Too late for 63/6.5 beta now.
Attachment #9012583 - Flags: approval-calendar-beta?(philipp)
You need to log in before you can comment on or make changes to this bug.