EEYE: RealSecure/BlackICE Server Message Block (SMB) Processing Overflow
From: Marc Maiffret (mmaiffret_at_EEYE.COM)
Date: Thu, 26 Feb 2004 18:36:18 -0800 To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
RealSecure/BlackICE Server Message Block (SMB) Processing Overflow
February 26, 2004
February 18, 2004
High (Remote Code Execution)
Internet Security Systems
RealSecure Network 7.0, XPU 20.15 through 22.9
Real Secure Server Sensor 7.0 XPU 20.16 through 22.9
Proventia A Series XPU 20.15 through 22.9
Proventia G Series XPU 22.3 through 22.9
Proventia M Series XPU 1.3 through 1.7
RealSecure Desktop 7.0 eba through ebh
RealSecure Desktop 3.6 ebr through ecb
RealSecure Guard 3.6 ebr through ecb
RealSecure Sentry 3.6 ebr through ecb
BlackICE PC Protection 3.6 cbr through ccb
BlackICE Server Protection 3.6 cbr through ccb
The RealSecure and BlackICE product lines from Internet Security Systems
offer host-based intrusion detection/prevention for large servers and
home networks. By design, these products attempt to identify and block
network attacks and intrusions.
eEye Digital Security has discovered a critical vulnerability in both
RealSecure and BlackICE. The vulnerability allows a remote attacker to
reliably overwrite heap memory with user-controlled data and execute
arbitrary code within the SYSTEM context. This attack will succeed with
BlackICE using its most paranoid settings.
This specific flaw exists within the component that handles the
processing of Server Message Block (SMB) packets. By issuing an
authentication request with a long username value, a direct heap
overwrite is triggered, and reliable code execution is then possible.
An IDS/IPS system, by its very nature, requires that every packet
entering a system be parsed and dealt with accordingly. When BlackICE
and RealSecure encounter an SMB packet, the packet is analyzed,
processed and re-assembled. It is during this assembly phase that our
custom data is passed to an insufficiently sized heap-based buffer. All
processing is conducted before any authentication.
To successfully replicate this vulnerability only one SMB packet is
required. The client must issue an "SMB Session Setup AndX request".
This SMB is used to "set up" a session previously established with the
negotiate protocol. A primary function of this request is to perform a
user login to a remote host. As neither RealSecure nor BlackICE require
the state to be kept, no previous negotiation is required. To cause a
reliable heap overwrite, the AccountName parameter should contain a
string with a length of 300 bytes or greater.
Please refer to the SNIA Common Internet File System Technical Reference
detailed information on the required packet structures.
In the end, this vulnerability equates to a textbook heap overwrite
vulnerability, and code execution is effortless.
Retina Network Security Scanner has been updated to identify this
ISS have released patches for these issues. The patches are available
Retina Network Security Scanner - Free 15 Day Trial
Cathy, The Filthy Few (we'll make up for it in July), and, of course --
all of the eEye massive.
Copyright (c) 1998-2004 eEye Digital Security
Permission is hereby granted for the redistribution of this alert
electronically. It is not to be edited in any way without express
consent of eEye. If you wish to reprint the whole or any part of this
alert in any other medium excluding electronic medium, please e-mail
alert@eEye.com for permission.
The information within this paper may change without notice. Use of this
information constitutes acceptance for use in an AS IS condition. There
are NO warranties with regard to this information. In no event shall the
author be liable for any damages whatsoever arising out of or in
connection with the use or spread of this information. Any use of this
information is at the user's own risk.
Please send suggestions, updates, and comments to:
eEye Digital Security
NTBugtraq Editor's Note:
Most viruses these days use spoofed email addresses. As such, using an Anti-Virus product which automatically notifies the perceived sender of a message it believes is infected may well cause more harm than good. Someone who did not actually send you a virus may receive the notification and scramble their support staff to find an infection which never existed in the first place. Suggest such notifications be disabled by whomever is responsible for your AV, or at least that the idea is considered.