The following security advisory is sent to the securiteam mailing list, and can
be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
The SecuriTeam alerts list - Free, Accurate, Independent.
Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html
- - - - - - - - -
AOL ICQ Pro Heap Overflow
------------------------------------------------------------------------
SUMMARY
The AOL/ <http://www.icq.com/> 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.
A vulnerability in AOL's ICQ Pro instant messenger client could lead to
denial of service attacks and remote compromise of systems running
vulnerable versions of the client.
DETAILS
Vulnerable Systems:
* AOL ICQ Pro version 2003b build #3916 and prior.
A heap overflow vulnerability was found in the ICQ Pro 2003b 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.
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.
Vendor Status:
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"
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.
ADDITIONAL INFORMATION
The original article can be found at:
<http://www.coresecurity.com/common/showdoc.php?idx=583&idxseccion=10>
http://www.coresecurity.com/common/showdoc.php?idx=583&idxseccion=10
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to:
list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to:
list-subscribe@securiteam.com
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any
kind.
In no event shall we be liable for any damages whatsoever including direct,
indirect, incidental, consequential, loss of business profits or special
damages.
