The vulnerable system is bound to the network stack and the set of possible attackers extends beyond the other options listed below, up to and including the entire Internet. Such a vulnerability is often termed “remotely exploitable” and can be thought of as an attack being exploitable at the protocol level one or more network hops away (e.g., across one or more routers). An example of a network attack is an attacker causing a denial of service by sending a specially crafted TCP packet across a wide area network (e.g., CVE-2004-0230).
Attack Complexity
Low
AC
The attacker must take no measurable action to exploit the vulnerability. The attack requires no target-specific circumvention to exploit the vulnerability. An attacker can expect repeatable success against the vulnerable system.
Privileges Required
None
PR
The attacker is unauthenticated prior to attack, and therefore does not require any access to settings or files of the vulnerable system to carry out an attack.
User Interaction
None
UI
The vulnerable system can be exploited without interaction from any human user, other than the attacker. Examples include: a remote attacker is able to send packets to a target system a locally authenticated attacker executes code to elevate privileges
Scope
Unchanged
S
An exploited vulnerability can only affect resources managed by the same security authority. In the case of a vulnerability in a virtualized environment, an exploited vulnerability in one guest instance would not affect neighboring guest instances.
Confidentiality
None
C
There is no impact on the confidentiality of the system; the attacker does not gain the ability to read any data.
Integrity
None
I
There is no impact on the integrity of the system; the attacker does not gain the ability to modify any files or information on the target system.
Availability
High
A
There is a total shutdown of the affected resource. The attacker can deny access to the system or data, potentially causing significant loss to the organization.
Core Security Technologies - CoreLabs Advisory
http://www.coresecurity.com/corelabs/
AOL ICQ Pro 2003b heap overflow vulnerability
Date Published: 2006-09-07
Last Update: 2006-09-06
Advisory ID: CORE-2006-0321
Bugtraq ID: None currently assigned
CVE Name: None currently assigned
Title: AOL ICQ Pro 2003b heap overflow vulnerability
Class: Boundary Error Condition
Remotely Exploitable: Yes
Locally Exploitable: Yes
Advisory URL:
http://www.coresecurity.com/index.php5?module=ContentMod&action=item&id=
1509
Vendors contacted:
America Online Inc.
. 2006-07-27: Initial notification sent to vendor, advisory release
date set for Aug. 14th.
. 2006-07-27: Vendor response acknowledging notification.
. 2006-08-11: Request for an update sent to vendor asking for an
estimated date for fix availability.
. 2006-08-14: Request for an update sent to vendor asking for an
estimated date for fix availability, advisory release date now set
for Aug. 22nd.
. 2006-08-15: Vendor response received. Still determining when a fix
will be available. A new update from the vendor forthcoming before
Aug. 22nd.
. 2006-08-16: Vendor email received requesting further technical details
or proof-of-concept code.
. 2006-08-17: Core response vendor: proof-of-concept for the ICQ client
bug can not be made available as standalone program without incurring
in a substantial development effort.
. 2006-08-21: Vendor email describing coordination issues with ICQ
development team. No fix schedule provided
. 2006-08-17: Core response vendor: proof-of-concept can not be made
available as standalone program without incurring in a substantial
development effort.
. 2006-08-21: Vendor email describing coordination issues with ICQ
development team. No fix schedule provided.
. 2006-08-21: In liue of proof-of-concept, Core provides succinct
technical explanation of the problem in the ICQ 2003b client.
. 2006-08-29: Updated advisory sent to vendor requesting comments and
fix availability information. Advisory release date now set for
Aug. 31st.
. 2006-08-30: Vendor response received stating that 30 days is
insufficient to fix bugs and reiterating the previously noted
coordination and communications problems with engineering team at
remote facilities. No tentative fix schedule made available, earliest
date for an official vendor statement about fixes is Sept. 1st
. 2006-08-30: Core response to vendor, publication of advisories will be
delayed until Sept. 6th in order to receive offical statement from
vendor. Baring a precise schedule that demonstrates an imminent
release of fixes the publication date is final.
. 2006-08-30: Vendor provides an official statement.
. 2006-09-07: Advisory published.
Release Mode: USER RELEASE
*Vulnerability Description:*
A vulnerability in AOL's ICQ Pro 2003b instant messenger client could
lead to denial of service attacks and remote compromise of systems
running vulnerable versions of the client.
The AOL/Mirabilis ICQ client is a popular Instant Messaging (IM) program
that enables users to communicate through instant messaging, chat,
e-mail, SMS and wireless-pager messages as well as transferring files
and URLs, among other features.
In 1998 America Online Inc. acquired Mirabilis Ltd., the company
responsible for the development of the ICQ instant messenger and all
associated services at that time. [1] Since then, AOL's ICQ unit
continued to develop and maintain the ICQ client program.
The ICQ Pro2003b client was officially launched on October 30th, 2003
and included capabilities to interoperate with AOL's Instant Messenger
AIM) and AOL services. The press release with the ICQ Pro 2003b
announcement indicated that, at the time, ICQ had over 160 million
registered users that spent - when connected - an average of 4.5 hours
on the service. [2]
The latest release of this particular IM client, ICQ Pro 2003b Build
#3916, is still one of the officially available options for users who
want to download an ICQ client from ICQ?s website (http://www.icq.com).
Even though by its name the IM client may seem to be a "veteran" client,
the ICQ team has been updating it up until -at least- Build #3916
released on October 2005. [3]
A vulnerability found in the way the ICQ Pro 2003b client handles
incoming message lengths could lead to denial of service attacks and
remote compromise of systems running vulnerable versions of the client.
Attacks that leverage this vulnerability would be difficult to identify
and isolate as exploit traffic does not present any features that makes
it easily distinguishable from normal IM communications.
*Vulnerable Packages:*
The following AOL/ICQ software products are affected by this issue:
- ICQ Pro 2003b Build #3916 and previous.
*Non-vulnerable Packages:*
- ICQ 5.1
- ICQ2Go!
*Solution/Vendor Information:*
Statement provided by AOL Product Vulnerabilities team:
"AOL has recently been made aware of a vulnerability in the ICQ 2003b
client build #3916. Successful exploitation of the vulnerability may
allow an attacker to remotely execute commands.
AOL and ICQ recommend that users upgrade to the latest version of the
ICQ client: ICQ 5.1"
*Credits:*
Luciana Tabo, Lucas Lavarello, Sebastian Cufre, Ezequiel Gutesman and
Javier Garcia Di Palma from Core Security Technologies discovered and
tested this vulnerability during Bugweek 2006.
This vulnerability was found using synaptic-based fuzzing.
*Technical Description - Exploit/Concept Code:*
A heap overflow vulnerability was found in the ICQ Pro 2003b build #3916
IM client. The problem derives from the way the vulnerable client
handles the length of a specific type of message received from other
clients.
The ICQ protocol supports exchange of IM messages both using servers as
well as with direct client-to-client connections, where data is sent
without a need for an intermediate ICQ server to process it.
The vulnerability was tested using the client-server-client model,
presenting a high-risk scenario since exploitation does not require the
establishment of a direct client-to-client connection with the victim
system. In the tested case, ICQ communications servers will pass
malicious traffic to unsuspecting clients without inspecting it first
and without enforcing strict sanity checks on the data fields.
To understand the technical description that follows, a few terms from
common ICQ message communication terminology will be defined:
FLAP: A 6 bytes structure, used to identify the channel (login[1],
connected[2], errors[3], logout[4], ...) for the packet being sent.
It also contains a sequence number and the length of the whole packet.
SNAC: A 10 bytes header used to identify the purpose of the packet.
SNACs identify packet types through a family type (Word) as well as a
SubType (Word).
TLV: Type-Length-Value, a container structure where the first two fields
are a Type (Word) and a Length (Word), followed by the data.
LNTS: A null terminated string preceded by a word (Little Endian),
indicating the length of the NTS, including the terminating null
character.
The vulnerability is triggered when a specific packet is received by a
vulnerable client on FLAP Channel 2, the channel in which most of the
packets are sent during a successful connection.
There are 3 main types of messages at the time of exchanging data
between ICQ clients when communicating through servers:
[Type 1] - Simple, plaintext messages.
[Type 2] - Messages, extended to support rtf, colors, etc.
[Type 4] - Utility messages, used for URLs, contacts, etc..
The issue resides inside a Type 2 message. Messages are stored inside
the Channel 2 FLAP with a SNAC of family-type 4, subtype 6.
Here is the outlook of ICQ communications packet so far:
[FLAP channel 2
[ SNAC type 4 - subtype 6
[message type 2]
]
]
There are two other encapsulation layers within the described packet
that need to be inspected in order to identify malicious data that could
trigger or exploit the described bug. Inside the Type 2 Message, a TLV
of Type 5 will include a set of information such as client capabilities
and sequence numbers. These are split in different Sub-TLVs within the
type 5 TLV (carried within a Type-2 message of SNAc type4, subtype 6).
There is one Sub-TLV in particular that we want to look at: TLV Type
0x2711.
TLV Type 0x2711 will hold, among other things, a Message structure that
includes LNTs.
So, let's look at an updated version of the previous outline:
[FLAP channel 2
[ SNAC type 4 - subtype 6
[message type 2
...
[ TLV type 5
...
[TLV type 0x2711
....
[Message - LNTS ]
]
]
]
]
]
It is inside the TLV type 0x2711 where a LNTS field resides with the
contents of the [Message]. AS explained above, the first word of a LNTS
determines the length of the message, followed by a null-terminated
string.
The ICQ Pro 2003b client does not perform any sanity check on this
length field and does not compare it to the actual size of the 0x2711
TLV or the size of the entire received packet. Unlike with other packet
fields, an intermediate server does not perform any sanitation on the
contents of this field either and therefore passes potentially malformed
data to connected clients, making a fully controllable attack vector
available to using potentially malicious IM client programs.
The nature of the bug can be understood by attaching a debugger to the
ICQ Pro 2003b client and tracing down the issue to find the problem
inside a routine called ?MCRegEx__Search?, which calls memset to clear
the contents of a heap allocated buffer, directly using our length field
(described above) as the third argument to the memset function. [4]
The following short disassembly should provide more detail:
First breakpoint is set inside ICQCUtl!ReadStringBCStreamFormat:
20002108 ff152cb00020 call dword ptr [ICQCUtl!MCRegEx__Search+0x89d4
(2000b02c)]{ICQRT!Ordinal360 (21382b39)} ds:0023:2000b02c=21382b39
The reason the initial breakpoint is set inside ReadStringBCStreamFormat
is because MCRegEx__Search is constantly called from several different
locations.
It is inside this routine that a call to ICQRT!Ordinal116+0x1af ends up
calling memset and using our length value directly:
213821ea 0fbe442414 movsx eax,byte ptr [esp+0x14]
213821ef 53 push ebx (length specified in the LNTS)
213821f0 50 push eax (character being written, 0)
213821f1 8b4604 mov eax,[esi+0x4]
213821f4 034608 add eax,[esi+0x8]
213821f7 50 push eax (destination buffer)
213821f8 e8b5300000 call ICQRT!Ordinal116+0x1af (213852b2)
ICQRT!Ordinal116+0x1af is the stub for memset that contains a direct
jmp to the msvcrt.
*Workaround:*
Switch to ICQ 5.1, which is (at the moment of writing the advisory) the
latest build for the alternative non-vulnerable ICQ official client.
ICQ 5.1 is available at http://www.icq.com.
*References:*
[1] http://www.icq.com/info/press/press_release26.html
[2] http://www.icq.com/info/press/press_release51.html
[3] http://www.icq.com/download/pro/
[4] http://www.openbsd.org/cgi-bin/man.cgi?query=memset&apropos=0&sektion=3&
manpath=OpenBSD+Current&arch=i386&format=html
*About CoreLabs*
CoreLabs, the research center of Core Security Technologies, is charged
with anticipating the future needs and requirements for information
security technologies.
We conduct our research in several important areas of computer security
including system vulnerabilities, cyber attack planning and simulation,
source code auditing, and cryptography. Our results include problem
formalization, identification of vulnerabilities, novel solutions and
prototypes for new technologies.
CoreLabs regularly publishes security advisories, technical papers,
project information and shared software tools for public use at:
http://www.coresecurity.com/corelabs/
*About Core Security Technologies*
Core Security Technologies develops strategic solutions that help
security-conscious organizations worldwide. The company?s flagship
product, CORE IMPACT, is the first automated penetration testing product
for assessing specific information security threats to an organization.
Penetration testing evaluates overall network security and identifies
what resources are exposed. It enables organizations to determine if
current security investments are detecting and preventing attacks.
Core augments its leading technology solution with world-class security
consulting services, including penetration testing, software security
auditing and related training.
Based in Boston, MA. and Buenos Aires, Argentina, Core Security
Technologies can be reached at 617-399-6980 or on the Web at
http://www.coresecurity.com.
*DISCLAIMER:*
The contents of this advisory are copyright (c) 2006 CORE Security
Technologies and (c) 2006 CoreLabs, and may be distributed freely
provided that no fee is charged for this distribution and proper credit
is given.
$Id: icq2003b-advisory.txt,v 1.15 2006/09/07 19:35:53 carlos Exp $
This information is provided for TESTING and LEGAL RESEARCH purposes only. All trademarks used are properties of their respective owners. By visiting this website you agree to Terms of Use and Privacy Policy and Impressum