slocate Buffer Management Error May Let Local Users Gain Elevated Privileges
SecurityTracker Alert ID: 1007888|
SecurityTracker URL: http://securitytracker.com/id/1007888
(Links to External Site)
Updated: Jan 20 2004|
Original Entry Date: Oct 6 2003
Disclosure of system information, Disclosure of user information, Execution of arbitrary code via local system, User access via local system|
Fix Available: Yes Vendor Confirmed: Yes |
Version(s): 2.6 and prior versions|
A buffer management vulnerability was reported in slocate. A local user may be able to gain elevated privileges on the target system.|
Patrik Hornik reported that a heap overflow may let a local user execute arbitrary code with 'slocate' group privileges. The flaw reportedly resides in 'main.c', where some dynamically allocated memory may not be properly freed.
A local user may be able to cause arbitrary code to be executed with set group id (setgid) 'slocate' privileges. With those privileges, the local user can view a list of all files on the system.|
According to the report, slocate version 2.7 is not vulnerable.|
Vendor URL: www.geekreview.org/slocate/ (Links to External Site)
Boundary error, State error|
Linux (Any), UNIX (Any)|
This archive entry has one or more follow-up message(s) listed below.|
Source Message Contents
Date: Mon, 6 Oct 2003 20:10:47 +0200|
Subject: SA-20031006 slocate vulnerability
-----BEGIN PGP SIGNED MESSAGE-----
Security advisory 20031006
Vulnerability type: buffer overflow (corrupt heap)
Extended type: possibly gaining elevated privileges
Issue date: 2003/10/06
Last updated: 2003/10/06
Mr. Hornik has discovered buffer overflow vulnerability in slocate
version 2.6. Many Linux distributions have their slocate package based
on this version. We found at least RedHat package to be vulnerable.
The vulnerability corrupts heap management structures and possibly
leads to gaining slocate group privileges, which allows reading global
slocate database and thus obtaining list of all files in the system by
Program slocate works on user supplied database with setgid to slocate
group. With user prepared slocate database one can cause (we are
reffering to source lines from slocate-2.6-1.src.rpm from RH 7.3) that
pathlen after executing main.c:1255 will have value -1. It must be
caused by not the first path in the database because it is verified in
validate_db. Then on line main.c:1275 the last byte of memory block
header (this memory block size) will be overwritten with user suplied
value. The codedpath is never freed by the code, but it is possible to
trigger realloc on line 1269 later by data in database.
Because of not freeing some dynamic memory, using multiple databases
and multiple search patterns it should be possible to prepare heap
before triggering this vulnerability to allow later execution of
arbitrary code, thus gaining slocate group privileges. This allows
reading of global slocate database with list of all files in the
system by unauthorized user. The exploit is not available at this
Suggested and correct patch is to change condition on line 1263 to
pathlen <= 0.
Who is affected?
Affected are all RedHat distributions up to version 9.0 including.
slocate version 2.6 and below is vulnerable. slocate version 2.7 and
all packages based on this version are not vulnerable.
We recommend to upgrade slocate package to the fixed version.
If obtaining the list of all files on the system by unauthorized user
is security risk for your system we recommend to remove slocate
database and disable automatic generation of this database (as daily
cron job) or remove slocate utility or generate database only from
safe files until fixed version is installed.
This security advisory:
Phone: +421 905 385 666
PGP KeyID: DFA5BC67
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.0.2i
-----END PGP SIGNATURE-----