Bug 15145

Cauldron is still pending investigation.

Christiaan has uploaded a patched package for Mageia 4:
icu-52.1-2.1.mga4
icu-data-52.1-2.1.mga4
icu-doc-52.1-2.1.mga4
libicu52-52.1-2.1.mga4
libicu-devel-52.1-2.1.mga4

from icu-52.1-2.1.mga4.src.rpm

The RedHat bug for CVE-2014-7940 says the affected code was completely rewritten in ICU 53, which confirms what Christiaan told me earlier.

The RedHat bugs for CVE-2014-7923 and CVE-2014-7926 identify upstream commits, which I have rediffed for 53.1 and applied in Cauldron.
https://bugzilla.redhat.com/show_bug.cgi?id=1185202
https://bugzilla.redhat.com/show_bug.cgi?id=1185205

Thanks Christiaan for your help with this!

Advisory:
========================

Updated icu packages fix security vulnerabilities:

The Regular Expressions package in International Components for Unicode (ICU)
52 before SVN revision 292944 allows remote attackers to cause a denial of
service (memory corruption) or possibly have unspecified other impact via
vectors related to a zero-length quantifier or look-behind expression
(CVE-2014-7923, CVE-2014-7926).

The collator implementation in i18n/ucol.cpp in International Components for
Unicode (ICU) 52 through SVN revision 293126 does not initialize memory for a
data structure, which allows remote attackers to cause a denial of service or
possibly have unspecified other impact via a crafted character sequence
(CVE-2014-7940).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-7923
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-7926
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-7940
http://googlechromereleases.blogspot.com/2015/01/stable-update.html
========================

Updated packages in core/updates_testing:
========================
icu-52.1-2.1.mga4
icu-data-52.1-2.1.mga4
icu-doc-52.1-2.1.mga4
libicu52-52.1-2.1.mga4
libicu-devel-52.1-2.1.mga4

from icu-52.1-2.1.mga4.src.rpm

Whiteboard: MGA4TOO => (none)
Assignee: cjw => qa-bugs
Version: Cauldron => 4
CC: (none) => cjw

ICU is used by LibreOffice, Chromium Browser, Qt4, Webkit, and Thunderbird for Unicode stuff.  Looking at Insert > Special Character in LibreOffice Writer, it looks to me like things are fine with this update.

Firefox in Mageia 4 isn't built against system icu.  This should probably be corrected.  It was fixed in Cauldron in r655459.

As pointed out on oss-security, the upstream patches I added in from the links from the RedHat bugs for the two CVEs only corresponded to the "regex.patch" from Chromium, but the "regex2.patch" corresponds to an additional upstream commit:
http://openwall.com/lists/oss-security/2015/01/28/12

I've now added the additional commit in Cauldron's icu.  A CVE has been requested for this change in the message above.  I'll update the advisory when it has been assigned.

MGA4-64 on HP Probook 6555b.
No installation issues.
Tried Insert > Special Character in LibreOffice Writer, works OK, but shouldn't I see icu appearing in its strace? It does not.

CC: (none) => herman.viaene

(In reply to Herman Viaene from comment #6)
> shouldn't I see icu appearing in its strace? It does not.

No, strace only catches system calls. ltrace is meant for tracing library calls but it never seems to work properly when I try to use it.

I'm guessing you forgot to use the -f option to strace to follow child processes.  The libreoffice commands run a series of scripts before they run the real executable.  Alternatively, you can run "oowriter --strace" as the libreoffice scripts have the option, and it will run it through strace for you, and save it in the current directory as "strace.log"

You should see libicuuc.so.52 being loaded.

Testing complete mga4 32

Used thunderbird.

$ strace -o strace.out thunderbird

$ grep icu strace.out
open("/lib/libicui18n.so.52", O_RDONLY|O_CLOEXEC) = 4
open("/lib/libicuuc.so.52", O_RDONLY|O_CLOEXEC) = 4
open("/lib/libicudata.so.52", O_RDONLY|O_CLOEXEC) = 4
..etc

Everything displays normally.

Whiteboard: (none) => has_procedure mga4-32-ok

Advisory uploaded.

Whiteboard: has_procedure mga4-32-ok => has_procedure advisory mga4-32-ok

Testing complete mga4 64

Validating. Please push to 4 updates

Thanks

Whiteboard: has_procedure advisory mga4-32-ok => has_procedure advisory mga4-32-ok mga4-64-ok
CC: (none) => sysadmin-bugs
Keywords: (none) => validated_update

An update for this issue has been pushed to Mageia Updates repository.

http://advisories.mageia.org/MGASA-2015-0047.html

Status: NEW => RESOLVED
Resolution: (none) => FIXED

(In reply to David Walser from comment #5)
> As pointed out on oss-security, the upstream patches I added in from the
> links from the RedHat bugs for the two CVEs only corresponded to the
> "regex.patch" from Chromium, but the "regex2.patch" corresponds to an
> additional upstream commit:
> http://openwall.com/lists/oss-security/2015/01/28/12
> 
> I've now added the additional commit in Cauldron's icu.  A CVE has been
> requested for this change in the message above.  I'll update the advisory
> when it has been assigned.

CVE-2014-9654 has been assigned:
http://openwall.com/lists/oss-security/2015/02/05/15

I don't have a description for this one yet, but it sounds like a stack overflow.

Debian also lists a CVE-2015-1205, I don't know where that came from:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776719

CVE-2015-1205 seems to be mentioned here: https://marc.info/?l=oss-security&m=142244042307425&w=2

CC: (none) => remi

(In reply to Rémi Verschelde from comment #14)
> CVE-2015-1205 seems to be mentioned here:
> https://marc.info/?l=oss-security&m=142244042307425&w=2

Ahh yes, the original post in that thread.  So I guess it's been separated out as CVE-2014-9654 and the other one isn't relevant to this issue now.

LWN reference for CVE-2014-9654:
http://lwn.net/Vulnerabilities/636939/