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
This archive was generated by hypermail 2b30 : Sun May 05 2002 - 21:59:01 PDT