Debian and Ubuntu have issued advisories on October 10: https://www.debian.org/security/2017/dsa-3995 https://usn.ubuntu.com/usn/usn-3442-1/ Mageia 5 and Mageia 6 are also affected.
Whiteboard: (none) => MGA6TOO, MGA5TOO
Assigning to all packagers collectively, since there is no registered maintainer for this package.
Assignee: bugsquad => pkg-bugsCC: (none) => marja11
Source RPM: libxfont-1.5.2-1.mga6.src.rpm => libxfont-1.5.2-1.mga6.src.rpm, libxfont2-2.0.1-4.mga6.src.rpmCC: (none) => nicolas.salguero
Suggested advisory: ======================== The updated packages fix security vulnerabilities: In the PatternMatch function in fontfile/fontdir.c in libXfont through 1.5.2 and 2.x before 2.0.2, an attacker with access to an X connection can cause a buffer over-read during pattern matching of fonts, leading to information disclosure or a crash (denial of service). This occurs because '\0' characters are incorrectly skipped in situations involving ? characters. (CVE-2017-13720) In the pcfGetProperties function in bitmap/pcfread.c in libXfont through 1.5.2 and 2.x before 2.0.2, a missing boundary check (for PCF files) could be used by local attackers authenticated to an Xserver for a buffer over-read, for information disclosure or a crash of the X server. (CVE-2017-13722) References: ======================== https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-13720 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-13722 https://www.debian.org/security/2017/dsa-3995 https://usn.ubuntu.com/usn/usn-3442-1/ Updated packages in 5/core/updates_testing: ======================== lib(64)xfont1-1.5.1-1.1.mga5 lib(64)xfont-devel-1.5.1-1.1.mga5 from SRPMS: libxfont-1.5.1-1.1.mga5.src.rpm Updated packages in 6/core/updates_testing: ======================== lib(64)xfont1-1.5.2-1.1.mga6 lib(64)xfont-devel-1.5.2-1.1.mga6 lib(64)xfont2_2-2.0.1-4.1.mga6 lib(64)xfont2-devel-2.0.1-4.1.mga6 from SRPMS: libxfont-1.5.2-1.1.mga6.src.rpm libxfont2-2.0.1-4.1.mga6.src.rpm
Assignee: pkg-bugs => qa-bugsWhiteboard: MGA6TOO, MGA5TOO => MGA5TOOStatus: NEW => ASSIGNEDVersion: Cauldron => 6
I can take this one. Maybe later in the night.
CC: (none) => tarazed25
Running this in mga5 on x86_64. There is a POC which involves compiling the small C file attached and running the executable under valgrind. Run by itself it produces no output. Compile with: $ gcc xtest.c -lxcb -O2 -Wall -o xtest and run this: $ valgrind Xvfb :0 & ./xtest The valgrind report produced here looks very similar to that posted at https://bugzilla.suse.com/show_bug.cgi?id=1054285. There is an "Invalid read of size 1 warning" comment near the head of the listing which should not appear using the updated packages.
Created attachment 9731 [details] Test file for valgrind to demonstrate the CVE-2107-13720 issue
Ran the updates on mga5 and then the same tests. $ gcc -lxcb -O2 -Wall -o xtest xtest.c [lcl@vega fonts]$ ./xtest [lcl@vega fonts]$ valgrind Xvfb :0 & ./xtest [2] 14488 [lcl@vega fonts]$ ==14488== Memcheck, a memory error detector ==14488== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==14488== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info ==14488== Command: Xvfb :0 ==14488== (EE) Fatal server error: (EE) Server is already active for display 0 If this server is no longer running, remove /tmp/.X0-lock and start again. (EE) ==14488== ==14488== HEAP SUMMARY: ==14488== in use at exit: 12,404 bytes in 8 blocks ==14488== total heap usage: 1,065 allocs, 1,057 frees, 139,355,791 bytes allocated ==14488== ==14488== LEAK SUMMARY: ==14488== definitely lost: 0 bytes in 0 blocks ==14488== indirectly lost: 0 bytes in 0 blocks ==14488== possibly lost: 0 bytes in 0 blocks ==14488== still reachable: 12,404 bytes in 8 blocks ==14488== suppressed: 0 bytes in 0 blocks ==14488== Rerun with --leak-check=full to see details of leaked memory ==14488== ==14488== For counts of detected and suppressed errors, rerun with: -v ==14488== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Not too sure but this is probably OK.
mga6::x86_64 The POC test could not be run in mga6, at least not with valgrind. valgrind complained that there was a server running already. $ ./xtest $ Updated the lib6xfont1 and libxfont2_2 packages. $ gcc -o xtest -lxcb -O2 -Wall xtest.c $ ./xtest $ Using valgrind as detailed on the upstream POC raises a complaint about the X server running already and issues this at one point: Fatal server error: (EE) Cannot establish any listening sockets - Make sure an X server isn't already running Checking lib64xfont1: The only bdf font on this system was associated with gkrellm, Azteker Tixus. $ bdftopcf -o tixus.pcf tixus.bdf $ file tixus.pcf tixus.pcf: X11 Portable Compiled Font data I tried to install the font using drakfont but saw errors: (drakfont:3091): dconf-WARNING **: failed to commit changes to dconf: The connection is closed ............................. Install Specifics Fonts........... Font to install: /home/lcl/pad/qa/fonts/tixus.pcf rm of /usr/share/fonts/fonts.cache-1 failed: No such file or directory LibreOffice cannot see any new font, neither Azteker nor Tixus. drakfont has worked with ttf fonts in the past. Tried using the command line: # fc-cache # drakfont --application 1 --install ./tixus.pcf Ignore the following Glib::Object::Introspection & Gtk3 warnings .......................... Install Specifics Fonts........... Font to install: /home/lcl/pad/qa/fonts/tixus.pcf rm of /usr/share/fonts/fonts.cache-1 failed: No such file or directory Note that none of my machines has /usr/share/fonts/fonts.cache-1 Maybe drakfonts is broken. Despite the absence of any concrete evidence I will assume that the PCF file is a legitimate font file. There are many other fonts on the system and they work OK in LibreOffice. $ fc-list | wc -l 1161 Giving this an OK.
Whiteboard: MGA5TOO => MGA5TOO MGA5-64-OK MGA6-64-OK
Rider to comment 7. It looks like drakfont may indeed be broken. An attempt to install a random TTF raised the same error: Font to install: /data/copyfonts/Dalelands.ttf rm of /usr/share/fonts/fonts.cache-1 failed: No such file or directory Or is this an initialization problem. It is the first time I have seen it in many years of installing free fonts.
Installed and tested without issue. The test involved running the PoC xtest program connected to a X11 vfb server at :1. The server was running in valgrind. No out of bound issues were seen in the test so the CVE issue should be fixed. IMPORTANT NOTICE: The PoC xtest.c source code shows that the PoC program connects to a X server at :1 and NOT at :0, like in the comments above mention. Normal desktop use also tested without any noticeable issues. System: Mageia 5, x86_64, Plasma DE, Intel CPU, nVidia CPU using proprietary driver nvidia340. $ uname -a Linux marte 4.4.92-desktop-1.mga5 #1 SMP Thu Oct 12 20:14:45 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux $ rpm -qa | grep lib.*xfont lib64xfont1-1.5.1-1.1.mga5 $ rpm -qa | grep x11-server x11-server-xvfb-1.16.4-2.3.mga5 x11-server-xorg-1.16.4-2.3.mga5 x11-server-common-1.16.4-2.3.mga5 $ cd ~/tmp/ $ wget 'https://bugs.mageia.org/attachment.cgi?id=9731' -q -O xtest.c $ gcc xtest.c -lxcb -Wall -o xtest $ valgrind Xvfb :1 & [1] 4421 $ ==4421== Memcheck, a memory error detector ==4421== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==4421== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info ==4421== Command: Xvfb :1 ==4421== $ VALGRIND_PID=$! $ echo $VALGRIND_PID 4421 $ ./xtest $ kill -s TERM $VALGRIND_PID $ ==4421== ==4421== HEAP SUMMARY: ==4421== in use at exit: 28,641 bytes in 63 blocks ==4421== total heap usage: 81,582 allocs, 81,519 frees, 115,268,798 bytes allocated ==4421== ==4421== LEAK SUMMARY: ==4421== definitely lost: 48 bytes in 2 blocks ==4421== indirectly lost: 0 bytes in 0 blocks ==4421== possibly lost: 0 bytes in 0 blocks ==4421== still reachable: 28,593 bytes in 61 blocks ==4421== suppressed: 0 bytes in 0 blocks ==4421== Rerun with --leak-check=full to see details of leaked memory ==4421== ==4421== For counts of detected and suppressed errors, rerun with: -v ==4421== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
CC: (none) => mageia
Re comment 9. When I tested the POC in mga5 it would not work with :1 but seemed to work with 0:. On mga6 I could not get it to work for :0 or :1. Anyway, it is good that it did work for PC LX.
Advisoried. Validating as we have both releases covered for 64-bit.
Keywords: (none) => advisory, validated_updateCC: (none) => lewyssmith, sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2017-0373.html
Resolution: (none) => FIXEDStatus: ASSIGNED => RESOLVED