X.Org Security Advisory: October 8, 2013 - CVE-2013-4396
Use after free in Xserver handling of ImageText requests
========================================================
Description:
============
Pedro Ribeiro (ped...@gmail.com) reported an issue to the X.Org security
team in which an authenticated X client can cause an X server to use memory
after it was freed, potentially leading to crash and/or memory corruption.
Affected Versions
=================
This bug appears to have been introduced in RCS version 1.42 on 1993/09/18,
and is thus believed to be present in every X server release starting with
X11R6.0 up to the current xorg-server 1.14.3. (Manual inspection shows it
is present in the sources from the X11R6 tarballs, but not in those from the
X11R5 tarballs.)
Fixes
=====
A fix is available via the attached patch, which is intended to be included
in xorg-server 1.15.0 and 1.14.4.
Thanks
======
X.Org thanks Pedro Ribeiro for reporting this issues to our security team at
xorg-secur...@lists.x.org.
--
-Alan Coopersmith- alan.coopersm...@oracle.com
X.Org Security Response Team - xorg-secur...@lists.x.org
From 7bddc2ba16a2a15773c2ea8947059afa27727764 Mon Sep 17 00:00:00 2001
From: Alan Coopersmith <alan.coopersm...@oracle.com>
Date: Mon, 16 Sep 2013 21:47:16 -0700
Subject: [PATCH] Avoid use-after-free in dix/dixfonts.c: doImageText()
[CVE-2013-4396]
Save a pointer to the passed in closure structure before copying it
and overwriting the *c pointer to point to our copy instead of the
original. If we hit an error, once we free(c), reset c to point to
the original structure before jumping to the cleanup code that
references *c.
Since one of the errors being checked for is whether the server was
able to malloc(c->nChars * itemSize), the client can potentially pass
a number of characters chosen to cause the malloc to fail and the
error path to be taken, resulting in the read from freed memory.
Since the memory is accessed almost immediately afterwards, and the
X server is mostly single threaded, the odds of the free memory having
invalid contents are low with most malloc implementations when not using
memory debugging features, but some allocators will definitely overwrite
the memory there, leading to a likely crash.
Reported-by: Pedro Ribeiro <ped...@gmail.com>
Signed-off-by: Alan Coopersmith <alan.coopersm...@oracle.com>
Reviewed-by: Julien Cristau <jcris...@debian.org>
---
dix/dixfonts.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/dix/dixfonts.c b/dix/dixfonts.c
index feb765d..2e34d37 100644
--- a/dix/dixfonts.c
+++ b/dix/dixfonts.c
@@ -1425,6 +1425,7 @@ doImageText(ClientPtr client, ITclosurePtr c)
GC *pGC;
unsigned char *data;
ITclosurePtr new_closure;
+ ITclosurePtr old_closure;
/* We're putting the client to sleep. We need to
save some state. Similar problem to that handled
@@ -1436,12 +1437,14 @@ doImageText(ClientPtr client, ITclosurePtr c)
err = BadAlloc;
goto bail;
}
+ old_closure = c;
*new_closure = *c;
c = new_closure;
data = malloc(c->nChars * itemSize);
if (!data) {
free(c);
+ c = old_closure;
err = BadAlloc;
goto bail;
}
@@ -1452,6 +1455,7 @@ doImageText(ClientPtr client, ITclosurePtr c)
if (!pGC) {
free(c->data);
free(c);
+ c = old_closure;
err = BadAlloc;
goto bail;
}
@@ -1464,6 +1468,7 @@ doImageText(ClientPtr client, ITclosurePtr c)
FreeScratchGC(pGC);
free(c->data);
free(c);
+ c = old_closure;
err = BadAlloc;
goto bail;
}
--
1.7.9.2
_______________________________________________
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
