Locate Utility (/usr/bin/locate) on Slackware Linux May Allow Certain Local Users to Obtain Elevated Privileges, Incluing Root Level Privileges
SecurityTracker Alert ID: 1002127|
SecurityTracker URL: http://securitytracker.com/id/1002127
(Links to External Site)
Date: Aug 2 2001
Execution of arbitrary code via local system, Root access via local system, User access via local system|
Exploit Included: Yes |
Version(s): part of findutils-4.1 and prior versions|
A vulnerability was reported with the /usr/bin/locate utility that allows any local user with 'nobody' user privileges to potentially obtain elevated privileges, including root level privileges|
It is reported that a local user with 'nobody' privileges (uid nobody) can modify the locate database and insert a trojan so that when another user (such as root) executes the locate function, the trojan code will be unknowingly executed, giving the local user access to the executing user's privileges.
It is reported that locate accepts old format databases. LOCATEDB_OLD_ESCAPE (char 30) is followed by an offset, stored in a signed integer, that indicates the number of characters to add to the current character pointer in the path. No sanity checking is performed on the input. As a result, a local user can move the pointer back past the beginning of the string to the GOT address for exit() and can then add the address of some arbitrary shellcode. This will cause the arbitrary shell code to be executed whenever a user runs 'locate'.
Demonstration exploit code is included in the Source Message (it is Base64 encoded).
A local user with 'nobody' user privileges can cause arbitrary code to be executed by other users that execute the 'locate' utility. The code will run with the privileges of the user calling the 'locate' utility, which could include a root user.|
No solution was available at the time of this entry.|
Input validation error|
|Underlying OS: Linux (Slackware)|
Source Message Contents
Subject: Slackware 8.0, 7.1 Vulnerability: /usr/bin/locate|
Content-Type: TEXT/PLAIN; charset=US-ASCII
Submitted by : Josh (firstname.lastname@example.org), lockdown
(email@example.com), zen-parse (firstname.lastname@example.org)
Vulnerability : /usr/bin/locate (findutils-4.1 and before)
Tested On : Slackware 8.0, Slackware 7.1
Local : Yes
Remote : No
Fix : Update to slocate
Target : root or any other user that runs locate
Requires : UID nobody
Greets to : alpha, fr3n3tic, omega, eazyass, Remmy, RedPen, banned-it,
slider, cryptix, s0ttle, xphantom, qtip, tirancy,
Defiance, KraZee, synexic, Insane, rusko,
Other Stuff : We all (individually) need jobs. E-mail the contact
people with [WE HAVE A JOB FOR YOU] in the subject.
In slackware, and possibly other distributions, it is possible to
modify the locate database if one were to obtain UID nobody. This allows
locate to act as a sort of 'trojan' having anyone who executes it
unknowingly execute potentially malicious code.
It works by taking advantage of the fact locate accepts old
format databases. LOCATEDB_OLD_ESCAPE (char 30) is followed by an offset,
stored in a signed integer, for how many characters to add to the current
character pointer in the path. It doesn't perform any sanity checking of
the input. This exploit tells it to move the pointer back a long way,
back past the beginning of the string, all the way to the GOT address for
exit() which then gets the address of the shellcode added, and the
program then runs out of database and executes our code.
There is also probably a similar vulnerability in the new format.
P.S. dies: If you see this e-mail email@example.com
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="locate-exploit.c"
Content-Disposition: attachment; filename="locate-exploit.c"
Go to the Top of This SecurityTracker Archive Page