[Global InterSec 2001121001] glibc globbing issues.

Jörg Lübbert kaladis at gmx.de
Wed Dec 19 08:38:42 PST 2001


Greetings,

I've attached a patch that I acquired from the latest native.tar.gz from
the OpenWall Linux project. They've got it from the CVS of glibc. Date
and filename looked promising so I figured it's the appropriate patch.
Because of time reasons no verification has been done from my side,
though.

I hope this helps

- Jörg Lübbert

--- 
Kaladix Linux - The Secure Linux Distribution
URL: http://www.kaladix.org

> -----Original Message-----
> From: lfs-security-owner at linuxfromscratch.org [mailto:lfs-security-
> owner at linuxfromscratch.org] On Behalf Of Kristoffer Ekelund
> Sent: Wednesday, December 19, 2001 11:11 AM
> To: lfs-security at linuxfromscratch.org
> Subject: Fw: [Global InterSec 2001121001] glibc globbing issues.
> 
> I don't know if this is a huge issue for most LFS users, but I guess
that
> a lot of us have public servers (eg. ftp/http) that might use the glob
> functions of glibc. What worries me a bit is that I couldn't find any
> "official" patch to this problem, redhat's is availible but I don't
really
> want to use that one... If anyone has some hints on where to look for
an
> official patch that would be nice
> 
>         Sincerely,
>         Kristoffer
> 
> Begin forwarded message:
> 
> Date: Mon, 17 Dec 2001 19:06:30 -0800
> From: "Tom Parker" <tom at rooted.net>
> To: <bugtraq at securityfocus.com>
> Subject: [Global InterSec 2001121001] glibc globbing issues.
> 
> 
> Global InterSec LLC
> http://www.globalintersec.com
> 
> GIS Advisory ID:  2001121001
> Changed:      12/12/2001
> Author:          tom.parker at globalintersec.com
> Reference:
http://www.globalintersec.com/adv/glibc-glob-2001121001.txt
> 
> Note:
> 
>   The release of this advisory has been earlier than first planned due
to
>   RedHats release of information regarding this vulnerability.
>   Redhat are not to blame this time around.
>   However better vendor/researcher coordination is called for.
> 
> Summary:
> 
>  glibc contains a globbing error which may be remotely
>  exploitable when glob functions are used in software
>  such as ftp  daemons.
> 
> Impact:
> 
>  A remote attacker may execute arbitrary commands via heap corruption.
> 
> Description:
> 
>    The glibc glob() function allows programs to search
>    for path names matching specific patterns according
>    the rules used by the shell. Glibc also implements
>    the globfree() function which free()'s memory used
>    earlier by other glob() matches.
>    The glob function itself may encounter errors when
>    handling strings ending with the "{"(0x7b)character.
>    This is due to next_brace_sub() which could cause
>    glob to read memory pages it shouldn't be, eventually
>    causing the program to exit (Normally with SEGV)..
> 
>    Note: The vulnerability described in CA-2001-33 with
>    Washington Universities ftpd was not due to errors in
>    glibc glob - but their own  implementation of this
>    function.
> 
>    Previous discussions on bugtraq and other mailing
>    lists ruled this bug as not exploitable.
>    This is not entirely true.
>    Global Intersec has since discovered a condition
>    under which the bug may be used to exploit this
>    vulnerability.
> 
>    This is dependant on the program in question using
>    the globfree() function, also defined in glibc glob.c
>    (sysdeps/generic/glob.c). An example of this would
>    be the OpenBSD ftpd Linux port.
>    By carefully crafting user input to such daemons it
>    is possible to corrupt memory space of the process.
>    Ultimately the result of this would be an ability to
>    execute arbitrary commands with the privileges of the
>    server process. This is often root(0).
> 
> Scope for attack:
> 
>    For this bug to be exploitable the attacker must be able
>    to cause a daemon to call glob matching functions via
>    services which allow either anonymous/public access or
>    which may require authentication. This includes ftp
>    daemons.
> 
> Work around:
> 
>  The scope for your systems being targeted to this form of
>  attack can be reduced by disabling remotely accessible
>  daemons which use the functions in question. These include
>  the OpenBSD ftpd Linux port.
>  It is also suggested that removal of any public access to
>  such daemons is removed until vendor fixes have been applied.
> 
> Credit:
> 
>  The glob bug was originally bought to light on several
>  mailing lists, but was ruled out as not being exploitable.
>  These include posts by flaviovs at magnux.com who later
>  concluded the bug was exploitable.
> 
>  Tom Parker from Global InterSec has discovered ways in
>  which these bugs can be exploited when used in conjunction
>  with globfree().
> 
>  Many thanks go to SuSE GmbH who have worked with GIS to
>  release the information described in this advisory on a mutually
>  appropriate date.
> 
> 
> Vendor Solutions:
> 
>  Red Hat have released the following series of packages which
>  fix the glibc issues. Other vendors are yet to release official
>  packages due to a lack of preparation time. As vendors release
>  their own updates, this document will be updated and can be viewed
>  at the "Reference" location posted at the top of this document.
> 
>  Red Hat Linux 6.2:
> 
> SRPMS:
> ftp://updates.redhat.com/6.2/en/os/SRPMS/glibc-2.1.3-23.src.rpm
> 
> alpha:
> ftp://updates.redhat.com/6.2/en/os/alpha/glibc-2.1.3-23.alpha.rpm
>
ftp://updates.redhat.com/6.2/en/os/alpha/glibc-devel-2.1.3-23.alpha.rpm
>
ftp://updates.redhat.com/6.2/en/os/alpha/glibc-profile-2.1.3-23.alpha.rp
m
> ftp://updates.redhat.com/6.2/en/os/alpha/nscd-2.1.3-23.alpha.rpm
> 
> i386:
> ftp://updates.redhat.com/6.2/en/os/i386/glibc-2.1.3-23.i386.rpm
> ftp://updates.redhat.com/6.2/en/os/i386/glibc-devel-2.1.3-23.i386.rpm
>
ftp://updates.redhat.com/6.2/en/os/i386/glibc-profile-2.1.3-23.i386.rpm
> ftp://updates.redhat.com/6.2/en/os/i386/nscd-2.1.3-23.i386.rpm
> 
> sparc:
> ftp://updates.redhat.com/6.2/en/os/sparc/glibc-2.1.3-23.sparc.rpm
>
ftp://updates.redhat.com/6.2/en/os/sparc/glibc-devel-2.1.3-23.sparc.rpm
>
ftp://updates.redhat.com/6.2/en/os/sparc/glibc-profile-2.1.3-23.sparc.rp
m
> ftp://updates.redhat.com/6.2/en/os/sparc/nscd-2.1.3-23.sparc.rpm
> 
> sparcv9:
> ftp://updates.redhat.com/6.2/en/os/sparcv9/glibc-2.1.3-23.sparcv9.rpm
> 
> Red Hat Linux 7.0:
> 
> SRPMS:
> ftp://updates.redhat.com/7.0/en/os/SRPMS/glibc-2.2.4-18.7.0.3.src.rpm
> 
> alpha:
>
ftp://updates.redhat.com/7.0/en/os/alpha/glibc-2.2.4-18.7.0.3.alpha.rpm
> ftp://updates.redhat.com/7.0/en/os/alpha/glibc-devel-2.2.4-
> 18.7.0.3.alpha.rp
> m
> ftp://updates.redhat.com/7.0/en/os/alpha/glibc-profile-2.2.4-
> 18.7.0.3.alpha.
> rpm
> ftp://updates.redhat.com/7.0/en/os/alpha/glibc-common-2.2.4-
> 18.7.0.3.alpha.r
> pm
> ftp://updates.redhat.com/7.0/en/os/alpha/nscd-2.2.4-18.7.0.3.alpha.rpm
> 
> alphaev6:
> ftp://updates.redhat.com/7.0/en/os/alphaev6/glibc-2.2.4-
> 18.7.0.3.alphaev6.rp
> m
> 
> i386:
> ftp://updates.redhat.com/7.0/en/os/i386/glibc-2.2.4-18.7.0.3.i386.rpm
> ftp://updates.redhat.com/7.0/en/os/i386/glibc-devel-2.2.4-
> 18.7.0.3.i386.rpm
> ftp://updates.redhat.com/7.0/en/os/i386/glibc-profile-2.2.4-
> 18.7.0.3.i386.rp
> m
> ftp://updates.redhat.com/7.0/en/os/i386/glibc-common-2.2.4-
> 18.7.0.3.i386.rpm
> ftp://updates.redhat.com/7.0/en/os/i386/nscd-2.2.4-18.7.0.3.i386.rpm
> 
> i686:
> ftp://updates.redhat.com/7.0/en/os/i686/glibc-2.2.4-18.7.0.3.i686.rpm
> 
> Red Hat Linux 7.1:
> 
> SRPMS:
> ftp://updates.redhat.com/7.1/en/os/SRPMS/glibc-2.2.4-19.3.src.rpm
> 
> alpha:
> ftp://updates.redhat.com/7.1/en/os/alpha/glibc-2.2.4-19.3.alpha.rpm
>
ftp://updates.redhat.com/7.1/en/os/alpha/glibc-devel-2.2.4-19.3.alpha.rp
m
> ftp://updates.redhat.com/7.1/en/os/alpha/glibc-profile-2.2.4-
> 19.3.alpha.rpm
>
ftp://updates.redhat.com/7.1/en/os/alpha/glibc-common-2.2.4-19.3.alpha.r
pm
> ftp://updates.redhat.com/7.1/en/os/alpha/nscd-2.2.4-19.3.alpha.rpm
> 
> alphaev6:
>
ftp://updates.redhat.com/7.1/en/os/alphaev6/glibc-2.2.4-19.3.alphaev6.rp
m
> 
> i386:
> ftp://updates.redhat.com/7.1/en/os/i386/glibc-2.2.4-19.3.i386.rpm
>
ftp://updates.redhat.com/7.1/en/os/i386/glibc-devel-2.2.4-19.3.i386.rpm
>
ftp://updates.redhat.com/7.1/en/os/i386/glibc-profile-2.2.4-19.3.i386.rp
m
>
ftp://updates.redhat.com/7.1/en/os/i386/glibc-common-2.2.4-19.3.i386.rpm
> ftp://updates.redhat.com/7.1/en/os/i386/nscd-2.2.4-19.3.i386.rpm
> 
> i686:
> ftp://updates.redhat.com/7.1/en/os/i686/glibc-2.2.4-19.3.i686.rpm
> 
> ia64:
> ftp://updates.redhat.com/7.1/en/os/ia64/glibc-2.2.4-19.3.ia64.rpm
>
ftp://updates.redhat.com/7.1/en/os/ia64/glibc-devel-2.2.4-19.3.ia64.rpm
>
ftp://updates.redhat.com/7.1/en/os/ia64/glibc-profile-2.2.4-19.3.ia64.rp
m
>
ftp://updates.redhat.com/7.1/en/os/ia64/glibc-common-2.2.4-19.3.ia64.rpm
> ftp://updates.redhat.com/7.1/en/os/ia64/nscd-2.2.4-19.3.ia64.rpm
> 
> Red Hat Linux 7.2:
> 
> SRPMS:
> ftp://updates.redhat.com/7.2/en/os/SRPMS/glibc-2.2.4-19.3.src.rpm
> 
> i386:
> ftp://updates.redhat.com/7.2/en/os/i386/glibc-2.2.4-19.3.i386.rpm
>
ftp://updates.redhat.com/7.2/en/os/i386/glibc-devel-2.2.4-19.3.i386.rpm
>
ftp://updates.redhat.com/7.2/en/os/i386/glibc-profile-2.2.4-19.3.i386.rp
m
>
ftp://updates.redhat.com/7.2/en/os/i386/glibc-common-2.2.4-19.3.i386.rpm
> ftp://updates.redhat.com/7.2/en/os/i386/nscd-2.2.4-19.3.i386.rpm
> 
> i686:
> ftp://updates.redhat.com/7.2/en/os/i686/glibc-2.2.4-19.3.i686.rpm.
> 
> Exploits (Proof of concept):
> 
>   For the purposes of proving a concept we will now
>   refer to use of these functions in the OpenBSD ftp
>   daemon - ported to Linux by David Madore.
> 
>   As we have recently seen in the Washington University
>   ftp daemon, free() based vulnerabilities are readily
>   exploitable. In the case of the OpenBSD ftpd we must
>   ensure that globfree() is called to make any use of
>   the glob vulnerabilities.
> 
>     Note: OpenBSD itself is not vulnerable to this form of
>     attack due to the way in which it handles memory pages.
> 
>   By forcing globfree() to be called _before_ the next_brace_sub
>   condition occurs it is possible to control the address
>   which is free()'d. In our first example we insert an invalid
>   address onto the stack, causing the program to SEGV.
> 
>    : 220 localhost FTP server (Version 6.5/OpenBSD, linux port 0.3.3)
> ready.
>    -> USER ftp
>    : 331 Guest login ok, type your name as password.
>    Sleeping for 10 seconds...
>    -> PASS AAAAAAAAAAAAAAAAAAA\xef\xef\xbe\xad\xde # ( <19 Bytes>
<Addr to
> write> <Glob char>)
>    : 230 Guest login ok, access restrictions apply.
>    -> STAT ~AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA{
> 
>    #0  0x400f7968 in globfree () at ../sysdeps/generic/glob.c:1055
>    #1  0x8051b0b in yyparse () at ftpcmd.y:1138
>    # 2  0x804b455 in main (argc=3D1094795585, argv=3D0xbffff864,
> envp=3D0xbffff86c) at ftpd.c:715
> 
>   Examination of the registers shows that we have successfully
inserted
> the
>   intended address. As the address is not valid the ftp daemon seg
faults.
> 
>    <snip>
>    esi            0xdeadbeef       -559038737
>    edi            0xdeadbeef       -559038737
>    </snip>
> 
>   On giving the ftp daemon a valid address to free (In this case a
pointer
>   to syslog()) the daemon will continue to free() the address we gave
it #
>   where it again will segfault due to the address we gave it not being
a
>   valid malloc chunk.
> 
>    #0  0x400c6178 in free () at malloc.c:2952
>    #1  0x400f7989 in globfree () at ../sysdeps/generic/glob.c:1055
>    #2  0x8051b0b in yyparse () at ftpcmd.y:1138
>    #3  0x804b455 in main (argc=3D1094795585, argv=3D0xbffff864,
> envp=3D0xbffff86c) at ftpd.c:715
> 
>    ie (SuSE glibc-2.2/sysdeps/generic/glob.c):
>    glob.c:1097  if (pglob->gl_pathv[pglob->gl_offs + i] != NULL)
>    glob.c:1098    free ((__ptr_t) pglob->gl_pathv[pglob->gl_offs +
i]);
>    glob.c:1099  free ((__ptr_t) pglob->gl_pathv);
> 
>    Information on exploiting this form of vulnerability are available
at
>    http://www.phrack.org/show.php?p=57&a=9
> 
>    Legal:
>    This advisory is the intellectual property of Global InterSec LLC
>    but may be freely distributed with the conditions that:
>    a) no fee is charged and b) appropriate credit is given.
>    (c) Global InterSec LLC 2001
> --
> Unsubscribe: send email to listar at linuxfromscratch.org
> and put 'unsubscribe lfs-security' in the subject header of the
message
-------------- next part --------------
A non-text attachment was scrubbed...
Name: glibc-2.1.3-cvs-20011129-glob.diff
Type: application/octet-stream
Size: 1162 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-security/attachments/20011219/1919690f/attachment.obj>


More information about the lfs-security mailing list