Attachment 7986 Details for Bug 9267 – 1st iDefense draft advisory

1st iDefense draft advisory

ultiple Vendor X Server Xdbe Extension%09'ProcRenderAddGlyphs()' Memory Corruption Vulnerability.txt (text/plain), 6.68 KB, created by Matthieu Herrb on 2006-12-06 13:37:26 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Matthieu Herrb

Created: 2006-12-06 13:37:26 UTC

Size: 6.68 KB

patch

obsolete

>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 customerservice@idefense.com 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.
>

Actions: View

Attachments on bug 9267: 7986 | 7987 | 7988 | 7989 | 7990 | 7991 | 8007 | 8309 | 8310

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.