re: slocate vulnerability

Date: 01/30/03

Date: Thu, 30 Jan 2003 11:58:32 -0800


Actually it isn't a buffer overflow at all. Slocate can be crashed with "slocate -r A -c A" as well, no need to feed 1024 A's.
If you had taken a look at the code instead of guessing from gdb backtraces, you could've wound up about here:
int j = optind;
int i = 0;
  while (SLOCATE_PATH && (database = SLOCATE_PATH[i++]))
    res |= decode_db(database, regexp_opt);
while (j < args) {
   /* while ((database = SLOCATE_PATH[i++])) res |= decode_db(database, argv[j++]);
    i = 0;
    * A Bug fix by Hans-Juergen Godau <>
    * Prevents segfault when using multiple databases */
   while (SLOCATE_PATH && (database = SLOCATE_PATH[i++]))
     res |= decode_db(database, argv[j]);
   i = 0; j += 1;
Where you would have noticed that if both a regular expression and normal search arguments are provided, variable i used as an index into SLOCATE_PATH is out of bounds after the regular expression search and thus the next loop will feed random values as string pointers to decode_db(). Which will fail the open, try to report the error and once of a sudden finds itself reading from non-mapped addresses. Which generates a nice protection fault.
So even though you can crash slocate, it is not a trivially exploitable buffer overflow, and it probably isn't exploitable at all.
The bug can be fixed by putting the i = 0; in the second loop before the inner SLOCATE_PATH loop, even though the way options are parsed might be reconsidered as well.

On Thu, 2003-01-30 at 16:02, wrote:
> The exploitation is trivial ,but with libsafe this buffer
> overflow doesn't work:
> (gdb) bt
> #0 0x0018fb88 in _IO_vfprintf (s=0xbffff6ec,
> format=0x804c215 "%s: decode_db(): %s: %s\n", ap=0xbffff854)
> at ../sysdeps/i386/i486/bits/string.h:530
> #1 0x0012b47c in _IO_vfprintf () from /lib/
> #2 0x001b1304 in _IO_vsnprintf (string=0x8056d28 "slocate: decode_db():
> ", maxlen=4096, format=0x804c215 "%s: decode_db(): %s: %s\n",
> args=0xbffff84c) at vsnprintf.c:130
> #3 0x0012b715 in vsnprintf () from /lib/
> #4 0x0804be26 in strcpy ()
> #5 0x0804ab5e in strcpy ()
> #6 0x0804b8e0 in strcpy ()
> #7 0x00154657 in __libc_start_main (main=0x804b340 <strcpy+9116>, argc=5,
> ubp_av=0xbffffad4, init=0x8048c1c <last_use+131884472>,
> fini=0x804bf50 <strcpy+12204>, rtld_fini=0x11dcd4 <_dl_fini>,
> stack_end=0xbffffacc) at ../sysdeps/generic/libc-start.c:129
> (gdb)
Version: Hush 2.2 (Java)
Note: This signature can be verified at


Concerned about your privacy? Follow this link to get
FREE encrypted email:

Big $$$ to be made with the HushMail Affiliate Program: to do with a vulerability?