Security issues fixed upstream in icu have been announced today (May 5): http://openwall.com/lists/oss-security/2015/05/05/6 The issues are fixed in 55.1. The fix for CVE-2014-8146 is here: http://bugs.icu-project.org/trac/changeset/37162/ The fix for CVE-2014-8147 is here: http://bugs.icu-project.org/trac/changeset/37080/ I also found a fix for an unrelated integer overflow issue here: http://bugs.icu-project.org/trac/changeset/37217/ Patches checked into Mageia 4 and Cauldron SVN. Freeze push requested. Reproducible: Steps to Reproduce:
Blocks: (none) => 14674Whiteboard: (none) => MGA5TOO, MGA4TOO
Patched packages uploaded for Mageia 4 and Cauldron. The first reference linked at the bottom of the page below is a 7zip file with PoC XLS files that you can open with oocalc (you can use ark to extract the 7zip file): https://raw.githubusercontent.com/pedrib/PoC/master/generic/i-c-u-fail.txt Advisory: ======================== Updated icu packages fix security vulnerabilities: The ICU Project's ICU4C library, before 55.1, contains a heap-based buffer overflow in the resolveImplicitLevels function of ubidi.c (CVE-2014-8146). The ICU Project's ICU4C library, before 55.1, contains an integer overflow in the resolveImplicitLevels function of ubidi.c due to the assignment of an int32 value to an int16 type (CVE-2014-8147). Both issues may lead to denial of service and the possibility of code execution. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-8146 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-8147 https://www.kb.cert.org/vuls/id/602540 ======================== Updated packages in core/updates_testing: ======================== icu-52.1-2.3.mga4 icu-data-52.1-2.3.mga4 icu-doc-52.1-2.3.mga4 libicu52-52.1-2.3.mga4 libicu-devel-52.1-2.3.mga4 from icu-52.1-2.3.mga4.src.rpm
Version: Cauldron => 4Blocks: 14674 => (none)Assignee: bugsquad => qa-bugsWhiteboard: MGA5TOO, MGA4TOO => has_procedure
I can confirm the crashes before the update. After the update, fuzzed-18-95-602621340.xls (CVE-2014-8147) no longer crashes. After the update, fuzzed-168-7-542405652.xls (CVE-2014-8146) still crashes :o(
Pedro Ribeiro, who reported these issues, told me he'd look into what I said about CVE-2014-8146 when he gets a chance, hopefully in the next couple weeks. I'll put this bug on feedback hold for now.
Whiteboard: has_procedure => has_procedure feedback
Ubuntu has issued an advisory for this today (May 11): http://www.ubuntu.com/usn/usn-2605-1/
URL: (none) => http://lwn.net/Vulnerabilities/643925/
I e-mailed Marc Deslauriers who did the Ubuntu update, and he pointed out that the crash post-patching is different. I double checked it and confirmed this. On my main workstation at work with the patches applied, I get this at the top of the stack trace: *** Error in `/usr/lib/libreoffice/program/soffice.bin': munmap_chunk(): invalid pointer: 0x09ce0a20 *** ======= Backtrace: ========= /lib/i686/libc.so.6(+0x6b053)[0xb757c053] /lib/i686/libc.so.6(+0x717aa)[0xb75827aa] /lib/i686/libc.so.6(+0x17e46)[0xb7528e46] /lib/libicuuc.so.52(uprv_free+0x48)[0xb5952178] /lib/libicuuc.so.52(ubidi_close+0x2d)[0xb59ccbfd] In a VM without the patches applied yet I get: *** Error in `/usr/lib/libreoffice/program/soffice.bin': munmap_chunk(): invalid pointer: 0x09ce0a20 *** ======= Backtrace: ========= /lib/i686/libc.so.6(+0x6b053)[0xb757c053] /lib/i686/libc.so.6(+0x717aa)[0xb75827aa] /lib/i686/libc.so.6(+0x17e46)[0xb7528e46] /lib/libicuuc.so.52(uprv_free+0x48)[0xb5952178] /lib/libicuuc.so.52(ubidi_close+0x2d)[0xb59ccbfd] So it went from a double free to an invalid pointer. Marking this OK for Mageia 4 i586 then. Please check x86_64. Thanks.
Whiteboard: has_procedure feedback => has_procedure MGA4-32-OK
Severity: normal => major
Copy-paste error. Trying again. On my main workstation at work with the patches applied, I get this at the top of the stack trace: *** Error in `/usr/lib/libreoffice/program/soffice.bin': munmap_chunk(): invalid pointer: 0x0982bbc0 *** ======= Backtrace: ========= /lib/i686/libc.so.6(+0x6b053)[0xb751f053] /lib/i686/libc.so.6(+0x717aa)[0xb75257aa] /lib/i686/libc.so.6(+0x17e46)[0xb74cbe46] /lib/libicuuc.so.52(uprv_free+0x48)[0xb58f5178] /lib/libicuuc.so.52(ubidi_close+0x2d)[0xb596fbfd] In a VM without the patches applied yet I get: *** Error in `/usr/lib/libreoffice/program/soffice.bin': double free or corruption (!prev): 0x08a8fee8 *** ======= Backtrace: ========= /lib/i686/libc.so.6(+0x6b053)[0xb758b053] /lib/i686/libc.so.6(+0x72954)[0xb7592954] /lib/libicuuc.so.52(uprv_free+0x48)[0xb5961178] /lib/libicuuc.so.52(ubidi_close+0x2d)[0xb59dbbfd]
On 64bit hardware both files crashed LibreOfficce before the update using oocalc. After the update both files resulted in crashes (i.e. the LibreOffice window flashed up and immediately disappeared). No stack dumps on the terminal so I tried strace. strace oocalc fuzzed-168-7-542405652.xls >& 168.txt strace oocalc fuzzed-18-95-602621340.xls >& 18.txt These produced large files of diagnostics but no sign of munmap_chunk or soffice.bin in the text. The operations exited with the lines: munmap(0x7f5c26c63000, 65536) = 0 exit_group(139) = ? +++ exited with 139 +++ munmap(0x7fb9ec048000, 65536) = 0 exit_group(139) = ? +++ exited with 139 +++ In 168.txt there are these lines (output from grep so not contiguous): open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib64/libreoffice/program/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib64/libreoffice/program/../ure-link/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 That is correct, the ure-link points back to ure and the ure/lib directory does not contain libc.so or any link to it. This seems to be unrelated to the bug in question and as I do not see a stack dump maybe this is OK for x86_64?
CC: (none) => tarazed25
Strange that you're not getting stack traces in your terminal. After the update, fuzzed-18-95-602621340.xls actually opened for me, so that one shouldn't be crashing. Pedro asked me to install the debug symbols for ICU (icu-debug or icu-debuginfo in the debug media) and make a backtrace with gdb. Of course, oocalc is a shell script, so I'll have to figure out again how to make that work.
# cd /usr/lib64/libreoffice/program # gdb soffice.bin
Ahh, the soffice script also has a built-in --backtrace option you can use to make a gdb backtrace. It generates a file called gdbtrace.log. oocalc --backtrace fuzzed-168-7-542405652.xls Before running this, I installed icu-debuginfo (from debug/core/updates on the VM and from debug/core/updates_testing on my workstation). VM: Program received signal SIGABRT, Aborted. 0xb7fdf428 in __kernel_vsyscall () #0 0xb7fdf428 in __kernel_vsyscall () #1 0xb7d725e6 in raise () from /lib/i686/libc.so.6 #2 0xb7d73f23 in abort () from /lib/i686/libc.so.6 #3 0xb7db0058 in __libc_message () from /lib/i686/libc.so.6 #4 0xb7db7954 in _int_free () from /lib/i686/libc.so.6 #5 0xb6186178 in uprv_free (buffer=0x8966440) at cmemory.c:127 #6 0xb6200bfd in ubidi_close (pBiDi=0x89662f8) at ubidi.c:243 workstation: Program received signal SIGABRT, Aborted. 0xb7fdf428 in __kernel_vsyscall () #0 0xb7fdf428 in __kernel_vsyscall () #1 0xb7d715e6 in raise () from /lib/i686/libc.so.6 #2 0xb7d72f23 in abort () from /lib/i686/libc.so.6 #3 0xb7daf058 in __libc_message () from /lib/i686/libc.so.6 #4 0xb7db57aa in malloc_printerr () from /lib/i686/libc.so.6 #5 0xb7d5be46 in munmap_chunk.part.3 () from /lib/i686/libc.so.6 #6 0xb6185178 in uprv_free (buffer=0x89ac590) at cmemory.c:127 #7 0xb61ffbfd in ubidi_close (pBiDi=0x89ac430) at ubidi.c:243 So it might really be unfixed. Len, see what you get with both files using the --backtrace option and icu-debuginfo installed.
Having trouble locating icu-debuginfo. Tried enabling Core Updates Testing Debug but no package.
http://mirrors.kernel.org/mageia/distrib/4/i586/media/debug/core/updates_testing/icu-debuginfo-52.1-2.3.mga4.i586.rpm
Got it. Thanks. Later.
Created attachment 6528 [details] Debug backtrace for fuzzed-18... file post-update oocalc --backtrace fuzzed-18-95-602621340.xls Application logo came up and disappeared.
Created attachment 6529 [details] oocalc gdbtrace log for fuzzed-168... file post-update test oocalc --backtrace fuzzed-168-7-542405652.xls Application crashes immediately.
(In reply to Len Lawrence from comment #15) > Created attachment 6529 [details] > oocalc gdbtrace log for fuzzed-168... file > > post-update test > oocalc --backtrace fuzzed-168-7-542405652.xls > Application crashes immediately. Can you try running this one again? It didn't pick up the debuginfo (your other one did). I had the same thing happen the first time I ran it with this file. for the ubidi_getRuns () lines you should see source files and line numbers, like you see in your other one, where it looked like this: Program received signal SIGSEGV, Segmentation fault. ubidi_getRuns (pBiDi=0x1563b10, pErrorCode=0x7fffffff7bf8) at ubidiln.c:693 693 runIndex=getRunFromLogicalIndex(pBiDi, point->pos, pErrorCode); #0 ubidi_getRuns (pBiDi=0x1563b10, pErrorCode=0x7fffffff7bf8) at ubidiln.c:693 #1 0x00007ffff2bbaf19 in ubidi_countRuns (pBiDi=0x1563b10, pErrorCode=0x7fffffff7bf8) at ubidiln.c:357
Created attachment 6530 [details] Repeat debug run for fuzzed-168* log This time the log does contain the expected information.
Thanks Len. Adding feedback marker while waiting for more feedback from Pedro on all of this.
Whiteboard: has_procedure MGA4-32-OK => has_procedure MGA4-32-OK feedback
Why is this marked OK for MGA4-32? The second POC spreadsheet still crashes.
CC: (none) => herman.viaene
You can remove it if you think problem is not fixed everybody have same rights in bugzilla.
CC: (none) => ozkyster
I'd rather David or Len do this, they've been working on this far longer.
I haven't heard back from anyone in a while on this. Since the patches used correspond to the CVEs, maybe we should OK this and consider there to be an incomplete fix or additional issue that would need another CVE later. It would be nice to hear back or see other distro's opinion on this, but I can't find anything.
@Herman I looked at this in x86_64 only as far as I can recall. Will check 32bit some time in the next week, probably in vbox.
@Herman Have just run these tests for i586 in virtualbox and see the same behaviour as you and as David (comment 2). About to remove the OK flag.
Whiteboard: has_procedure MGA4-32-OK feedback => has_procedure feedback
Depends on: (none) => 16478
icu update moved to Bug 16478.
CC: (none) => qa-bugsAssignee: qa-bugs => bugsquad
Fixed in: http://advisories.mageia.org/MGASA-2015-0286.html
Status: NEW => RESOLVEDResolution: (none) => FIXED