Sun Microsystems Solaris ld.so 'doprf()' Buffer Overflow Vulnerability

iDefense Security Advisory 12.12.06
http://labs.idefense.com/intelligence/vulnerabilities/ 
Dec 12, 2006

I. BACKGROUND

Solaris is a UNIX operating system developed by Sun Microsystems.  More
information can be found at http://www.sun.com/software/solaris/ 

II. DESCRIPTION

Local exploitation of a buffer overflow vulnerability in ld.so could
potentially allow a non root user to execute arbitrary code as root.

ld.so is vulnerable to a buffer overflow in its internal doprf()
formatting function. A fixed size stack buffer is used to store the
precision padding characters when printing out a numerical format
specifier. The vulnerable code was taken from the OpenSolaris source, and
is as follows:

size_t
doprf(const char *format, va_list args, Prfbuf *prf)
{
    char    c;
    char    *bp = prf->pr_cur;
    char    *bufend = prf->pr_buf + prf->pr_len;
    size_t  bufsiz = prf->pr_len;

    while ((c = *format++) != '\0') {
        if (c != '%') {
            PUTC(c);
        } else {
            int base = 0, flag = 0, width = 0, prec = 0;
            size_t  _i;
            int _c, _n;
            char    *_s;
            int ls = 0;

* snip *

            if (base) {
1]             char        local[20];
                const char  *string                             MSG_ORIG(MSG_STR_HEXNUM);
                size_t      ssize = 0, psize = 0;
                const char  *prefix                             MSG_ORIG(MSG_STR_EMPTY);
                u_longlong_t    num;


* snip *

                /*
                 * Convert the numeric value into a local
                 * string (stored in reverse order).
                 */
                _s = local;
2]            do {
                    *_s++ = string[num % base];
                    num /= base;
                    ssize++;
                } while (num);
                
                /*
                 * Provide any precision or width padding.
                 */
                if (prec) {
                    /* LINTED */
                    _n = (int)(prec - ssize);
3]                while (_n-- > 0) {
                        *_s++ = '0';
                        ssize++;
                    }
                }

1) This is the stack buffer that will later be overflowed.

2) Here the given number is stored into the buffer.  There is no chance
for an overflow here as the maximum number of digits in a long long int is
20 bytes.

3) However in this loop an attacker can freely overwrite the stack with
'0' (0x30) bytes.

This vulnerability would normally not be able to be triggered by a non
root user. The doprf() function is only supposed to be passed format
strings from a message file owned by root. However, when this
vulnerability is combined with the ld.so directory traversal vulnerability
any user can pass arbitrary format strings to the doprf() function.

III. ANALYSIS

Successful local exploitation allows an attacker to execute arbitrary code
as root on the affected host by running a setuid binary.

Exploitation is difficult due to the limited data value with which the
buffer can be overflowed. It is necessary to have valid memory mapped at
an address with a most significant byte of 0x30, for example 0x30fffff0.
In our tests on both x86 and SPARC architectures we were unable to achieve
this. With a different memory layout exploitation may be possible.  On x86,
it also may be possible to overwrite the low byte of a saved frame pointer
if the registers are allocated in a different way.

IV. DETECTION

iDefense has confirmed that Solaris 10 for both x86 and SPARC is
vulnerable. Older versions of Solaris are likely to be vulnerable as well.

V. WORKAROUND

iDefense is unaware of any effective workarounds for this issue.

VI. VENDOR RESPONSE

Sun Microsystems has addressed this problem with new patches. More
information can be found in Sun Alert #102724. This alert can be found at:
http://sunsolve.sun.com/search/document.do?assetkey=1-26-102724-1 

VII. CVE INFORMATION

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

VIII. DISCLOSURE TIMELINE

10/24/2006  Initial vendor notification
10/27/2006  Initial vendor response
12/12/2006  Coordinated public disclosure

IX. CREDIT

Sean Larsson (iDefense Labs) is credited with the discovery of this
vulnerability.

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

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

X. LEGAL NOTICES

Copyright =A9 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 e-mail
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.