1275400 - (CVE-2016-5824) Handful use-after-free crashes in libical (used in Thunderbird)

Status: RESOLVED FIXED

(Calendar :: Internal Components, defect)

Description

[Brandon Perry]

Attachment: 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.

Comment 1

[Daniel Veditz [:dveditz]]

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.

Comment 2

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

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 [e-mail]. 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.

Comment 3

[Brandon Perry]

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

Comment 4

[Brandon Perry]

Attachment: Crashes focused on libical 0.47

Comment 5

[Al Billings [:abillings - ex-MoCo]]

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.

Comment 6

[Brandon Perry]

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.

Comment 7

[Brandon Perry]

Attachment: Use-after-free specific crashes and stack traces for libical 0.47

Comment 8

[Al Billings [:abillings - ex-MoCo]]

Each use-after-free, if they are a different crash and a different cause, should be in its own bug.

Comment 9

[Brandon Perry]

I believe they are the same bug, just with different paths being used to reach it.

Comment 10

[Tyson Smith [:tsmith]]

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?

Comment 11

[Brandon Perry]

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 <[e-mail]>
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

Comment 12

[Brandon Perry]

Attachment: Testcase demonstrating use after free in libical commit af48b97b12f8d61bbaad3cd40d3a122a602a8648

Comment 13

[Tyson Smith [:tsmith]]

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.

Comment 14

[Brandon Perry]

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.

Comment 15

[Tyson Smith [:tsmith]]

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.

Comment 16

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

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.

Comment 17

[Brandon Perry]

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.

Comment 18

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Great, thanks for checking!

Comment 19

[Brandon Perry]

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

Thanks

Comment 20

[Al Billings [:abillings - ex-MoCo]]

Can you look at this, Philipp?

Comment 21

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Yes, I'll take a look at these on the weekend. Leaving needinfo so I don't forget.

Comment 22

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

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.

Comment 23

[Brandon Perry]

Hi, were we able to confirm these affect Lightning/Thunderbird?

Comment 24

[Brandon Perry]

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

Comment 25

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

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.

Comment 26

[Brandon Perry]

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.

Comment 27

[Brandon Perry]

I am back from traveling. Please let me know if there is anything I can do to help speed this up a bit.

Comment 28

[Brandon Perry]

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

Comment 29

[Brandon Perry]

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.

Comment 30

[Brandon Perry]

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

Comment 31

[Al Billings [:abillings - ex-MoCo]]

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?

Comment 32

[Daniel Veditz [:dveditz]]

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

Comment 33

[Dhiru Kholia]

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.

Comment 34

[Dhiru Kholia]

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

[Wayne Mery (:wsmwk)]

(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

[Allen Winter]

all those bugs have been squashed since libical3.0.0

the libical team has done its part in this.

Comment 37

[[:MakeMyDay]]

Attachment: 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?

Comment 38

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

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.

Comment 39

[[:MakeMyDay]]

(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.

Comment 40

[[:MakeMyDay]]

Attachment: 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

Comment 41

[[:MakeMyDay]]

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.

Comment 42

[Jorg K (CEST = GMT+2)]

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.

Comment 43

[[:MakeMyDay]]

Yes, the whitespace changes are intended. Please land the patch as is.

Comment 44

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/4a2171ca49da
Porting upstream fixes for use-after-free vulnerability of libical. r=philipp DONTBUILD

Comment 45

[Jorg K (CEST = GMT+2)]

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

Too late for 63/6.5 beta now.

Comment 46

[Jorg K (CEST = GMT+2)]

TB 60.5 ESR, Cal. 6.2.5:
https://hg.mozilla.org/releases/comm-esr60/rev/44f8c542e1baf20d3f9f0bff6cf11dbf5ffeef9f

Target needs to be set to 6.2.5. Philipp?