Memory Corruption Vulnerability3.txt

Memory Corruption Vulnerability3.txt (text/plain), 6.68 KB, created by Sune Kloppenborg Jeppesen (RETIRED) on 2007-01-07 12:36:12 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
'ProcRenderAddGlyphs()' 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/render/render.c


static int
ProcRenderAddGlyphs (ClientPtr client)
{
    GlyphSetPtr     glyphSet;
    REQUEST(xRenderAddGlyphsReq);
    GlyphNewRec     glyphsLocal[NLOCALGLYPH];
    GlyphNewPtr     glyphsBase, glyphs;
    GlyphPtr        glyph;
    int         remain, nglyphs;
    CARD32      *gids;
    xGlyphInfo      *gi;
    CARD8       *bits;
    int         size;
    int         err = BadAlloc;

    REQUEST_AT_LEAST_SIZE(xRenderAddGlyphsReq);
    glyphSet = (GlyphSetPtr) SecurityLookupIDByType (client,
                             stuff->glyphset,
                             GlyphSetType,
                             SecurityWriteAccess);
    if (!glyphSet)
    {
    client->errorValue = stuff->glyphset;
    return RenderErrBase + BadGlyphSet;
    }

    nglyphs = stuff->nglyphs;
    if (nglyphs <= NLOCALGLYPH)
    glyphsBase = glyphsLocal;
    else
    {  
1]  glyphsBase = (GlyphNewPtr) ALLOCATE_LOCAL (nglyphs * sizeof (GlyphNewRec));
    if (!glyphsBase)
        return BadAlloc;
    }

    remain = (client->req_len << 2) - sizeof (xRenderAddGlyphsReq);

    glyphs = glyphsBase;

    gids = (CARD32 *) (stuff + 1);
    gi = (xGlyphInfo *) (gids + nglyphs);
    bits = (CARD8 *) (gi + nglyphs);
    remain -= (sizeof (CARD32) + sizeof (xGlyphInfo)) * nglyphs;
    while (remain >= 0 && nglyphs)
    {
    glyph = AllocateGlyph (gi, glyphSet->fdepth);
    if (!glyph)
    {
        err = BadAlloc;
        goto bail;
    }

2] glyphs->glyph = glyph;
    glyphs->id = *gids;

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->nglyphs is >
0xffffffff / sizeof(GlyphNewRec) 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 a nearly
arbitrary address with arbitrary data when *gids is stored into glyphs->id.
This value is supplied by the attacker.  If malloc() is used then an attacker
can trigger a heap overflow. 


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

The render extension is built in to some versions of X. One way of checking
whether it is built in is to run a command like:


[test@test]grep -i render /var/log/Xorg.0.log
        X.Org Font Renderer : 0.4
        Module class: X.Org Font Renderer
        ABI class: X.Org Font Renderer, version 0.4
        Module class: X.Org Font Renderer
        ABI class: X.Org Font Renderer, version 0.4
(WW) RADEON(0): Direct rendering disabled
(II) RADEON(0): Render acceleration enabled
(II) Initializing built-in extension RENDER


This would indicate that render is built in. If it is not built in, then it can
be disabled from loading by editing 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 "render"

from this file will stop the render extension from being loaded. Applying this
workaround may affect the operation of some applications.


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.