Common Vulnerabilities and Exposures assigned an identifier CVE-2010-2891 to the following vulnerability: Name: CVE-2010-2891 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-2891 Assigned: 20100727 Reference: BUGTRAQ:20101020 [CORE-2010-0819] LibSMI smiGetNode Buffer Overflow When Long OID Is Given In Numerical Form Reference: URL: http://www.securityfocus.com/archive/1/archive/1/514382/100/0/threaded Reference: EXPLOIT-DB:15293 Reference: URL: http://www.exploit-db.com/exploits/15293 Reference: MISC: http://www.coresecurity.com/content/libsmi-smigetnode-buffer-overflow Reference: CONFIRM: http://security-tracker.debian.org/tracker/CVE-2010-2891 Reference: MANDRIVA:MDVSA-2010:209 Reference: URL: http://www.mandriva.com/security/advisories?name=MDVSA-2010:209 Reference: BID:44276 Reference: URL: http://www.securityfocus.com/bid/44276 Reference: SECUNIA:41841 Reference: URL: http://secunia.com/advisories/41841 Reference: VUPEN:ADV-2010-2764 Reference: URL: http://www.vupen.com/english/advisories/2010/2764 Reference: XF:libsmi-smigetnode-bo(62686) Reference: URL: http://xforce.iss.net/xforce/xfdb/62686 Buffer overflow in the smiGetNode function in lib/smi.c in libsmi 0.4.8 allows context-dependent attackers to execute arbitrary code via an Object Identifier (aka OID) represented as a numerical string containing many components separated by . (dot) characters.
Created attachment 456295 [details] svn diff -r28702:29145 lib/smi.c This is fixed upstream in r29145. The patch looks applicable to pre-0.4.8 versions as well. The only thing that looks to link against libsmi is wireshark, and even there, wireshark does not call the vulnerable function (smiGetNode()); from wireshark 1.2.10: % grep -r smiGetNode * epan/oids.c: SmiType* elType = smiGetNodeType(elNode); epan/oids.c: SmiType* smiType = smiGetNodeType(smiNode); The only thing I see using smiGetNode is libsmi.so.2.0.27, smiquery, and smidump (all part of libsmi). The upstream svn repo doesn't seem to have viewvc or anything to point to for the patch, so I have attached it from an svn checkout.
Statement: This issue affects the version of libsmi shipped with Red Hat Enterprise Linux 4, 5 and 6. The Red Hat Security Response Team has rated this issue as having moderate security impact, a future update may address this flaw.
Hi, libsmi is full of memory corruption issues. taking the juniper mibs for example: for f in v j m l ; do smidump mib-jnx-$f* > /dev/null 2>&1; done Segmentation fault Segmentation fault Segmentation fault smidump crashes without trying.
Hi, I have been contacted by secunia regarding this issue. I haven't really investigated these bugs thoroughly but given that smidump crashes really easily, I suspect there to be exploitable issues in the libraries. Most of the crashes don't look readily exploitable however. If there were some incentive to exploit this i'd give it a try but currently I don't have time for this :/. Below are some results from randomly parsing juniper-mibs-13.2R2.4.tgz . (gdb) x/i $rip => 0x7ffff7ba0201 <smiparse+30833>: mov 0x18(%rax),%rcx (gdb) i r rax 0x21 33 rbx 0x7fffffffe150 140737488347472 rcx 0x21 33 rdx 0x6f2a80 7285376 rsi 0x662530 6694192 rdi 0x669730 6723376 rbp 0x2 0x2 rsp 0x7fffffffcac0 0x7fffffffcac0 r8 0x0 0 r9 0x1ff 511 r10 0x7ffff76912f0 140737344246512 r11 0x0 0 r12 0x6f5770 7296880 r13 0x6f40f0 7291120 r14 0x6f40f0 7291120 r15 0x7ffff7ddcc24 140737351896100 rip 0x7ffff7ba0201 0x7ffff7ba0201 <smiparse+30833> eflags 0x10212 [ AF IF RF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 findNodeByParentAndSubid (parentNodePtr=0x6d0ab0, subid=1) at data.c:1943 1943 data.c: No such file or directory. in data.c (gdb) x/i $rip => 0x7ffff7b8cbf0 <findNodeByParentAndSubid+48>: cmp %esi,(%rax) (gdb) i r rax rax 0x3 3 (gdb) x/i $rip => 0x7ffff7ba0201 <smiparse+30833>: mov 0x18(%rax),%rcx (gdb) i r rax rax 0x41 65 (gdb) x/i $rip => 0x7ffff7ba09a0 <smiparse+32784>: cmpl $0x1,0x74(%rbp) (gdb) i r rbp rbp 0x2e6567 0x2e6567 (gdb) rbp smashes :O