Bug 20706 - icu new security issues CVE-2017-7867 and CVE-2017-7868
Summary: icu new security issues CVE-2017-7867 and CVE-2017-7868
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 5
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
Whiteboard: MGA5-32-OK MGA5-64-OK advisory
Keywords: validated_update
Depends on:
Reported: 2017-04-20 04:13 CEST by David Walser
Modified: 2017-04-24 09:28 CEST (History)
5 users (show)

See Also:
Source RPM: icu-53.1-12.6.mga5.src.rpm
Status comment:


Description David Walser 2017-04-20 04:13:55 CEST
Debian has issued an advisory today (April 19):

They referenced an upstream commit in the Debian bug:

Debian's backported patch will probably work for us for Mageia 5.
Comment 1 Marja Van Waes 2017-04-20 09:35:01 CEST
Assigning to the registered maintainer.

Assignee: bugsquad => shlomif
CC: (none) => marja11

Comment 2 Nicolas Lécureuil 2017-04-21 22:27:04 CEST
pushed in updates_testing:

src.rpm: icu-53.1-12.7.mga5

Assignee: shlomif => qa-bugs
CC: (none) => mageia

Comment 3 David Walser 2017-04-22 03:18:56 CEST

Updated icu packages fix security vulnerabilities:

It was discovered that icu did not correctly validate its input. An attacker
could use this problem to trigger an out-of-bound write through a heap-based
buffer overflow, thus causing a denial of service via application crash, or
potential execution of arbitrary code (CVE-2017-7867, CVE-2017-7868).


Updated packages in core/updates_testing:

from icu-53.1-12.7.mga5.src.rpm
Comment 4 Len Lawrence 2017-04-22 11:12:53 CEST
Looking at this some time this weekend.  Checked that all the various utilities are installed.

CC: (none) => tarazed25

Comment 5 Len Lawrence 2017-04-22 21:22:30 CEST
Testing on x86_64 real hardware.  
Checked out a few things before the update.

icu is basically a set of library tools for UNICODE conversions and handling and is mostly of interest to programmers.  What you get is outlined at http://www.linuxfromscratch.org/blfs/view/8.0/general/icu.html; a set of utilities in /usr/bin, C/C++ header files in /usr/include and a number of files in /usr/share.  The only utility missing seems to be icu-config.

There is a way to reproduce the bug, not really accessible to us, involving address sanitizer and a "fuzztesting" framework.  The data file can be downloaded but how to use it?  All we can do is see that conversions work.

$ icuinfo 
 <icuSystemParams type="icu4c">
    <param name="copyright"> Copyright (C) 2014, International Business Machines Corporation and others. All Rights Reserved. </param>
    <param name="product">icu4c</param>
ICU Initialization returned: U_ZERO_ERROR
Plugin file is: /usr/lib64/icu/icuplugins53.txt

$ uconv --list
UTF-8 ibm-1208 ibm-1209 ibm-5304 ibm-5305 ibm-13496 ibm-13497 ibm-17592 ibm-17593 windows-65001 cp1208 x-UTF_8J unicode-1-1-utf-8 unicode-2-0-utf-8 
UTF-16 ISO-10646-UCS-2 ibm-1204 ibm-1205 unicode csUnicode ucs-2 

$ uconv --default-code

Used uconv to generate two SJIS encoded files from originals encoded with the default UTF-8.  jabberwocky is normal ASCII text, part2 contains a special unicode character for Greek pi which is not part of SJIS.

$ uconv -f UTF-8 -t SJIS -o sjis.txt jabberwocky
$ uconv -f UTF-8 -t SJIS -o part3 part2

The following ruby snippet demonstrates the conversions.  For normal ASCII text the encodings are transparent.

#!/bin/env ruby
# encoding: utf-8

PI = "\u03c0"*3
pi = "π"
puts PI, pi
# π
# π
a = File.read "jabberwocky"
puts a
# Output is "Twas brillig ....."
puts __ENCODING__
# UTF-8
c = File.read "part2"
puts c
# π = 3.14159 or thereabouts
d = File.read "part3"
puts d
# �� = 3.14159 or thereabouts
b = File.read "sjis.txt"
puts b
# Twas brillig ......
# Open the pi file encoded as SJIS 
e = File.open( "part3", "r:sjis" )
puts e.gets
# �� = 3.14159 or thereabouts
# This last check simply emphasizes the correctness of the uconv conversion.
# Open the pi file encoded as SJIS and enable internal conversion to UTF-8
f = File.open( "part3", "r:sjis:utf-8" )
puts f.gets
# π = 3.14159 or thereabouts

Updates not available just now - will get back to this.
Comment 6 Len Lawrence 2017-04-23 02:05:35 CEST
i586 in virtualbox.
Updates available so updated all the packages and ran the simple tests detailed in comment 5 then ran the ruby script against the various files to check the encodings.

$ ./testencoding.rb
--- Original UTF-8 text ---
Twas brillig and the slithy toves
Did gyre and gimble in the wabe.
All mimsy were the borogoves
And the mome raths outgrabe.
--- Original UTF-8 pi file ---
Part the second:
π = 3.14159 or thereabouts

--- File encoded as SJIS ---
Part the second:
�� = 3.14159 or thereabouts
--- UTF-8 text encoded as SJIS ---
Twas brillig and the slithy toves
Did gyre and gimble in the wabe.
All mimsy were the borogoves
And the mome raths outgrabe.
--- pi file encoded as SJIS ---
Part the second:
�� = 3.14159 or thereabouts
--- pi file encoded as SJIS converted to UTF-8 by ruby ---
Part the second:
π = 3.14159 or thereabouts
OK for 32-bits.
Len Lawrence 2017-04-23 02:06:04 CEST

Whiteboard: (none) => MGA5-32-OK

Comment 7 Len Lawrence 2017-04-23 02:07:53 CEST
uconv run with strace shows the library searches.

$ strace uconv -f UTF-8 -t ISO-8859-1 -o part4 part3 >& trace
$ cat trace | grep libicu
open("/usr/lib64/tls/x86_64/libicui18n.so.53", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib64/tls/libicui18n.so.53", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib64/x86_64/libicui18n.so.53", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib64/libicui18n.so.53", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib64/libicuuc.so.53", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib64/libicudata.so.53", O_RDONLY|O_CLOEXEC) = 3

read(4, "Part the second:\n\203\316 = 3.14159 or"..., 4096) = 45
write(2, "Conversion to Unicode from codep"..., 111Conversion to Unicode from codepage failed at input byte position 17. Bytes: 83 Error: Illegal character found
) = 111

--> π cannot be handled by ISO-8859-1.
 Shall run these simple tests again when the updates arrive.  Meanwhile 32-bits....
Comment 8 Len Lawrence 2017-04-23 02:18:55 CEST
X86_64 after updates (forgot to enable updates testing after a complete reconfiguration of this machine).

Used the previous files with the encoded versions as well and ran the same tests as in comment 5.  Identical results.

Passing this for 64-bits.
Len Lawrence 2017-04-23 02:20:37 CEST

Whiteboard: MGA5-32-OK => MGA5-32-OK MGA5-64-OK

Comment 9 Dave Hodgins 2017-04-24 02:45:32 CEST
Advisory added to svn. Validating the update based on Len's testing.

Whiteboard: MGA5-32-OK MGA5-64-OK => MGA5-32-OK MGA5-64-OK advisory
Keywords: (none) => validated_update
CC: (none) => davidwhodgins, sysadmin-bugs

Comment 10 Mageia Robot 2017-04-24 09:28:09 CEST
An update for this issue has been pushed to the Mageia Updates repository.


Resolution: (none) => FIXED

Note You need to log in before you can comment on or make changes to this bug.