Exploit-DB #15293
Description: LibSMI smiGetNode - Buffer Overflow When Long OID Is Given In Numerical Form
Type: dos
Platform: linux
Date: 2010-10-20
Author: Core Security

Exploit:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
                Core Security Technologies - CoreLabs Advisory
                            http://corelabs.coresecurity.com/

LibSMI smiGetNode Buffer Overflow When Long OID Is Given In Numerical Form


1. *Advisory Information*

Title: LibSMI smiGetNode Buffer Overflow When Long OID Is Given In
Numerical Form
Advisory Id: CORE-2010-0819
Advisory URL:
http://www.coresecurity.com/content/libsmi-smigetnode-buffer-overflow
Date published: 2010-10-20
Date of last update: 2010-10-20
Vendors contacted: Libsmi team
Release mode: Coordinated release


2. *Vulnerability Information*

Class: Failure to Constrain Operations within the Bounds of a Memory
Buffer [CWE-119]
Impact: Code execution
Remotely Exploitable: Yes
Locally Exploitable: Yes
CVE Name: CVE-2010-2891
Bugtraq ID: N/A


3. *Vulnerability Description*

A statically allocated buffer is overwritter in the case that a very
long Object Identifier is specified in stringified dotted notation to
the smiGetNode function of libsmi[1]. This may result in arbitraty
code execution by cleverly overwriting key pointers in memory.


4. *Vulnerable packages*

   . libsmi 0.4.8.
   . Any software that uses the vulnerable function to find a
definition from an Object Indentifier specified in stringified dotted
notation that is given by the user. The SNMP packets from the protocol
that travel over the network do not use this notation for OIDs.


5. *Non-vulnerable packages*

   . libsmi 0.4.8 patched with the supplied patch.
   . Any future release of libsmi, or current SVN head revision, since
this patch was already commited to their repositories.


6. *Vendor Information, Solutions and Workarounds*

This patch was supplied by Juergen Schoenwaelder and fixes the bug:

/-----
Index: lib/smi.c
===================================================================
- --- lib/smi.c    (revision 29144)
+++ lib/smi.c    (working copy)
@@ -1793,10 +1793,15 @@
     }
 
     if (isdigit((int)node2[0])) {
- -    for (oidlen = 0, p = strtok(node2, ". "); p;
+    for (oidlen = 0, p = strtok(node2, ". ");
+         p && oidlen < sizeof(oid)/sizeof(oid[0]);
          oidlen++, p = strtok(NULL, ". ")) {
         oid[oidlen] = strtoul(p, NULL, 0);
     }
+    if (p) {
+        /* the numeric OID is too long */
+        return NULL;
+    }
     nodePtr = getNode(oidlen, oid);
     if (nodePtr) {
         if (modulePtr) {
- -----/


7. *Credits*

This vulnerability was discovered and researched by Andrés López
Luksenberg
[http://corelabs.coresecurity.com/index.php?module=Wiki&action=view&type=researcher&name=Andres_Lopez_Luksenberg]
from Core Security Technologies. The publication of this advisory was
coordinated by Pedro Varangot
[http://corelabs.coresecurity.com/index.php?module=Wiki&action=view&type=researcher&name=Pedro_Varangot].



8. *Technical Description / Proof of Concept Code*

The 'smiGetNode' function returns a 'SmiNode' struct given the name of
a OID as a 'char *' in both either numeric (i.e. "1.3.6.1.2.1.4.17")
or human readable format (i.e. "ipForwarding"). This function uses a
static array of 128 elements of type 'unsigned int' to hold the OID in
numeric format:

/-----
    SmiSubid        oid[128];
- -----/
 Note that 'SmiSubid' is a 'typedef' of 'unsigned int'.

This array is populated by a loop that calls 'strtok' and then
subsecuently 'strtoul' in the case that the OID supplied as a 'char *'
was in the form of subsecuent numbers separated by a period.

/-----
    if (isdigit((int)node2[0])) {
      for (oidlen = 0, p = strtok(node2, ". "); p;
            oidlen++, p = strtok(NULL, ". ")) {
        oid[oidlen] = strtoul(p, NULL, 0);
      }
    }
- -----/
 That loop clearly overwrites past 'oid' boundaries when the string
contained in 'node2' has more that 128 dots ("."). This constitutes a
classical overflow that can likely be leveraged into arbitrary code
execution reliably.

To verify if the version on 'libsmi' installed on a unix based system
is vulnerable, the code example (smisubtree) from 'man libsmi'[2] can
be used. This programs calls 'smiGetNode' in the following way in line
17:

/-----
    for((smiNode = smiGetNode(NULL, argv[1])) &&}
- -----/
 The program crashes when called via commandline with an OID with more
than 128 numeric tokens, like the OID outputed by the following Python
script:

/-----
    #!/usr/bin/python

    # run ./smisubtree `./libsmicrash.py`

    if __name__ == "__main__":
            s = ""
            for i in xrange(158):
                    s = s + "1."

            print s}
- -----/


9. *Report Timeline*

. 2010-09-06:
Core Security Technologies contacts Vincent Bernat, the Debian Package
Maintainer for libsmi, informing that a bug has been found in libsmi.
Core Security Technologies asks for a security contact in upstream
stating that finding a reliable one using Google or looking at mailing
lists was difficult.

. 2010-09-06:
Vincent Bernat, the Debian Package Maintainer for libsmi, replies with
two e-mail of aledged developers of libsmi, Juergen Schoenwaelder and
Frank Strauss.

. 2010-09-07:
Core Security Technologies contacts Juergen Schoenwaelder and Frank
Strauss at their supplies e-mail addresses, telling about a found
vulnerability and offering an advisory draft in either plain or
encripted form.

. 2010-09-07:
Frank Strauss' e-mail address bounces Core Security Technologies'
e-mail back, informing about a new e-mail address. Core Security
Technologies sends the message again to the new address.

. 2010-09-07:
Juergen Schoenwaelder replies with his PGP keys, and copies Vincent
Bernat again in the conversation.

. 2010-09-09:
Core Security Technologies sends and encripted draft of this advisory
to Juergen Schoenwaelder and Vincent Bernat, with apologies due to the
delay caused by Pe