re: slocate vulnerability

From: tqa@hushmail.com
Date: 01/30/03


Date: Thu, 30 Jan 2003 11:58:32 -0800
To: vuln-dev@securityfocus.com
From: tqa@hushmail.com


-----BEGIN PGP SIGNED MESSAGE-----

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;
if (REGEXP)
  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 <godau@wi-inf.uni-essen.de>
    * 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, xbuggyx@libero.it 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/libsafe.so.2
> #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/libsafe.so.2
> #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)
-----BEGIN PGP SIGNATURE-----
Version: Hush 2.2 (Java)
Note: This signature can be verified at https://www.hushtools.com/verify

wlgEARECABgFAj45hGYRHHRxYUBodXNobWFpbC5jb20ACgkQrEuaaeyMVAUPhQCgoXCA
n2jF4OSj6O+ZIAIdA+/3cWsAn1M61yqKj7EZx2TvzxnoRXtSd8eE
=D37o
-----END PGP SIGNATURE-----

Concerned about your privacy? Follow this link to get
FREE encrypted email: https://www.hushmail.com/?l=2

Big $$$ to be made with the HushMail Affiliate Program:
https://www.hushmail.com/about.php?subloc=affiliate&l=427stiWhat to do with a vulerability?



Relevant Pages

  • Re: Advanced data structures
    ... igcd a b = igcd b ... int igcd ... commonality "an algorithm" not "the exploitation of a mathematical ... mod operation in language X, the above "algorithm" can be represented ...
    (comp.lang.c)
  • Re: [Full-disclosure] PHP: Calendar Buffer Overflow
    ... >Example exploitation: ... int year, month, day; ... The biggest string length I could get is 15 characters. ... Ubuntu Developer http://www.ubuntu.com ...
    (Full-Disclosure)