Date: Fri, 04 May 2007 21:28:22 +0200
From: Reversemode <advisories@...ersemode.com>
To: Securityfocus <bugtraq@...urityfocus.com>
Cc: Marvin Frick <spiderfrick@....de>
Subject: Re: iDefense Security Advisory 04.30.07: Cerulean Studios Trillian
 Multiple IRC Vulnerabilities


Hi,

You are right Marvin.  There is a lot more behind the scenes.
There is a funny flaw in the way Trillian handles certain UTF series in
the Talk Window, so the flaw affects almost every protocol supported by
Trillian.

Summing up the problem:

Trillian (talk module) allocates a fixed amount of heap memory for
storing a line which, after being parsed, will be displayed on the talk
Box. The size reserved is determined by the width of the window
(GetClientRect) where you are chatting.

This reasoning is valid if you think in  "visible" characters and the
width in a ratio such as "1:4",I mean one ascii character will always
need a bounding box (x:y)  greater than 1x1 to fit onto, i.e at least 4x4.
Thus, a buffer of 200 bytes is always enough (Rect.width = 200) for
copying  a line of ascii characters without having to calculate how many
bytes we really need. This is the idea (more or less). Not very secure
but works so everything ok.

However, this assumption becomes a potential (real indeed) risk while
handling UTF series. In terms of "visible" characters you could reduce (
or expand ) a specially crafted UTF string of three hundred bytes to
just a few "visible" characters  displayed on the box. Moreover, if the
parser is, say, "weak", you get a remote heap overflow screaming "Hey!
I'm here! don't you see me?".

I'm not the original discoverer of this flaw, just some time ago a
person came up requesting my opinion about why Trillian was crashing and
well,you know...


Cheers,
Rubén.

------------
Reversemode
Advanced Reverse Engineering Services
www.reversemode.com

Marvin Frick wrote:
> Hi there,
> 
> this is my first mail to a mail list at all and additionally my
> English is not as perfect as it should be... i know.
> 
> I verified this overflow vulnerability and found some interesting
> facts coming along with that.
> If you try to copy a very very long URL to a conversation window (ICQ
> and MSN  work as well as IRC) the application will end up in a denial
> of service situation.
> 
> iDefense Labs only reported their issue only to the IRC module but I
> think this should work with all the other modules too.
> 
> 
> greetings from Germany,
> Marvin Frick
> 
> iDefense Labs wrote:
>>> Cerulean Studios Trillian Multiple IRC Vulnerabilities
>>>
>>> iDefense Security Advisory 04.30.07
>>> http://labs.idefense.com/intelligence/vulnerabilities/
>>> Apr 30, 2007
>>>
>>> I. BACKGROUND
>>>
>>> Cerulean Studios Trillian is a multi-protocol chat application that
>>> supports IRC, ICQ, AIM and MSN protocols. More information can be found
>>> on the vendor's site at the following URL.
>>>
>>> http://www.ceruleanstudios.com/learn/
>>>
>>> II. DESCRIPTION
>>>
>>> Remote exploitation of multiple vulnerabilities in the Internet Relay
>>> Chat (IRC) module of Cerulean Studios' Trillian could allow for the
>>> interception of private conversations or execution of code as the
>>> currently logged on user.
>>>
>>> When handling long CTCP PING messages containing UTF-8 characters, it is
>>> possible to cause the Trillian IRC client to return a malformed response
>>> to the server. This malformed response is truncated and is missing the
>>> terminating newline character. This could allow the next line sent to
>>> the server to be improperly sent to an attacker.
>>>
>>> When a user highlights a URL in an IRC message window Trillian copies
>>> the data to an internal buffer. If the URL contains a long string of
>>> UTF-8 characters, it is possible to overflow a heap based buffer
>>> corrupting memory in a way that could allow for code execution.
>>>
>>> A heap overflow can be triggered remotely when the Trillian IRC module
>>> receives a message that contains a font face HTML tag with the face
>>> attribute set to a long UTF-8 string.
>>>
>>> III. ANALYSIS
>>>
>>> Exploitation of this vulnerability allows remote attackers to intercept
>>> private communications for Trillian IRC users or execute code with the
>>> credentials of the currently logged on user.
>>>
>>> In order to exploit the highlighted URL vulnerability, users would have
>>> to highlight the malicious URL.
>>>
>>> IV. DETECTION
>>>
>>> iDefense has confirmed the existence of this vulnerability in Cerulean
>>> Studios Trillian 3.1.
>>>
>>> V. WORKAROUND
>>>
>>> iDefense is currently unaware of any effective workaround for this
>>> issue.
>>>
>>> VI. VENDOR RESPONSE
>>>
>>> Cerulean Studios has addressed these vulnerabilities within version
>>> 3.1.5.0 of Trillian. For more information, visit their blog at the
>>> following URL.
>>>
>>> http://blog.ceruleanstudios.com/
>>>
>>> VII. CVE INFORMATION
>>>
>>> A Mitre Corp. Common Vulnerabilities and Exposures (CVE) number has not
>>> been assigned yet.
>>>
>>> VIII. DISCLOSURE TIMELINE
>>>
>>> 01/24/2007  Initial vendor notification
>>> 01/30/2007  Initial vendor response
>>> 04/30/2007  Coordinated public disclosure
>>>
>>> IX. CREDIT
>>>
>>> These vulnerabilities were reported to iDefense by enhalos.
>>>
>>> Get paid for vulnerability research
>>> http://labs.idefense.com/methodology/vulnerability/vcp.php
>>>
>>> Free tools, research and upcoming events
>>> http://labs.idefense.com/
>>>
>>> X. LEGAL NOTICES
>>>
>>> Copyright © 2007 iDefense, Inc.
>>>
>>> Permission is granted for the redistribution of this alert
>>> electronically. It may not be edited in any way without the express
>>> written consent of iDefense. If you wish to reprint the whole or any
>>> part of this alert in any other medium other than electronically,
>>> please e-mail customerservice@...fense.com for permission.
>>>
>>> Disclaimer: The information in the advisory is believed to be accurate
>>> at the time of publishing based on currently available information. Use
>>> of the information constitutes acceptance for use in an AS IS condition.
>>>  There are no warranties with regard to this information. Neither the
>>> author nor the publisher accepts any liability for any direct,
>>> indirect, or consequential loss or damage arising from use of, or
>>> reliance on, this information.
>>>
> 

Powered by blists - more mailing lists