lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <87ad8cog81.fsf@volatile.central.fluidsignal.com> From: aroldan at debian.org (Andrés Roldán) Subject: ltrace bug This seems to be fixed in the latest version: aroldan@...atile:~$ ltrace -V ltrace version 0.3.30. Copyright (C) 1997-2002 Juan Cespedes <cespedes@...ian.org>. This is free software; see the GNU General Public Licence version 2 or later for copying conditions. There is NO warranty. "Abhisek Datta" <abhisek@...uxmail.org> writes: > ********************************* > BFI Security Research Group > ********************************* > > Vulnerability: > ============== > A heap based buffer overrun bug is identified in ltrace 'Library Call Tracer' utility version 0.3.10-12 which allows execution of arbitrarty code with root privilage by corrupting the heap. > > Affected Versions: > ================= > So far now only tested version 0.3.10-12 on RedHat Linux 8 (2.4.18-14) seems to be vulnerable to this approach. > > Description: > ============ > There seems to exists a heap based buffer overflow vulenrability in ltrace utility version 0.3.10-12. Based on my research so far, I think the bug is in static char *search_for_command(char * filename) function in options.c . > > [root@...alhost codes]# rpm -qa |grep ltrace > ltrace-0.3.10-12 > [root@...alhost codes]# ltrace -V > ltrace version 0.3.11. > Copyright (C) 1997-1999 Juan Cespedes <cespedes@...ian.org>. > This is free software; see the GNU General Public Licence > version 2 or later for copying conditions. There is NO warranty. > [root@...alhost codes]# cp `which ltrace` ltrace > [root@...alhost codes]# ltrace ./ltrace `perl -e 'print "A"x6000'` > __libc_start_main(0x08049a40, 2, 0xbfff7f84, 0x08048f30, 0x08057644 <unfinished ...> > getpid() = 2487 > __cxa_atexit(0x08049cf0, 0, 0, 0x0805b860, 0x420aedf0) = 0 > signal(2, 0x08049c10) = NULL > signal(15, 0x08049c10) = NULL > getopt_long(2, 0xbfff7f84, "+dfiLSrthVCa:s:o:u:p:e:", 0x0805b060, 0xbfff6f08) = -1 > strchr("AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"..., '/') = NULL > getenv("PATH") = "/usr/local/sbin:/usr/local/bin:/"... > strchr("/usr/local/sbin:/usr/local/bin:/"..., ':') = ":/usr/local/bin:/sbin:/bin:/usr/"... > strncpy(0x0805b880, "/usr/local/sbin", 15) = 0x0805b880 > strcpy(0x0805b890, "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"... <unfinished ...> > --- SIGSEGV (Segmentation fault) --- > +++ killed by SIGSEGV +++ > > ltrace 0.3.11 src > ================== > options.c : > static char *search_for_command(char * filename) > { > static char pathname[1024]; > char *path; > int m, n; > if (strchr(filename, '/')) { > return filename; > for (path = getenv("PATH"); path && *path; path += m) { > if (strchr(path, ':')) { > n = strchr(path, ':') - path; > m = n + 1; > } else { > m = n = strlen(path); > strncpy(pathname, path, n); > if (n && pathname[n - 1] != '/') { > pathname[n++] = '/'; > strcpy(pathname + n, filename); /* Possible buffer overrun */ > if (!access(pathname, X_OK)) { > return pathname; > return filename; > } > > Seems like there is no bound checking for the length of filename which is passed as parameter to the function.Version 0.3.20 implements bound checking before for(path = getenv("PATH"); path && *path; path += m) and hence cannot be exploited this way. The exploitation of this bug doesnt appear to be a simple one and conventional heap based overun exploitation techniques probably wont work. > > by > Abhisek Datta > abhisek@...secure.com > > BFI Security Research Group > India > -- > ______________________________________________ > http://www.linuxmail.org/ > Now with e-mail forwarding for only US$5.95/yr > > Powered by Outblaze > > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.netsys.com/full-disclosure-charter.html -- Andres Roldan <aroldan@...ian.org> GPG Key-ID: 0xB29396EB -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20031007/38185e29/attachment.bin
Powered by blists - more mailing lists