X.Org Security Advisory: May 13, 2014
X Font Service Protocol & Font metadata file handling issues in libXfont
Ilja van Sprundel, a security researcher with IOActive, has discovered
several issues in the way the libXfont library handles the responses
it receives from xfs servers, and has worked with X.Org's security team
to analyze, confirm, and fix these issues.
Most of these issues stem from libXfont trusting the font server to send
valid protocol data, and not verifying that the values will not overflow
or cause other damage. This code is commonly called from the X server
when an X Font Server is active in the font path, so may be running in a
setuid-root process depending on the X server in use. Exploits of this
path could be used by a local, authenticated user to attempt to raise
privileges; or by a remote attacker who can control the font server to
attempt to execute code with the privileges of the X server. (CVE-2014-XXXA
is the exception, as it does not involve communication with a font server,
as explained below.)
The vulnerabilities are:
- CVE-2014-0209: integer overflow of allocations in font metadata file parsing
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.
Affected functions: FontFileAddEntry(), lexAlias()
- CVE-2014-0210: unvalidated length fields when parsing xfs protocol replies
When parsing replies received from the font server, these calls do not
check that the lengths and/or indexes returned by the font server are
within the size of the reply or the bounds of the memory allocated to
store the data, so could write past the bounds of allocated memory when
storing the returned data.
Affected functions: _fs_recv_conn_setup(), fs_read_open_font(),
fs_read_query_info(), fs_read_extent_info(), fs_read_glyphs(),
- CVE-2014-0211: integer overflows calculating memory needs for xfs replies
These calls do not check that their calculations for how much memory
is needed to handle the returned data have not overflowed, so can
result in allocating too little memory and then writing the returned
data past the end of the allocated buffer.
Affected functions: fs_get_reply(), fs_alloc_glyphs(),
X.Org believes all prior versions of this library contain these flaws,
dating back to its introduction in X11R5.
Arches, please stabilize x11-libs/libXfont-1.4.8
Target keywords: alpha amd64 arm hppa ia64 ppc ppc64 sparc x86
Stable for HPPA.
Maintainer(s), please cleanup.
Security, please add it to the existing request, or file a new one.
Arches, Thank you for your work
Maintainer(s), please drop the vulnerable version.
New GLSA Request filed.
The vulnerable version has been removed from the tree.
Multiple integer overflows in the (1) fs_get_reply, (2) fs_alloc_glyphs, and
(3) fs_read_extent_info functions in X.Org libXfont before 1.4.8 and 1.4.9x
before 18.104.22.1681 allow remote font servers to execute arbitrary code via a
crafted xfs reply, which triggers a buffer overflow.
Multiple buffer overflows in X.Org libXfont before 1.4.8 and 1.4.9x before
22.214.171.1241 allow remote font servers to execute arbitrary code via a crafted
xfs protocol reply to the (1) _fs_recv_conn_setup, (2) fs_read_open_font,
(3) fs_read_query_info, (4) fs_read_extent_info, (5) fs_read_glyphs, (6)
fs_read_list, or (7) fs_read_list_info function.
Multiple integer overflows in the (1) FontFileAddEntry and (2) lexAlias
functions in X.Org libXfont before 1.4.8 and 1.4.9x before 126.96.36.1991 might
allow local users to gain privileges by adding a directory with a large
fonts.dir or fonts.alias file to the font path, which triggers a heap-based
buffer overflow, related to metadata.
This issue was resolved and addressed in
GLSA 201406-11 at http://security.gentoo.org/glsa/glsa-201406-11.xml
by GLSA coordinator Mikle Kolyada (Zlogene).