On 05/13/14 08:08 AM, Alan Coopersmith wrote:
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.)
Sorry, missed an update when filling in the assigned CVE's - the above statement
should say "CVE-2014-0209 is the exception" as explained in:
- 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()
--
-Alan Coopersmith- [email protected]
Oracle Solaris Engineering - http://blogs.oracle.com/alanc
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
