Open Bug 1280832 (CVE-2016-5825) Opened 4 years ago Updated 1 month ago
Heap buffer overread in libical (icalparser
_parse _string function)
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: The following ICS file causes a heap overread in libical 0.47 in the icalparser_parse_string function. I wrote a small program simply calling the function to parse a given input for testing. BEGIN; TZNAME:\ TZNAME:\ TZNAME:\ TZNAME:\ TZNAME:\ TZNAME:\ TZNAME:\ TZNAME:\ Unfortunately, I have not been able to build a version of Thunderbird yet with ASan, which I would be able to use to get a better idea of what exactly could be affected. Valgrind doesn't much care about these as far as I can tell and doesn't report them. Actual results: The ASan results: ================================================================= ==19470==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000ef92 at pc 0x000000511d4f bp 0x7ffd2839ded0 sp 0x7ffd2839dec8 READ of size 1 at 0x60200000ef92 thread T0 #0 0x511d4e in icalmemory_strdup_and_dequote (/root/tmp/new_parse/parse_string047_asan+0x511d4e) #1 0x50f5b3 in icalvalue_new_from_string_with_error (/root/tmp/new_parse/parse_string047_asan+0x50f5b3) #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 0x7f68086cba3f 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) 0x60200000ef92 is located 0 bytes to the right of 2-byte region [0x60200000ef90,0x60200000ef92) 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 0x4ed417 in icalparser_get_value (/root/tmp/new_parse/parse_string047_asan+0x4ed417) #4 0x4f43c4 in icalparser_add_line (/root/tmp/new_parse/parse_string047_asan+0x4f43c4) #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 0x7f68086cba3f in __libc_start_main /build/glibc-ryFjv0/glibc-2.21/csu/libc-start.c:289 SUMMARY: AddressSanitizer: heap-buffer-overflow ??:0 icalmemory_strdup_and_dequote Shadow bytes around the buggy address: 0x0c047fff9da0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9db0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9dc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9dd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9de0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa 02 fa =>0x0c047fff9df0: fa fafa fa fa fd fa fa fa 04 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 0x0c047fff9e30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9e40: 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 Left alloca redzone: ca Right alloca redzone: cb ==19470==ABORTING Expected results: Not crashed.
Also, here is the code that calls icalparser_parse_string: https://dxr.mozilla.org/comm-central/search?q=icalparser_parse_string
Chiaki, do you use calendar?
Severity: normal → major
Component: Untriaged → Internal Components
Product: Thunderbird → Calendar
(In reply to Wayne Mery (:wsmwk, NI for questions) from comment #2) > Chiaki, do you use calendar? Not much so far. Also, starting around summer last year(?), I could not build ASAN-build any more: I am not sure if it was GCC change (I used 5.x instead of GCC 4.y), the local library changes of various libraries, or binutils tool chain such as gnu gold linker, etc. Maybe if someone can create a calendar event message with screwed up Date line as in comment 0, I can test one. This possibly means someone crafts a malformed calendar event message and sends it to someone, and if that someone uses TB, TB may crash (?)
"This possibly means someone crafts a malformed calendar event message and sends it to someone, and if that someone uses TB, TB may crash (?)" That's what I am looking at it as, but need someone better in-tune with the codebase to confirm.
(In reply to Brandon Perry from comment #4) > "This possibly means someone crafts a malformed calendar event message and > sends it to someone, and if that someone uses TB, TB may crash (?)" > > That's what I am looking at it as, but need someone better in-tune with the > codebase to confirm. You mention that you could not build an ASAN build of TB. Did you get a link-time error? (I think I got one: before that happened, I certainly could build one earlier last year.) TIA
I did not dig too much into it. 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
Also, FWIW, I am only attempting to compile C libraries with ASan (as libical is), which is why I only set the CFLAGS and LDFLAGS.
Hi, You might want to check https://bugzilla.mozilla.org/show_bug.cgi?id=1272498#c6 use the patch there to see if you can build an ASAN-build of TB. I could build one locally using GCC-5. Using that I tried to tinker with calendar event sent by MS OFFICE (saving it and then editing by an editor to change the entries, etc.) but no luck crashing TB. Maybe before ical library is called some sanity check is done at higher level?
These errors may crash TB, but they may not. I only get clear reproductions of the crash with ASan. There may be some checking that I am unaware of. Like I said, I need someone with better familiarity with the code base to make a better statement of vulnerability.
Didn't crash a stock Thunderbird (Mac). Not sure if it's not reachable in Thunderbird, or if the particular overread simple doesn't trigger an access violation. Even if it could be triggered in Thunderbird, if there's no scripting it would seem hard to exploit: random memory could be read into a calendar event, which shows up on the user's calendar (if the rest of it isn't too corrupted to get that far), but how does it get back to the attacker? If it doesn't it's not very useful as an exploit.
Does it have to make it back to an attacker to be considered a security vulnerability? Many times, heap over reads are used in conjunction with other vulns in order to achieve more than the sum of the parts.
For instance, Jon Oberheide's half-nelson exploit from 2010 is a great example of this, even though he takes advantage of uninitialized memory as opposed to a heap overread, the end effect is the same that potentially sensitive memory can be leaked/disclosed. Each of these bugs in and of themselves are 'not very useful as an exploit'. https://jon.oberheide.org/files/half-nelson.c
(In reply to Daniel Veditz [:dveditz] from comment #10) > Created attachment 8765011 [details] > bug1280832.ics > > Didn't crash a stock Thunderbird (Mac). I get the following with C-C TB under linux. (This is a debug build created locally. I also ran it using ASAN-enabled TB.). Error: [calICSService] Exception parsing item: ReferenceError: data is not defined Error: Error Parsing ICS: 2147500037 It seems that lightening seems to check data at the upper level somewhat, but as was pointed out, we should wait. At the same time, I think I would file RFE (Request for Enhancement) about TB's behavior. It seems - TB asks the users if s/he wants to add an event to the calendar if an e-mail with calendar event is received (in my case POP3 account). - TB does NOT ASK anything and automatically adds the event to one's calendar if we open an ics file [File] -> [Open] -> calendar This is rather bad. We can import broken/unwanted event into the calendar without the chance to inspect its content. E.g., we may never realize that the bad calendar event may try to use up a whole month six months head, for example, etc.
Hey Chiaki, The patch may work, but in Thunderbird 38 (the version in the ubuntu repos and what I am currently set up to build in my dev VM) the patch doesn't work (no surprise though). I am also unable to locate the code where you would supposedly patch it in, and no mention of MOZ_ASAN can be found in the release tarball of Thunderbird 38. I will work on getting a system set up with all of the deps required to build the bleeding edge code.
(In reply to Brandon Perry from comment #14) > Hey Chiaki, > > The patch may work, but in Thunderbird 38 (the version in the ubuntu repos > and what I am currently set up to build in my dev VM) the patch doesn't work > (no surprise though). Oh, I did not realize that you are working on ESR38 source tree. Sorry for the confusion. > I am also unable to locate the code where you would > supposedly patch it in, and no mention of MOZ_ASAN can be found in the > release tarball of Thunderbird 38. Well, I have been building C-C source tree irrespective of the current widely used version for quite some time and so have lost touch with how the source/document are distributed for the ESR version. Usually, there is a tarball for the released version, but now that you mention it, I am not entirely sure if ESR38 source code is ready for instrumentation with address sanitizer. > I will work on getting a system set up with all of the deps required to > build the bleeding edge code. Good luck. Preparing C-C source tree for building is NOT THAT difficult. Well, there may be a few quirks. (GCC 5.x seems to generate a buggy binary OR it changes the timing of various threads to the point that the ASAN-enabled version of C-C TB segfaults due to MOZ_ASSERT that says getStringBundle methods are not thread-safe (!?). Also, with GCC 6.x, you need to pass additional compiler flag -fno-delete-null-pointer-checks so that C-C TB does not crash at all. I am using Oracle VirtualBox which runs 64-bit Debian GNU/Linux 64-bit distribution as guest OS under Windows 10 host. I compile and test C-C TB within this guest linux OS, and the environment works just fine.
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.
Many different testcases which should reproduce the same vulnerability.
FWIW, Thunderbird 38 is irrelevant as that's obsolete at this point. We already released 45 ESR, and the 38 series won't get any more updates.
When I looked into how I should begin repro'ing issues I found in libical, I looked at the commits to libical in Thunderbird between the version available in Ubuntu and the latest snapshot. The number of commits to libical in the timeframe (only a handful that I could see) gave me the impression that libical in ESR 38 was essentially the same as libical in the current version. If anyone disagrees with this, however, I am willing to reconsider.
How exactly should an ASan build be performed on a source release tarball? I have found documentation I have tried every possible way I can think of, but I cannot actually compile Thunderbird+Calendar with ASan. In some parts, LDFLAGS does not seem to be respected at all, which causes a library compilation to succeed, but the linking to fail. I have tried by using the client.mk Makefile directly, by specifying the environment variables. Fails as described above. I have tried directly modifying the moz.build files for the libraries I intend on compiling with ASan support. Again, LDFLAGS even specified in moz.build files seem to not be respected everywhere. I have tried using the mozconfig approach, the following mozconfig and many permutations of it which all fail in slightly different areas due to linking failing to find the __asan methods. export CC=clang export CXX=clang++ ac_add_options --disable-gstreamer ac_add_options --enable-application=mail ac_add_options --enable-calendar ac_add_options --enable-jemalloc ac_add_options --enable-replace-malloc ac_add_options --with-system-harfbuzz ac_add_options --disable-glibtest ac_add_options --disable-gtktest ac_add_options --disable-tests ac_add_options --disable-freetypetest ac_add_options --disable-crypto ac_add_options --disable-webrtc ac_add_options --disable-webspeech ac_add_options --disable-webspeechtestbackend ac_add_options --disable-directshow ac_add_options --disable-wmf ac_add_options --disable-ffmpeg ac_add_options --disable-fmp4 ac_add_options --disable-wave ac_add_options --enable-address-sanitizer ac_add_options --disable-crashreporter I am at a complete loss as to how to get a better, more relevant stack trace (or to disprove my suspicion that Thunderbird is vulnerable). Any thoughts are appreciated. I am testing with Clang 3.6 for what that's worth. I have downloaded and also been working with the latest Thunderbird 45.1.1 release tarball.
Hi, I could create C-C TB with the following approach. Define -fsanitize=address in your environmental variables: CFLAGS and CXXFLAGS. GCC under Debian GNU/Linux. ... snip from my shell script ... ASAN=-fsanitize=address # ASAN= # # # # # -fPIC -mcmodel=large caused cpuid() asm definition in # mozilla/media/libvpx/vpx_ports/x86.h to blow up. # # see the discussion in https://gcc.gnu.org/ml/gcc-patches/2012-12/msg01484.html # But I don't understand the GCC in-line asm of late. # MEMORYMODEL="-fPIC -mcmodel=large" MEMORYMODEL="-mcmodel=large" MEMORYMODEL= export CFLAGS="$CFLAGS $MEMORYMODEL $ASAN -fno-builtin-strlen $SPLITDWARF -Dfdatasync=fdatasync -DDEBUG_4GB_CHECK -DUSEHELGRIND=1" export CXXFLAGS="$CXXFLAGS $MEMORYMODEL $ASAN -fno-builtin-strlen $SPLITDWARF -Dfdatasync=fdatasync -DDEBUG_4GB_CHECK -DUSEHELGRIND=1" export CC="/usr/bin/gcc-6" export CXX="/usr/bin/g++-6" before invokcing make -f client.mk Possibly redundant but I also define -fsanitaize=address again in mozconfig for ASAN build: -dl for LDFLAGS was necessary to link ASAN with GCC. -fno-delete-null-pointer-checks is necessary for GCC6 with C-C TB. # # Mandatory flags for ASan export ASANFLAGS="-fsanitize=address -Dxmalloc=myxmalloc -fPIC" export CFLAGS="$ASANFLAGS $CFLAGS -fno-delete-null-pointer-checks" export CXXFLAGS="$ASANFLAGS $CXXFLAGS -fno-delete-null-pointer-checks" export LDFLAGS="-fsanitize=address -ldl" # Enable ASan specific code and build workarounds ac_add_options --enable-address-sanitizer # Mandatory options required for ASan builds (both on Linux and Mac) export MOZ_DEBUG_SYMBOLS=1 # ac_add_options --enable-debug-symbols # already defined with -gsplit-dwarf ac_add_options --disable-install-strip ac_add_options --disable-jemalloc ac_add_options --disable-crashreporter ac_add_options --disable-elf-hack # Avoid dependency on libstdc++ 4.7 # ac_add_options --enable-stdcxx-compat ... Some --disable-* are from the instruction for FF build with ASAN. Hope this helps.
You don't have to disable gmp-plugin, gmp-plugin-openh264 from the mozilla/dom/media/moz.build? With those exact settings on ESR38, ESR45, and latest comm-central, I have to manually edit out the gmp-plugin and gmp-plugin-openh264 in the moz.build. They fail to build when asan is enabled. I also have to edit the ldap/moz.build to not build the c-sdk because this also fails to build with asan. Once those are edited out, libnspr4.so fails to build with asan: 1:07.11 ../../../build/unix/gold/ld: error: read-only segment has dynamic relocations Here is the mozconfig I am using. export CC=clang-3.6 export CXX=clang++-3.6 export ASANFLAGS="-fsanitize=address -Dxmalloc=myxmalloc -fPIC" export CFLAGS="$ASANFLAGS $CFLAGS -fno-delete-null-pointer-checks" export CXXFLAGS="$ASANFLAGS $CXXFLAGS -fno-delete-null-pointer-checks" export LDFLAGS="-fsanitize=address -ldl" export MOZ_DEBUG_SYMBOLS=1 ac_add_options --enable-application=mail ac_add_options --enable-calendar ac_add_options --disable-jemalloc ac_add_options --disable-install-strip ac_add_options --disable-tests ac_add_options --disable-webrtc ac_add_options --disable-webspeech ac_add_options --disable-webspeechtestbackend ac_add_options --disable-directshow ac_add_options --disable-wmf ac_add_options --disable-ffmpeg ac_add_options --disable-fmp4 ac_add_options --disable-elf-hack ac_add_options --enable-address-sanitizer ac_add_options --disable-crashreporter I also exported your CXXFLAGS and CFLAGS that you mentioned. I am assuming C-C Thunderbird is comm-central? Are you building a particular branch? What is the current hg commit that these build instructions work for you?
(In reply to Brandon Perry from comment #22) > You don't have to disable gmp-plugin, gmp-plugin-openh264 from the > mozilla/dom/media/moz.build? > > With those exact settings on ESR38, ESR45, and latest comm-central, I have > to manually edit out the gmp-plugin and gmp-plugin-openh264 in the > moz.build. They fail to build when asan is enabled. > > I also have to edit the ldap/moz.build to not build the c-sdk because this > also fails to build with asan. > > Once those are edited out, libnspr4.so fails to build with asan: > > 1:07.11 ../../../build/unix/gold/ld: error: read-only segment has dynamic > relocations > > > Here is the mozconfig I am using. > > export CC=clang-3.6 > export CXX=clang++-3.6 > export ASANFLAGS="-fsanitize=address -Dxmalloc=myxmalloc -fPIC" > export CFLAGS="$ASANFLAGS $CFLAGS -fno-delete-null-pointer-checks" > export CXXFLAGS="$ASANFLAGS $CXXFLAGS -fno-delete-null-pointer-checks" > export LDFLAGS="-fsanitize=address -ldl" > export MOZ_DEBUG_SYMBOLS=1 > > ac_add_options --enable-application=mail > ac_add_options --enable-calendar > ac_add_options --disable-jemalloc > ac_add_options --disable-install-strip > ac_add_options --disable-tests > ac_add_options --disable-webrtc > ac_add_options --disable-webspeech > ac_add_options --disable-webspeechtestbackend > ac_add_options --disable-directshow > ac_add_options --disable-wmf > ac_add_options --disable-ffmpeg > ac_add_options --disable-fmp4 > ac_add_options --disable-elf-hack > ac_add_options --enable-address-sanitizer > ac_add_options --disable-crashreporter > > > I also exported your CXXFLAGS and CFLAGS that you mentioned. > > I am assuming C-C Thunderbird is comm-central? Are you building a particular > branch? What is the current hg commit that these build instructions work for > you? From the last question first: C-C thunderbird means comm-central. I never had to tweak moz.config (I *THINK*) directly. I have no idea what gmp-plugin, gmp-plugin-openh264 are. Here is the output from grep -v "^#" mozconfig-tb3-asan on my PC where I could compile and build ASAN version of C-C TB. export MOZ_DEBUG_SYMBOLS=1 mk_add_options AUTOCLOBBER=1 mk_add_options MOZ_OBJDIR=/WWW-DIR/ASAN-OBJ-DIR/objdir-tb3 mk_add_options MOZ_CO_PROJECT=mail ac_add_options --enable-application=mail ac_add_options --enable-debug-symbols=-gsplit-dwarf ac_add_options --disable-necko-wifi ac_add_options --enable-tests ac_add_options --enable-debug ac_add_options --enable-official-branding ac_add_options --disable-libjpeg-turbo ac_add_options --disable-necko-wifi ac_add_options --enable-valgrind ac_add_options --enable-optimize="-g -Og -fsanitize=address -fno-omit-frame-pointer -freorder-blocks " ac_add_options --disable-jemalloc mk_add_options BUILD_OFFICIAL=1 mk_add_options MOZILLA_OFFICIAL=1 mk_add_options BUILD_MODULES=all mk_add_options MOZ_MAKE_FLAGS="-j1" mk_add_options MOZ_MAKE_FLAGS="-s" ac_add_options --with-ccache=/usr/bin/ccache ac_add_options --enable-profiling ac_cv_visibility_pragma=no export ASANFLAGS="-fsanitize=address -Dxmalloc=myxmalloc -fPIC" export CFLAGS="$ASANFLAGS $CFLAGS -fno-delete-null-pointer-checks" export CXXFLAGS="$ASANFLAGS $CXXFLAGS -fno-delete-null-pointer-checks" export LDFLAGS="-fsanitize=address -ldl" ac_add_options --enable-address-sanitizer export MOZ_DEBUG_SYMBOLS=1 ac_add_options --disable-install-strip ac_add_options --disable-jemalloc ac_add_options --disable-crashreporter ac_add_options --disable-elf-hack That said, what linker are you using? I would suggest try GNU gold linker from binutils. Mine is ld --version GNU gold (GNU Binutils for Debian 2.26) 1.11 ... Under debian, it is /usr/bin/ld.gold (which is a link to architecture specific binary). (I would not recommend ac_add_options --enable-debug-symbols=-gsplit-dwarf in my mozconfig-tb3 unless you are using gnu gold linker.) Basically, with the above mozconifg I run make -f client.mk configure; make -f client.mk (The above is hanlded in my locally crafted shell script.) Hope this helps.
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-5825 to this one https://lists.debian.org/debian-lts/2016/08/msg00192.html
Severity: major → critical
Status: UNCONFIRMED → NEW
Ever confirmed: true
You need to log in before you can comment on or make changes to this bug.