[LSD] Solaris cachefsd remote buffer overflow vulnerability

From: Last Stage of Delirium (contact@lsd-pl.net)
Date: 05/06/02


Date: Sun, 5 May 2002 20:32:23 -0700
From: Last Stage of Delirium <contact@lsd-pl.net>
To: bugtraq@securityfocus.com


Solaris cachefsd remote buffer overflow vulnerability

We would like to report another security vulnerability in the Solaris cachefsd
program, which allows remote root access to the vulnerable system. The following
information has been sent to Sun Microsystems some time ago, yet we have not
received any official response.

We have developed the proof of concept code for this vulnerability and it will
be published after release of appropriate patch.

Introduction

The cachefsd program is installed (and started) by default on all versions of
SUN's Solaris operating system starting from version 2.6. The purpose of this
program is to cache requests for operations on remote file systems mounted with
the use of NFS protocol. In the Solaris operating system, the cachefsd service
is installed as RPC service with a number 100235.

We have found that there exists a security vulnerability in the cachefsd
service, which can be remotely exploited to gain unauthorised access to
the system with administrative (root user) privileges.

Description of the vulnerability

The vulnerability found belongs to the so called class of "heap buffer
overflow" errors. It can be triggered by sending appropriate string argument
as the second parameter (cache name) of the 5th RPC function
cachefsd_fs_mounted_1_svc() of the cachefsd service. This function takes two
character strings as arguments. These are respectively the name of directory
to be mounted and a cache name. During further operation of
cachefsd_fs_mounted_1_svc() function, a call to subr_add_mount() is made as
it is responsible for servicing the request. The two forementioned string
parameters are also passed along with it as they will be used in a creation
of a new cachefs structure by the cfsd_fscache_create() function. As the new
cachefs structure is allocated (cfsd_calloc()) it is also filled with data,
and this is done with the use of passed directory name and cache name values.
Unfortunately this data initialisation is not safe as it is done by calling
strcpy() function. This leads to overwriting internal structures of memory
allocator and when properly exploited can change the execution path of a
vulnerable program so that a user provided machine code instructions will be
executed. Below you can see a detailed trace log from our bptrace tool,
which clearly illustratates the cachefsd execution path that leads to the
overflow condition.

breakpoint trace [version 1.4]
copyright by LAST STAGE OF DELIRIUM 1998 Poland
    found 340 symbols
    340 breakpoints enabled, 0 disabled, 0 aliases
==> attaching process 14548 (/usr/lib/fs/cachefs/cachefsd)
....
[14548] 0x00028ea4 1 xdr_cachefsd_fs_mounted()
[14548] 0x0003b324 1 xdr_string()
[14548] 0x0003b324 2 xdr_string()

---
[14548] 0x00016c58    1  cachefsd_fs_mounted_1_svc()
---
[14548] 0x0003b1c8    5  thr_getspecific()
[14548] 0x0002623c    5  db_debugon()
---
[14548] 0x00023c74    1  subr_add_mount()
---
[14548] 0x0003b1a4    8  free(0x00047e08)
[14548] 0x0003b000   21  mutex_unlock()
---
[14548] 0x000206a0    1  cfsd_fscache_create()
---
[14548] 0x00024c94   12  dbug_object_create()
[14548] 0x0003aff4   23  mutex_lock()
[14548] 0x00024b00    2  cfsd_calloc()
[14548] 0x0003b198   15  calloc(13920,1) -> 0x00067a38

[14548] 0x0003af10 27 strcpy(0x00067a38,"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAA")

After the above strcpy() function call, the chunk of memory allocator gets overwritten and this condition can be exploited at the next call to malloc() or free().

Best regards,

Members of LSD Research Group http://lsd-pl.net



Relevant Pages