A CVE has been assigned for a security issue fixed in libXpm 3.5.12: http://openwall.com/lists/oss-security/2017/01/25/7 Updated package uploaded for Mageia 5. PoC in the CVE request: http://openwall.com/lists/oss-security/2017/01/22/2 Advisory: ======================== Updated libxpm packages fix security vulnerability: An out of boundary write has been found in libXpm before 3.5.12 which can be exploited by an attacker through maliciously crafted XPM files. To trigger the vulnerability, a program must explicitly request to also parse XPM extensions while reading files. The motif toolkit and xdm are two among some programs that set the flag (XpmReturnExtensions). It can only be exploited on 64-bit systems (CVE-2016-10164). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-10164 http://openwall.com/lists/oss-security/2017/01/25/7 ======================== Updated packages in core/updates_testing: ======================== libxpm4-3.5.12-1.mga5 libxpm-devel-3.5.12-1.mga5 from libxpm-3.5.12-1.mga5.src.rpm
Debian has issued an advisory for this on January 26: https://www.debian.org/security/2017/dsa-3772
URL: (none) => https://lwn.net/Vulnerabilities/712803/
x86_64 later today.
CC: (none) => tarazed25
Hit a snag with this. Compiled the poc C file extracted from the openwall.com reference but the message does not provide a link to the test XPM file - the browser says "contents skipped".
Tried a Google search and found the attachment. More trouble trying to unzip it.
The test file has to be gunzipped twice to generate a 4GB file whcih can be renamed to poc.xpm. The command $ gcc -o poc -L /usr/lib64 -lX11 -lXpm poc.c compiles and links the C file as the executable poc. $ ./poc /usr/share/xmorph/pixmaps/pencil.xpm returned immediately. $ ./poc defaults to reading poc.xpm and eventually segfaults. The packages have not yet arrived on whatever mirror I used, so off to do a search.
Used http://seclists.org/oss-sec/2017/q1/167 to obtain the gzipped xpm. Updated lib64xpm4 and lib64xpm-devel and recompiled poc.c. $ ./poc /usr/share/xmorph/pixmaps/eraser.xpm $ ./poc poc: failed to create data: Resource temporarily unavailable No segfault but the program appeared to examine the whole file judging by the time it took. This can be pushed once the 32-bit vbox test is effected.
Whiteboard: (none) => has_procedure MGA5-64-OK
Created attachment 8910 [details] Test script for CVE-2016-10164 to be run against large XPM file $ gcc -o poc -L /usr/lib64 -lX11 -lXpm poc.c $ ./poc anyold.xpm A normal file produces no output but for the exploit file and using the patched library a failure message is returned. It is sufficient to run $ ./poc although $ ./poc poc.xpm should also work. poc.xpm weighs in at over 4 GB so has to be downloaded and gunzipped twice. Compressed file linked at http://seclists.org/oss-sec/2017/q1/167
i586 in virtualbox $ gcc -o poc -L /usr/lib -lX11 -lXpm poc.c ./poc worked fine with a system xmp icon file but returned "poc: failed to parse image: No such file or directory" for the test file. Checked the first few lines: /* XPM */ static char * xterm_32x32_xpm[] = { "1 1 1 1 XPMEXT", " c #000000", " ", "XPMEXT abc", "BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB /usr/share/xmorph/pixmaps/hand01.xpm looks like this /* XPM */ static char * hand01_xpm[] = { "16 16 4 1", " c None", ". c #8E085E", "+ c #B18A8A", "@ c #B98B8B", " ", " ... ", " ...+... ", " .@.@.@.. ", " .@.@.@.@. ", " .@.@.@.@. ", " .@.@.@.@. ", " ...@.@.@.@. ", " .@.@@@@@.@. ", " .@.@@@@@@@. ", " .@.@@@@@@@. ", " .@@@@@@@@@. ", " .@@@@@@@@@. ", " .@@@@@@@@. ", " .@@@@@@. ", " ........ "}; so I do not see what poc objects to in poc.xpm unless this is expected behaviour. It certainly differs from the x86_64 test, which was on real hardware (!).
An strace reveals that the code is looking for lib64 libraries, so maybe there is something wrong with my compile statement.
Specifically, from the strace: execve("./poc", ["./poc", "poc.xpm"], [/* 72 vars */]) = 0 brk(0) = 0x8ff5000 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb76ed000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/usr/lib64/tls/i686/sse2/libX11.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/lib64/tls/i686/sse2", 0xbff58800) = -1 ENOENT (No such file or directory) ..............
$ ls -l /usr/lib/libX11.so lrwxrwxrwx 1 root root 15 Sep 23 2015 /usr/lib/libX11.so -> libX11.so.6.3.0*
No, I am wittering here. The program searches all possible paths for the library and does find it. open("/usr/lib/libX11.so.6", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000D\1\0004\0\0\0"..., 512) = 512 ................. open("poc.xpm", O_RDONLY) = -1 EOVERFLOW (Value too large for defined data type) open("poc.xpm.Z", O_RDONLY) = -1 ENOENT (No such file or directory) open("poc.xpm.gz", O_RDONLY) = -1 ENOENT (No such file or directory) write(2, "poc: ", 5poc: ) = 5 write(2, "failed to parse image", 21failed to parse image) = 21 write(2, ": ", 2: ) = 2 write(2, "No such file or directory\n", 26No such file or directory ) = 26 exit_group(1) = ? But - quoting the advisory: The motif toolkit and xdm are two among some programs that set the flag (XpmReturnExtensions). It can only be exploited on 64-bit systems (CVE-2016-10164). This means that the update does not need a 32-bit test?
Whiteboard: has_procedure MGA5-64-OK => has_procedure MGA5-64-OK MGA5-32-OK
@Len: champion work. Validatied & advisoried.
CC: (none) => lewyssmith, sysadmin-bugsWhiteboard: has_procedure MGA5-64-OK MGA5-32-OK => has_procedure MGA5-64-OK MGA5-32-OK advisoryKeywords: (none) => validated_update
An update for this issue has been pushed to the Mageia Updates repository. http://advisories.mageia.org/MGASA-2017-0035.html
Status: NEW => RESOLVEDResolution: (none) => FIXED