bug-glibc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Is there a fix for the glob() and glibc vulnerability ?


From: Stephane Rozes
Subject: Is there a fix for the glob() and glibc vulnerability ?
Date: Tue, 18 Dec 2001 09:43:39 +0100

I work for Cert-IST, a french CERT which is a member of FIRST
(http://www.first.org).

Recent posts on Bugtraq mailing-list publically disclosed a security bug in
"glibc" (titled "[Global InterSec 2001121001] glibc globbing issues.") - see
the attached e-mail.

Yesterday, Red Hat released the security advisory "[RHSA-2001:160-09]
Updated glibc packages are available" about that problem.

We are not aware of any fix for that problem released by Glibc maintainer.
Is there a new version of "glibc" that fixes that bug ?

Thank you for your help

Regards

Stephane Rozes

Cert-IST
82 route de Bayonne
31300 TOULOUSE
FRANCE
Tel : +33 562 748 970
Fax : +33 561 495 482
E-mail : address@hidden
Web site : http://www.cert-ist.com

--- Begin Message --- Subject: [Global InterSec 2001121001] glibc globbing issues. Date: Tue, 18 Dec 2001 04:06:30 +0100
Global InterSec LLC
http://www.globalintersec.com

GIS Advisory ID:  2001121001
Changed:      12/12/2001
Author:          address@hidden
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 address@hidden 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.rpm
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.rpm
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.rpm
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.rpm
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.rpm

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.rpm
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.rpm
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.rpm
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

--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]