Bugtraq mailing list archives

FW: Fscan advisory (fwd)


From: Dave Ahmad <da () securityfocus com>
Date: Wed, 1 May 2002 10:46:39 -0600 (MDT)


---------- Forwarded message ----------
Date: Wed, 1 May 2002 09:49:21 -0700
From: Foundstone Labs <labs () foundstone com>
To: da () securityfocus com
Subject: FW: Fscan advisory

Format string vulnerability in FScan 1.12
---------------------------------------------------------------------


Release Date: April 24, 2002
Product:  FScan
Type: Format string vulnerability
Author: Foundstone, Inc.
Operating Systems:  N/A
Vulnerable versions: FScan 1.12 and prior

Foundstone Advisory:  http://www.foundstone.com/advisories.htm

---------------------------------------------------------------------


Background
--------------------------------------
FScan is a free, unsupported TCP/UDP port scanning and banner grabbing tool for Windows, available for download from 
Foundstone; the last version (1.12) was released in August of 2000. FScan should not be confused with Foundstone's 
commercially available enterprise vulnerability management software, FoundScan, which is unaffected by this issue.

Problem Description
--------------------------------------


Using FScan with banner selected via the -b command line switch could cause a problem if the banner received from the 
remote host contained C-style printf format specifiers e.g. percent symbols that matched string or numeric format 
specifiers such as "%s" or "%d" etc.

When banner output to the command line is performed, the received data is placed in a stack buffer, replacing 
non-printable characters with 2-digit HEX equivalents (this has been changed in version 1.14 to show just dots '.' for 
non-printable characters). After the output string had been constructed a call to the "OutPrintf" function was made to 
display the string. OutPrintf is defined as a variable parameter type function in the style of printf.

void OutPrintf(const char *fmt,...)
{
char szBuffer[2048];
va_list list;
va_start(list, fmt);
_vsnprintf(szBuffer, sizeof(szBuffer), fmt, list);
va_end(list);


// zero-terminate the string in case it exceeded the buffer size
szBuffer[sizeof(szBuffer) - 1] = '\0';
fprintf(ghOutputFile, szBuffer);
...
}


The problem occurs on the last line shown where the string in szBuffer is sent directly to fprintf without specifying a 
"%s" format specified. If for example, the string in szBuffer contains the characters "%d" then fprintf will expect to 
find a number on the stack to format in the output. The same would happen if "%s" was found but in this case it would 
try to pull a zero terminated string off the stack to format.


The correct format for the fprintf command should have been:

fprintf(ghOutputFile, "%s", szBuffer);

to force the command to take szBuffer as a literal string instead of trying to parse format specifiers out of it.



Impact
--------------------------------------
An attacker could setup a service with a banner that contained exploit code to execute a format string overflow against 
the fscan.exe process on the scanning machine and possibly gain the privileges of the user conducting the scan.



Solution
--------------------------------------
Upgrade to FScan 1.14. FScan 1.14 is now available for download at http://www.foundstone.com/knowledge/zips/fscan114.zip



Credit
--------------------------------------
Foundstone would like to thank Peter Gründl prg () spamfilter dk for bringing this issue to our attention.



Disclaimer
--------------------------------------
The information contained in this advisory is the Copyright(c) 2002 of Foundstone, Inc. and believed to be accurate at 
the time of printing, but no representation or warranty is given, express or implied, as to its accuracy or 
completeness. Neither the author nor the publisher accepts any liability whatsoever for any direct, indirect or 
consequential loss or damage arising in any way from any use of, or reliance placed on, this information for any 
purpose. This advisory may be redistributed provided that no fee is assigned and that the advisory is not modified in 
any way.



Current thread: