Closed Bug 1280832 (CVE-2016-5825) Opened 7 years ago Closed 1 year ago

Heap buffer overread in libical (icalparser_parse_string function)

Categories

(Calendar :: Internal Components, defect)

Product:
Calendar
Component:
Internal Components
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 1553820

People

(Reporter: bperry.volatile, Unassigned)

References

(
URL
)

Details

(Keywords: sec-low)

Attachments

(2 files)

bug1280832.ics
78 bytes, text/calendar
Details
strdup.zip
409.06 KB, application/zip
Details 
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 fa[02]fa 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
Flags: needinfo?(ishikawa)
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 (?)
Flags: needinfo?(ishikawa)
"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.
Flags: sec-bounty?
Attached file bug1280832.ics — 
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.
Attached file strdup.zip — 
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.
Keywords: sec-low
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
Alias: CVE-2016-5825
Group: mail-core-security

(assuming this is still legit)

Severity: major → critical
Status: UNCONFIRMED → NEW
Ever confirmed: true

Possibly fixed by bug 1553820. (Didn't look in detail yet.)

(In reply to Magnus Melin [:mkmelin] from comment #27)

Possibly fixed by bug 1553820. (Didn't look in detail yet.)

And Bug 1281043 ? Heap overread in libical icalparser_parse_string -> icaltime_from_string function

Flags: needinfo?(kaie)
Flags: sec-bounty-hof-
URL: https://lists.debian.org/debian-lts/2...
Flags: needinfo?(kaie)
See Also: → CVE-2016-5827

(In reply to Magnus Melin [:mkmelin] from comment #27)

Possibly fixed by bug 1553820. (Didn't look in detail yet.)

Christian confirmed that, thanks!

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.