Memory Corruption Vulnerability2.txt

Memory Corruption Vulnerability2.txt (text/plain), 5.81 KB, created by Sune Kloppenborg Jeppesen (RETIRED) on 2007-01-07 12:36:00 UTC

Multiple Vendor X Server Xdbe Extension 'ProcRenderAddGlyphs()' Memory
Corruption Vulnerability

iDefense Security Advisory XX.XX.06
http://www.idefense.com/intelligence/vulnerabilities/
MMM DD, 2006

I. BACKGROUND

The X Window System is a graphical windowing system based on a client/server
model. More information about about The X Window system is available at the
following link:

http://en.wikipedia.org/wiki/X_Window_System

II. DESCRIPTION

Local exploitation of a memory corruption vulnerability in the
'ProcDbeGetVisualInfo()' function in the X.Org and XFree86 X server could allow
an attacker to execute arbitrary code with privileges of the X server, typically
root.

xorg-server-X11R7.1-1.1.0/dbe/dbe.c


static int
ProcDbeGetVisualInfo(ClientPtr client)
{  
    REQUEST(xDbeGetVisualInfoReq);
    DbeScreenPrivPtr        pDbeScreenPriv;
    xDbeGetVisualInfoReply  rep;
    Drawable            *drawables;
    DrawablePtr         *pDrawables = NULL;
    register int        i, j, n;
    register int        count;  /* number of visual infos in reply */
    register int        length; /* length of reply */
    ScreenPtr           pScreen;
    XdbeScreenVisualInfo    *pScrVisInfo;        
        

    REQUEST_AT_LEAST_SIZE(xDbeGetVisualInfoReq);

    /* Make sure any specified drawables are valid. */
    if (stuff->n != 0)
    {                                  
1]     if (!(pDrawables = (DrawablePtr *)ALLOCATE_LOCAL(stuff->n *
                                                 sizeof(DrawablePtr))))
        {
            return(BadAlloc);
        }
    
        drawables = (Drawable *)&stuff[1];
            
        for (i = 0; i < stuff->n; i++)
        {
2]         if (!(pDrawables[i] = (DrawablePtr)SecurityLookupDrawable(
                drawables[i], client, SecurityReadAccess)))
            {
                DEALLOCATE_LOCAL(pDrawables);
                return(BadDrawable);
            }
        }  
    }

1) This macro will call alloca() on systems that support it, or malloc() on
systems that do not.  There are two vulnerabilities here.  First there is an
integer overflow when multiplying the two operands.  If stuff->n is > 0xffffffff
/ sizeof(DrawablePtr) the operation will overflow, and too little memory will be
allocated.  If malloc() is being used then this is the only way to exploit the
vulnerability.  The second vulnerability is passing a user controlled value to
the alloca() function.  This function takes its argument and subtracts it from
the current stack pointer in order to allocate local storage dynamically without
using the heap.  By passing alloca() a large unsigned value the stack pointer
can be set to nearly anywhere in the address space, including an area outside of
the actual stack segment.  This address can then be overwritten with arbitrary
values.

2) If alloca() is used then an attacker can trigger an overwrite of an arbitrary
address with arbitrary data when this function pushes its drawables[i] argument
onto the stack.  This value is supplied by the attacker. If malloc() is used
then an attacker can trigger a heap overflow with data they partially control.


III. ANALYSIS

Successful local exploitation allows an attacker to execute arbitrary as the
root user. In order to exploit this vulnerability an attacker would require the
ability to send commands to an affected X server. This typically requires access
to the console, or access to the same account as a user who is on the console.
One method of gaining the required access would be to remotely exploit a
vulnerability in, for example, a graphical web browser. Thiw would then allow an
attacker to exploit this vulnerability and elevate their privileges to root.

As exploitation requires access to the X server, but typically gives local root,
iDefense considers this a MEDIUM-severity vulnerability.

IV. DETECTION

iDefense has confirmed the existance of this vulnerability in the X.org server
version 7.1-1.1.0. Previous versions may also be affected.

V. WORKAROUND

Disable loading of the dbe extension in the X configuration file. Depending on
the version of X being used this file name varies. Common names are:

/etc/X11/xorg.conf
/etx/X11/XF86Config

Removing the line:

Load "dbe"

from this file will stop the DBE extension from being loaded.


VI. VENDOR RESPONSE

[Quoted vendor response if available. Otherwise include vendor fix
details.]

VII. CVE INFORMATION

The Common Vulnerabilities and Exposures (CVE) project has assigned the
name CVE-2006-XXXX to this issue. This is a candidate for inclusion in
the CVE list (http://cve.mitre.org), which standardizes names for
security problems.

[OR]

A Mitre Corp. Common Vulnerabilities and Exposures (CVE) number has not
been assigned yet.

VIII. DISCLOSURE TIMELINE

XX/XX/2006  Initial vendor notification
XX/XX/2006  Initial vendor response
XX/XX/2006  Coordinated public disclosure

IX. CREDIT

This vulnerability was discovered by Sean Larsson, iDefense Labs.

Get paid for vulnerability research
http://www.idefense.com/methodology/vulnerability/vcp.php

Free tools, research and upcoming events
http://labs.idefense.com/

X. LEGAL NOTICES

Copyright © 2006 iDefense, Inc.

Permission is granted for the redistribution of this alert
electronically. It may not be edited in any way without the express
written consent of iDefense. If you wish to reprint the whole or any
part of this alert in any other medium other than electronically, please
email [e-mail] for permission.

Disclaimer: The information in the advisory is believed to be accurate
at the time of publishing based on currently available information. Use
of the information constitutes acceptance for use in an AS IS condition.
There are no warranties with regard to this information. Neither the
author nor the publisher accepts any liability for any direct, indirect,
or consequential loss or damage arising from use of, or reliance on,
this information.