Thread-topic: AOL ICQ Pro 2003b heap overflow vulnerability
> -----Original Message-----
> From: CORE Security Technologies Advisories
> [mailto:advisories@xxxxxxxxxxxxxxxx]
> Sent: Thursday, September 07, 2006 11:47 PM
> To: Bugtraq; Vulnwatch; NTBUGTRAQ@xxxxxxxxxxxxxxxxxxxxxx
> Subject: CORE-2006-0321: AOL ICQ Pro 2003b heap overflow vulnerability
>
>
> Core Security Technologies - CoreLabs Advisory
>
>
> 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:
>
> n=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
> ().
>
> 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 .
>
>
> *References:*
>
> [1]
> [2]
> [3]
> [4]
> ;
> 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:
>
>
> *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
> .
>
> *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 $
>
>
