Buffer overflow in Network Monitor allows code execution (Patch
available)
------------------------------------------------------------------------


SUMMARY

Internet Security Systems (ISS) X-Force has discovered a buffer overflow 
vulnerability in Microsoft's Network Monitor utility. The vulnerability 
allows code to be executed on the remote computer with the privilege 
levels of the administrator.

DETAILS

Affected Versions: 
 -Microsoft Windows NT 4.0 Server, Terminal Server Edition, and
Enterprise 
Edition.
 -Windows 2000 Server, Advanced Server, and Datacenter Server
 -Microsoft Systems Management Server versions 1.2 and 2.0

Network Monitor is a network administration tool installed as an option 
with Microsoft Windows NT 4.0 and Windows 2000. Network Monitor allows 
administrators to monitor network traffic. This vulnerability affects
both 
basic and full versions of Network Monitor. The basic version is shipped 
with Windows NT 4.0 and Windows 2000 servers and allows an administrator 
to gather data sent directly to his or her computer. The full version of 
Network Monitor ships with Systems Management Server (SMS) and puts the 
network card into promiscuous mode where it can gather data sent over an 
entire network segment.

The vulnerability is caused by a remotely exploitable buffer overflow 
condition in one of Network Monitor's protocol parsers. A protocol
parser 
is a dynamic-link library (.dll) that identifies and analyzes protocols 
that have been used to send data over the network. Information about
these 
protocols appears when captured data is displayed in Network Monitor's 
Frame Viewer window. 

Each protocol that Network Monitor supports has a corresponding parser. 
When Network Monitor captures HTTP traffic, the HTTP parser interprets
the 
data for display. Network Monitor will crash or exit when malformed data 
is captured and parsed. This buffer overflow allows a remote attacker to 
gain privileged access and execute arbitrary code on any computer
running 
Network Monitor that displays this captured data. 

Recommendations:
Microsoft recommends that customers apply the following patches:

Microsoft Windows NT 4.0 Server and Windows NT 4.0 Server, Enterprise 
Edition: 
 <http://www.microsoft.com/Downloads/Release.asp?ReleaseID=25487> 
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=25487
 
Microsoft Windows 2000 Server, Advanced Server and Datacenter Server: 
 <http://www.microsoft.com/Downloads/Release.asp?ReleaseID=25485> 
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=25485
 
Microsoft Systems Management Server 1.2: 
 <http://www.microsoft.com/Downloads/Release.asp?ReleaseID=25505> 
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=25505
 
Microsoft Systems Management Server 2.0: 
 <http://www.microsoft.com/Downloads/Release.asp?ReleaseID=25514> 
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=25514

Detailed Information:
When a captured session is viewed in Network Monitor's user interface, a 
single line summary of protocol specific data is displayed. Analysis of
a 
selection of protocol specific libraries has identified a practice of 
utilizing insecure string handling functions creating numerous remote 
vulnerabilities.  The following examples illustrate specific problems 
identified by COVERT Labs research.

1) If a CIFS Browse Frame is delivered to UDP port 138, the function 
FormatBrowserSummary() is called within 'browser.dll'.  One specific
CIFS 
Browse Frame, "Become Backup", includes the name of the Browse Server to 
be promoted.  This information is extracted from the UDP datagram for 
inclusion in the single line summary.

The Browser Server name is passed to the WIN32 API function call 
OemToChar(), which translates a string from the OEM-defined character
set 
into either an ANSI or a wide-character string.  The OemToChar()
function 
stops converting characters when it encounters a null character.  The 
vulnerable FormatBrowserSummary() function in 'browser.dll' calls 
OemToChar(), converting the server name into a 255-byte character buffer 
on the stack. Because OemToChar() provides no bounds checking the stack 
can be overrun with arbitrary values.

2) If an SNMP request is received on UDP port 161, 'snmp.dll' is
called.  
The community name of the SNMP request is extracted from the datagram
for 
the protocol specific summary. The SNMP community name is copied into a 
stack buffer by 'snmp.dll' using the WIN32 function wsprintfA(). 
Because 
this function call does not provide adequate bounds checking, the stack 
may be overwritten.

3) If an SMB session is received on TCP port 139, 'smb.dll' is called.  
This parser contains two vulnerabilities.  If an SMB session with a long 
username or a long filename for a type C transaction is received,
Network 
Monitor will overwrite its stack frame via an unchecked wsprintfA() call 
in a manner similar to the vulnerability described in the SNMP parser.

Extracting control of the instruction pointer for each of these 
vulnerabilities can either be achieved by overwriting the return address 
and allowing the vulnerable functions to return or by overwriting the 
Structure Exception Handlers callback pointer and then causing an
invalid 
memory reference.

What's the scope of the vulnerability?
This is a buffer overrun vulnerability affecting a tool used by 
administrators to monitor their networks. If a malicious user sent a 
particular type of malformed data across a network segment that the 
administrator was monitoring, it could have either of two effects. In
the 
less serious case, the malformed data would cause the tool to fail when
it 
processed the data. In the more serious case, code of the malicious
user's 
choice could be made to run on the administrator's machine. 
The network-monitoring tool requires administrative privileges to run,
so 
if the vulnerability were exploited to run code on the machine, it would 
have complete control over the local machine. However, adhering to best 
practices would prevent the vulnerability from being exploited against a 
domain administrator. The tool only ships by default only on server 
products. 

What causes the vulnerability?
Several of the protocol parsers provided for Network Monitor have 
unchecked buffers. If an especially malformed data were sent over a 
network segment that the administrator was monitoring, it could 
potentially overrun the buffer and either cause the Network Monitor to 
fail, or cause code of the sender's choice to run on the machine in the 
administrator's security context. 

What is Network Monitor?
Network Monitor, also known as Netmon, is an administrative tool that's 
used to monitor network traffic. It enables an administrator to record
and 
analyze the data packets that traverse a network segment. Netmon is a 
useful tool for troubleshooting communications problems, or monitoring 
activities on the network. Administrative privileges are needed in order 
to use the tool. 
There are two versions of Netmon, and both are affected by the 
vulnerability. A basic version, informally referred to as Netmon Lite,
is 
delivered as part of Windows NT 4.0 and Windows 2000 server products. An 
advanced version, which we'll refer to here as the full version of
Netmon, 
is included as one of the management tools in Systems Management Server 
1.2 and 2.0. 

Both versions allow data to be captured and analyzed, but there are 
important differences between them. Netmon Lite only allows the 
administrator to record and analyze data sent directly to his machine.
In 
contrast, the full version of Netmon allows the administrator to record 
all data traversing the local network segment, regardless of what
machine 
it's addressed to. (It does this by putting the network interface into 
"promiscuous mode"). Also, by installing remote agents on other
machines, 
the full version allows the administrator to record and analyze data 
addressed directly to those machines, regardless of where on the network 
they reside. 

What's a protocol parser?
A protocol parser is a plug-in module for Netmon that knows how to 
interpret the data packets, or frames, for a particular protocol.
Suppose 
you received a frame of data and wanted to interpret it. One way to do 
this would be to read the initial part of the frame and identify the 
protocol in use, and then consult a reference that lists the size and 
meaning of each field in a frame from that protocol. Once you had this 
information, you could interpret the frame, but this clearly is a task 
that cries out for automation, and Netmon's protocol parsers are
designed 
to do this work. 
Netmon includes a collection of parsers, each of which knows how to 
interpret the frames for a particular protocol. Netmon provides parsers 
for more than 100 different protocols, depending on the version. Most 
parsers are not affected by the vulnerability, but a number of them are. 

What's the problem with the parsers?
Several of the parsers don't properly validate the data in a frame
before 
interpreting it. If a malicious user sent an especially malformed frame
to 
a machine that was monitoring network traffic, and the administrator 
processed it using an affected parser, either of two outcomes could
occur. 
If the malformed part of the frame contained random data, it would cause 
Netmon to fail. However, if it contained carefully selected data, it
could 
allow code of the malicious user's choice to run on the administrator's 
machine. 

Would the malicious user need to send the malformed frame directly to
the 
machine that was running Netmon, or could he just put it onto the
network 
segment?
If the administrator were running Netmon Lite, the malicious user would 
need to send the data directly to the specific machine. However, if the 
administrator were running the full version of Netmon, the malicious
user 
would only need to send the malformed frame to an address on the same 
network segment, or to a machine on which a remote agent was installed. 

Would this vulnerability enable a malicious user to attack the 
administrator the moment he began monitoring the network?
No. It's important to understand that the vulnerability lies in the 
parsers, not in Netmon itself. Parsers can only be used to interpret
data 
that has been "delay captured" - that is, captured for later analysis.
The 
parsers cannot be used to interpret data in real time. As a result, if
an 
administrator was using Netmon for tasks other than data capture and 
analysis, the vulnerability would pose no threat. 

If the vulnerability were exploited to cause Netmon to fail, what would
be 
needed to resume normal operation?
The administrator would just need to restart Netmon. It would not be 
necessary to restart the machine. 

If the vulnerability were exploited to cause the malicious user's code
to 
run on the administrator's machine, what could it do?
Netmon requires administrative privileges to run, so it would be certain 
that the code could gain these privileges. Thus, at a minimum, the code 
would gain local administrator privileges and would have complete
control 
over the local machine. 
If the person running Netmon was a domain administrator, his code could 
gain complete control over the entire domain. However, security best 
practices recommend against ever using the domain Administrator account 
for anything other than domain management functions, and if this 
recommendation has been followed, an administrator would use Netmon in
the 
local, rather than domain, administrative context. 

Would the malicious user be able to tell when the administrator was
using 
Netmon?
He would be able to tell if the administrator was using the full version 
of Netmon, as it transmits a multicast packet when it puts the network 
interface into promiscuous mode. The malicious user would just need to 
write an application that watched for the multicast packet and recorded 
what machine transmitted it. 
It would be more difficult for the malicious user to determine whether 
someone was running Netmon Lite, as it doesn't put the network interface 
into promiscuous mode, and as a result doesn't send a multicast packet. 
Netmon Lite does provide one way to tell if it's running - if another 
machine is running Netmon Lite, it can send a query to determine whether 
any other machines on the same network segment are also running it. This 
means that the malicious user could determine if someone was running 
Netmon Lite, but only if he already had administrative control of a
server 
on the same network segment as the administrator. 

Could this vulnerability be remotely exploited?
A properly configured firewall - one that prevents an outside user from 
delivering packets to a specific internal network address - would
prevent 
this vulnerability from being exploited by an Internet user. 

Who should use the patch?
Microsoft recommends that the patch be installed on the following 
machines: 
 - All Windows NT 4.0 or Windows 2000 server products, as Netmon Lite 
ships as part of these products. Netmon Lite does not ship as part of
any 
workstation products. 
 - Any machine on which the full version of Netmon has been installed -- 
that is, any machine on which SMS has been installed. SMS can be
installed 
on either servers or workstations, and the patch should be applied to
any 
machine that it has been installed on. 

I'm running SMS on an affected server product. Do I need to install both 
the SMS and the operating system patch?
No. If you're running SMS, you only need to apply the SMS patch. If
you're 
not running SMS, you need to apply the patch for the version of the 
operating system you're using. 

What does the patch do?
The patch provides a new set of parsers that do not have the unchecked 
buffer at issue here. 

How do I use the patch?
Knowledge Base article  
<http://www.microsoft.com/technet/support/kb.asp?ID=274835> Q274835 
contains detailed instructions for applying the patch to your site.

How can I tell if I installed the patch correctly?
Knowledge Base article  
<http://www.microsoft.com/technet/support/kb.asp?ID=274835> Q274835 
provides a manifest of the files in the patch package. The easiest way
to 
verify that you've installed the patch correctly is to verify that these 
files are present on your computer, and have the same sizes and creation 
dates as shown in the KB article.


ADDITIONAL INFORMATION

The information has been provided by  <mailto:[EMAIL PROTECTED]> X-Force,  
<mailto:[EMAIL PROTECTED]> COVERT Labs and 
<mailto:[EMAIL PROTECTED]> 
Microsoft Product Security.


--
Eko Sulistiono
MIKRODATA & AntiVirus Media
Web: http://www.mikrodata.co.id/
WAP: http://www.mikrodata.co.id/wap/index.wml

This message contains no viruses. Guaranteed by AVP.


------------------------------------------------------------------------
Forum Komunikasi Penulis-Pembaca MIKRODATA (FKPPM)

Informasi : http:[EMAIL PROTECTED]
Arsip     : http://www.mail-archive.com/forum%40mikrodata.co.id/
WAP       : http://mikrodata.co.id/wap/index.wml

Milis ini menjadi kontribusi beberapa rubrik yang diasuh tim MIKRODATA.
Termasuk rubrik-rubrik yang ada di media lain.

Memakai, Menyebarluaskan, dan Memperbanyak software bajakan adalah 
tindakan kriminal.

Please check with the latest AVP update before you ask about virus:
ftp://mikrodata.co.id/avirus_&_security/AntiViral_Toolkit_Pro/avp30.zip

Kirim email ke