Multiple security issues in libxfont were announced today (May 13): http://seclists.org/oss-sec/2014/q2/302 They will be fixed upstream in version 1.4.8. Mageia 3 and Mageia 4 are also affected. As far as backporting fixes, only CVE-2014-0209 sounds important (heap overflow). The other two issues depend on xfs, which we stopped using several years ago (thankfully). Reproducible: Steps to Reproduce:
Whiteboard: (none) => MGA4TOO, MGA3TOO
Debian and Ubuntu have issued advisories for this on May 13 and May 14: https://www.debian.org/security/2014/dsa-2927 http://www.ubuntu.com/usn/usn-2211-1/ Thierry, Ubuntu says that as of Ubuntu 14.04 they've used the --disable-fc configure option in libxfont to explicitly disable support for xfs (which also eliminates the CVE-2014-021[01] vulnerabilities). Should we do the same?
URL: (none) => http://lwn.net/Vulnerabilities/598578/
I built 1.4.8 locally, but the build failed in Cauldron: http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20140520195850.luigiwalser.valstar.10808/log/libxfont-1.4.8-1.mga5/build.0.20140520195901.log
Version: Cauldron => 4Whiteboard: MGA4TOO, MGA3TOO => MGA3TOO
Version: 4 => CauldronWhiteboard: MGA3TOO => MGA4TOO, MGA3TOO
With a patch from upstream via omdv, it builds now in Cauldron.
Version: Cauldron => 4
I did a second build in Cauldron, disabling xfs support. I left it alone in mga3/mga4 for now. Patched packages uploaded for Mageia 3 and Mageia 4. Advisory: ======================== Updated libxfont packages fix security vulnerabilities: Ilja van Sprundel discovered that libXfont incorrectly handled font metadata file parsing. A local attacker could use this issue to cause libXfont to crash, or possibly execute arbitrary code in order to gain privileges (CVE-2014-0209). Ilja van Sprundel discovered that libXfont incorrectly handled X Font Server replies. A malicious font server could return specially-crafted data that could cause libXfont to crash, or possibly execute arbitrary code (CVE-2014-0210, CVE-2014-0211). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0209 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0210 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0211 http://www.ubuntu.com/usn/usn-2211-1/ ======================== Updated packages in core/updates_testing: ======================== libxfont1-1.4.5-3.2.mga3 libxfont1-devel-1.4.5-3.2.mga3 libxfont1-static-devel-1.4.5-3.2.mga3 libxfont1-1.4.7-1.1.mga4 libxfont-devel-1.4.7-1.1.mga4 from SRPMS: libxfont-1.4.5-3.2.mga3.src.rpm libxfont-1.4.7-1.1.mga4.src.rpm
CC: (none) => thierry.vignaudAssignee: thierry.vignaud => qa-bugsWhiteboard: MGA4TOO, MGA3TOO => MGA3TOOSeverity: normal => major
Testing MGA4 64-bit real hardware Updated to lib64xfont1-1.4.7-1.1.mga4 OK. How do I know whether the library is being used? Just a bit of normal usage?
CC: (none) => lewyssmith
My understanding is that different types of fonts are handled by different libraries. Certainly you'll need to restart the X server (log out and restart the X server from the DM) for the updated library to start being used. I guess try using several different types of fonts in some applications (like LibreOffice Writer) and make sure things generally seem the same.
More info on this. Only CVE-2014-0209 is really important here IMO. From http://lists.x.org/archives/xorg-announce/2014-May/002431.html: When a local user who is already authenticated to the X server adds a new directory to the font path, the X server calls libXfont to open the fonts.dir and fonts.alias files in that directory and add entries to the font tables for every line in it. A large file (~2-4 gb) could cause the allocations to overflow, and allow the remaining data read from the file to overwrite other memory in the heap. These pages shows how to add directories to the font path at runtime: http://www.freebsd.org/doc/handbook/x-fonts.html http://www.x.org/archive/X11R6.8.0/doc/fonts2.html Speaking of which, we should add the upstream advisory to the References: http://lists.x.org/archives/xorg-announce/2014-May/002431.html
Testing MGA4 64-bit real hardware Added a font directory & copied a few existing fonts into it. Did $ mkfontscale <fontdir> $ mkfontdir <fontdir> which created fonts.dir & fonts.scale . $ xset fp+ <fontdir> $ xset q correctly added this fontdir to the pathlist: Font Path: catalogue:/etc/X11/fontpath.d,built-ins,/home/lewis/.fonts Confused about the difference between: - Configuring Xft [fontconfig] - Configuring the core X11 fonts system and things mentioned in http://www.x.org/archive/X11R6.8.0/doc/fonts2.html which I could not find: specific sections in specific config files. Without anything nasty happening, I'm OKing this.
Whiteboard: MGA3TOO => MGA3TOO MGA4-64-OK
(In reply to Lewis Smith from comment #8) > Confused about the difference between: > - Configuring Xft [fontconfig] > - Configuring the core X11 fonts system > and things mentioned in http://www.x.org/archive/X11R6.8.0/doc/fonts2.html > which I could not find: specific sections in specific config files. So I think what's relevant here is the core X11 fonts, as Xft/fontconfig should use different libraries. > Without anything nasty happening, I'm OKing this. Nice job. Thanks.
testing on MGA4 32bit the same procedure as Lewis did in Comment #8. Font Path: catalogue:/etc/X11/fontpath.d,built-ins,/home/marc/fonts/ Citing Lewis: nothing nasty happened.
Whiteboard: MGA3TOO MGA4-64-OK => MGA3TOO MGA4-64-OK MGA4-64-OK
Whiteboard: MGA3TOO MGA4-64-OK MGA4-64-OK => MGA3TOO MGA4-64-OK MGA4-32-OK
tested the same way for MGA3 32bit and 64bit. Everything is fine as described above. For me this update can be validated if those tests are sufficient.
CC: (none) => marc.lattemann
CC: marc.lattemann => (none)Whiteboard: MGA3TOO MGA4-64-OK MGA4-32-OK => MGA3TOO MGA4-64-OK MGA4-32-OK MGA3-32-OK MGA3-64-OK
Validating update, advisory uploaded. Please push libxfont to Mageia 3 and 4 core/updates.
Keywords: (none) => validated_updateWhiteboard: MGA3TOO MGA4-64-OK MGA4-32-OK MGA3-32-OK MGA3-64-OK => MGA3TOO MGA4-64-OK MGA4-32-OK MGA3-32-OK MGA3-64-OK advisoryCC: (none) => remi, sysadmin-bugs
Update pushed: http://advisories.mageia.org/MGASA-2014-0278.html
Status: NEW => RESOLVEDCC: (none) => tmbResolution: (none) => FIXED