0day.today - Biggest Exploit Database in the World.
![](/img/logo_green.jpg)
- We use one main domain: http://0day.today
- Most of the materials is completely FREE
- If you want to purchase the exploit / get V.I.P. access or pay for any other service,
you need to buy or earnGOLD
Administration of this site uses the official contacts. Beware of impostors!
![We DO NOT use Telegram or any messengers / social networks!](/img/no_telegram_big.png)
Please, beware of scammers!
- Read the [ agreement ]
- Read the [ Submit ] rules
- Visit the [ faq ] page
- [ Register ] profile
- Get [ GOLD ]
- If you want to [ sell ]
- If you want to [ buy ]
- If you lost [ Account ]
- Any questions [ admin@0day.today ]
- Authorisation page
- Registration page
- Restore account page
- FAQ page
- Contacts page
- Publishing rules
- Agreement page
Mail:
Facebook:
Twitter:
Telegram:
We DO NOT use Telegram or any messengers / social networks!
You can contact us by:
Mail:
Facebook:
Twitter:
Telegram:
We DO NOT use Telegram or any messengers / social networks!
LibSMI smiGetNode Buffer Overflow When Long OID Is Given In Numerical
===================================================================== LibSMI smiGetNode Buffer Overflow When Long OID Is Given In Numerical ===================================================================== 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 Pedro Varangot [http://corelabs.coresecurity.com/index.php?module=Wiki&action=view&type=researcher&name=Pedro_Varangot] being on leave due to health issues. The advisory draft mentions Net-SNMP as possible vulnerabile software. . 2010-09-11: Juergen Schoenwaelder replies with a patch fixing the vulnerability, and correcting some tecnical information in the advisory draft regarding the impact of the vulnerability, stating that it is likely low and that Net-SNMP is not affected. . 2010-09-27: Core Security Technologies replies to Juergen Schoenwaelder and Vincent Bernat agreeing that the impact of the vulnerability is low and removes the mention of Net-SNMP in the avisory. Core Security Technologies asks for a timeline regarding the release of a fixed version of libsmi stating that this advisory will be released anyway, because someone may be using libsmi in his software introducing a vulnerability he may not know about. No reply is received for this e-mail. . 2010-10-04: Core Security Technologies notifies Juergen Schoenwaelder and Vincent Bernat that October the 18th has been set as a tentative release date for this advisory, and that the release date is open to discussion if commitment to release a fixed version of libsmi in a given timeframe is given. . 2010-10-08: Juergen Schoenwaelder replies with sugestions for the vulnerable packages and vendor information section of this advisory. He also mentions that Core Security Technologies should go with the October de 18th release date for this advisory. . 2010-10-08: Core Security Technologies incorporates Juergen Schoenwaelder's suggestions to the advisory, and again mentions that the advisory can be rescheduled if it is deemed necesary by the vendor. . 2010-10-20: Advisory CORE-2010-0819 is released. 10. *References* [1] [http://www.ibr.cs.tu-bs.de/projects/libsmi/] [2] [http://www.ibr.cs.tu-bs.de/projects/libsmi/libsmi.html] # 0day.today [2024-07-01] #