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>] [day] [month] [year] [list]
Message-ID: <20060531221047.GA21196@fbi.gov>
Date: Wed, 31 May 2006 18:10:47 -0400
From: bugtraq@....gov
To: bugtraq@...urityfocus.com
Subject: ishopcart cgi 0day and multiple vulnerabilities

Vendor: ishopcart inc
Vendor Site: ishopcart.com
Vendor Status: notified via telephone

While spending a night auditing I have found 2 buffer overflows and 1
directory traversal in the ishopcart cgi, which is written in C. 

The directory traversal is caused by how the cgi chooses to show pages.
If, for example, the CGI is tould to show an order form, the order
form's name is taken as argv[1] and opens this file and prints it, ie:

/cgi-bin/easy-scart.cgi?../../../../../../../etc/passwd

The first buffer overflow is in main()'s szTmp[100] variable. argv[1] is
placed in this variable through a sprintf, although no check is made on
the size of argv[1] before putting it in szTmp:

sprintf(szTmp,"%s",argv[1]);

The other buffer overflow (of which I have succesfuly exploited) lies in
main() also, but is overflowed in vGetPost(). char  szBuf[4000]; is
passed to vGetPost() under the circumstance that argv[1] contains
specific criteria. vGetPost() reads POST data until the word "Submit" is
encountered, doing absolutely no bounds checking on the ammount of data
supplied.

When notified via telephone, the author claimed to be in the process of
fixing these errors, and at the same time took ishopcart.com offline.
Provided is the exploit code that spawns a connect back shell. It has been tested both localy and remotely
and has proved to work 100%

The real issue lies in the fact that this is a shopping cart system.
Also, since this is a cgi script, apache forks before executing it and
hence does not die on unsuccessful attempts, meaning that combined with
a massive 4000 NOP buffer, brute forcing of the offset is possible
leading to a theoretical 100% probability of remote code execution.

The good news is that this program doesn't seem to be common. If you you
would like to view the site and the code, search 'ishopcart' on google
and click it's cached link, then hit the source code link and you'll see
easy-scart.c through easy-scart6.c (all, of which, are vulnerable)

--K-sPecial

View attachment "ishopcart-cgi-bof.c" of type "text/plain" (5868 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ