| Summary: | libxpm new security issue CVE-2016-10164 | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | David Walser <luigiwalser> |
| Component: | Security | Assignee: | QA Team <qa-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | Sec team <security> |
| Severity: | normal | ||
| Priority: | Normal | CC: | lewyssmith, sysadmin-bugs, tarazed25 |
| Version: | 5 | Keywords: | validated_update |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://lwn.net/Vulnerabilities/712803/ | ||
| Whiteboard: | has_procedure MGA5-64-OK MGA5-32-OK advisory | ||
| Source RPM: | libxpm-3.5.11-4.mga5.src.rpm | CVE: | |
| Status comment: | |||
| Attachments: | Test script for CVE-2016-10164 to be run against large XPM file | ||
|
Description
David Walser
2017-01-25 12:11:29 CET
Debian has issued an advisory for this on January 26: https://www.debian.org/security/2017/dsa-3772
David Walser
2017-01-27 22:18:44 CET
URL:
(none) =>
https://lwn.net/Vulnerabilities/712803/ 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.
Len Lawrence
2017-01-31 00:30:09 CET
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?
Len Lawrence
2017-02-01 00:42:53 CET
Whiteboard:
has_procedure MGA5-64-OK =>
has_procedure MGA5-64-OK MGA5-32-OK @Len: champion work. Validatied & advisoried. CC:
(none) =>
lewyssmith, sysadmin-bugs An update for this issue has been pushed to the Mageia Updates repository. http://advisories.mageia.org/MGASA-2017-0035.html Status:
NEW =>
RESOLVED |