pushed in updates_testing :

src.rpm:
        libgxps-0.2.5-1.1.mga6
        libgxps-0.2.5-1.1.mga5

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

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

Updated libgxps packages fix security vulnerability:

There is a NULL pointer dereference in the caseless_hash function in
gxps-archive.c in libgxps 0.2.5. A crafted input will lead to a denial of
service attack (CVE-2017-11590).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11590
https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/4UCPAG32F7QVCTWKIO5S7U5CKIZQEYJY/
========================

Updated packages in core/updates_testing:
========================
libgxps2-0.2.5-1.1.mga5
libgxps-tools-0.2.5-1.1.mga5
libgxps-gir0.1-0.2.5-1.1.mga5
libgxps-devel-0.2.5-1.1.mga5
libgxps2-0.2.5-1.1.mga6
libgxps-tools-0.2.5-1.1.mga6
libgxps-gir0.1-0.2.5-1.1.mga6
libgxps-devel-0.2.5-1.1.mga6

from SRPMS:
libgxps-0.2.5-1.1.mga5.src.rpm
libgxps-0.2.5-1.1.mga6.src.rpm

Version: Cauldron => 6
Whiteboard: MGA6TOO, MGA5TOO => MGA5TOO

MGA5-32 on Asus A6000VM Xfce
No installation issues.
Library supposed to handle XPS files. In whatrequires I find atril, but opening an XPS file in atril works OK, but the trace has no calls to the library.

CC: (none) => herman.viaene

Trying this out on mga5::x86_64 before the updates.

Found a sample XPS file on github which displayed in atril and evince, both of which register in the whatrequires list.  However, when run they show no sign of interacting with the gxps libraries, as Herman found.

However, the xps tools in /bin do access the gxps library.  The names are self-explanatory and in the simplest case, each is run like this:
$ <xpstool> <xps-file> <output-file>

$ strace xpstopdf sample1.xps sample1-1.pdf 2> trace
$ cat trace | grep gxps
open("/lib64/libgxps.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib64/libgxps.so.2.1.1", O_RDONLY) = 3
stat("/home/lcl/qa/gxps", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
open("/home/lcl/qa/gxps/sample1.xps", O_RDONLY) = 6
....................
The pdf file matches the original sample.

The tools are:
xpstojpeg*  xpstopdf*  xpstopng*  xpstops*  xpstosvg*

Each converts the sample file to the relevant format which is true to the original.  Use gs to view the sample1.ps file.
$ ls
sample1-1.pdf      sample1.pdf        sample1.ps   sample1.xps
sample1.jpg-1.jpg  sample1.png-1.png  sample1.svg  trace

Note the quirks for png and jpeg images.

There is a PoC for CVE-2017-11590.  Downloads as a rar file.  Investigating that later.

CC: (none) => tarazed25

Created attachment 9642 [details]
Sample XPS file containing graphics elements

The PoC file looks like a TIFF file with four stacked frames and it is meant to be run against software compiled and linked with ASAN so it is probably not of much use to QA.  Might as well try it though.

$ identify POC1
POC1[0] TIFF 32x32 32x32+0+0 4-bit Grayscale Gray 5.36KB 0.000u 0:00.009
POC1[1] TIFF 32x32 32x32+0+0 4-bit Grayscale Gray 5.36KB 0.000u 0:00.000
POC1[2] TIFF 4096x544 4096x544+0+0 4-bit Grayscale Gray 5.36KB 0.000u 0:00.000
POC1[3] TIFF 4096x544 4096x544+0+0 4-bit Grayscale Gray 5.36KB 0.000u 0:00.000
identify: Unknown field with tag 302 (0x12e) encountered. `TIFFReadDirectory' @ warning/tiff.c/TIFFWarnings/896.
identify: Unknown field with tag 61961 (0xf209) encountered. `TIFFReadDirectory' @ warning/tiff.c/TIFFWarnings/896.
identify: Invalid TIFF directory; tags are not sorted in ascending order. `TIFFReadDirectoryCheckOrder' @ warning/tiff.c/TIFFWarnings/896.
identify: Unknown field with tag 5054 (0x13be) encountered. `TIFFReadDirectory' ..................................................
$ xpstojpeg POC1 > /dev/null
Error creating XPS file: Source _rels/.rels not found in archive

Updated from Core Updates Testing.  Note that the tools package is libgxps-tools on 64-bit systems.

As expected, the PoC test returned the same result as before.  Not useful.
Removed the earlier sample conversions and ran the tests again without specifying an output file.
$ ls
page-1.jpg  POC1      sample1.pdf  sample1.svg  trace
page-1.png  POC1.rar  sample1.ps   sample1.xps

Used display, xpdf and gs as appropriate and all the output files looked fine.

Good for 64-bits.

Testing this on mga6::x86_64

Skipping the PoC file test.
Installed the four update packages.
Exercized the xps tools against the sample XPS file without specifying an output file.
$ ls
page-1.jpg  page-1.png  sample1.pdf  sample1.ps  sample1.svg  sample1.xps

The output files all resembled the sample file when viewed with xpdf, display or gs.

Passing this for 64-bits.

Super work yet again, Len.
Advisoried; & validating as it has a 64-bit OK for M5 and M6 - good under present rules.

Whiteboard: MGA5TOO MGA5-64-OK MGA6-64-OK => MGA5TOO MGA5-64-OK MGA6-64-OK advisory
Keywords: (none) => validated_update
CC: (none) => lewyssmith, sysadmin-bugs

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

http://advisories.mageia.org/MGASA-2017-0318.html

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