full-disclosure - ltrace bug

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

From: abhisek at linuxmail.org (Abhisek Datta)
Subject: ltrace bug

			*********************************
			   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