Critical holes in Trillian Instant Messenger

May 22, 2008 – 5:51 AM

Security service Zero Day Initiative (ZDI) has found three critical vulnerabilities that allow attackers to infect the computers of Trillian Instant Messenger users with malicious code. The vendor has responded by releasing an update to close the holes.

When processing XML through functions of the talk.dll dynamic link library, malformed attributes for the IMG tag can cause data to be written beyond the limits of an allocated heap buffer. Attackers do not require to be authenticated to exploit this hole and inject and execute arbitrary code.

Missing length checks in the functions for parsing MSN MIME headers (X-MMS-IM-FORMAT) can lead to a stack-based buffer overflow. Again, attackers can exploit this vulnerability without prior authentication, and can inject malicious code simply by sending specially crafted messages to potential victims.

The aim.dll library calls sprintf() to process tag values without adequately sanitising the supplied parameters. When excess length attribute strings within the FONT tag are submitted a buffer overflow may result, allowing attackers to execute arbitrary code under the privileges of the logged in user. To exploit this vulnerability, attackers need to either send specially crafted messages via the AIM protocol or establish a direct connection to their victims.

According to ZDI, vendor Cerulean Studios has fixed the vulnerabilities in Trillian version v3.1.10.0. Users of the software are advised to download and install the current version as soon as possible.

Read the rest of the story…

Top 10 Firefox 3 Features

May 22, 2008 – 5:45 AM

The newest version of our favorite open source web browser, Mozilla Firefox 3, offers dozens of new features and fixes, but only a handful will make the most dramatic difference in your everyday browsing. After 17 months of alphas and betas, Mozilla’s finally made a feature-complete release candidate available, so it’s time to spotlight the biggest improvements that will make “Gran Paradiso” the browser to beat. Nearly everything in the open-source app has gotten a second look from the minds at Mozilla, from back buttons to bookmarks, address bars to add-ons, passwords to performance, and the changes will make Firefox 3 worth the upgrade come its official release date, slated for sometime next month. Let’s take a look at the 10 best upgrades in Firefox 3, and how they’ll bolster your browsing, after the jump.

Note: Firefox 3 hasn’t been officially released yet—a public preview release is available and intended for testers only. While it’s a very stable preview, only use it if you’re willing to deal with bugs and instability as the Mozilla teams ready the official release.

That said, our favorite Firefox 3 features include:

Read the rest of the story…

BlackBerry Giving Encryption Keys to Indian Government

May 21, 2008 – 1:47 PM

RIM encrypts e-mail between BlackBerry devices and the server the server with 236-bit AES encryption. The Indian government doesn’t like this at all; they want to snoop on the data. RIM’s response was basically: that’s not possible. The Indian government’s counter was: Then we’ll ban BlackBerries. After months of threats, it looks like RIM is giving in to Indian demands and handing over the encryption keys.

Source: Schneier on Security

Firefox Heap Corruption

May 21, 2008 – 6:08 AM

I forgot to tell you all about this actually. I found this about 8 months back and never discussed it for various reasons. Since I saw that Mozilla has fixed a lot of memory leaks inside Firefox 2/3, I guess it’s safe to say I can talk about this now. Still it works in the latest Firefox build. So, what is going on? Well, I found out that when you utilize the document.open, document.write, and document.close procedure by writing into an Iframe, it usually runs into trouble when a block of code fails to execute between writing in the JSframe and closing the JSframe. Sounds plausible so far I guess, but it’s more interesting when you use an empty applet. An empty applet fails to load and therefore the JSframe can’t close the writing procedure since Firefox already closed it because of the applet failing -or- because there are instructions being written to the heap due to Java memory allocation, on the same time Javascript tries to close the Iframe. That results into the problem that the parent JS thread still tries to close the iframe -since that was the instruction- but can’t 🙂 which in terms eats it’s way on the heap, because it’s running multiple instructions in a process -which heaps are for eh- which then results in possible invalid memory I figured, then gives up and goes into reverse. 😉

When executing the example below, it tries to load the applet, runs into memory and fails to close. In my test environment the browser becomes unresponsive and text being typed in the url-bar is reversed. If I let it run a couple of minutes, or try to navigate it results into a heap corruption, for God knows what. Anyway, I am too lazy to perform a stack trace, I’ll leave that as an exercise for you, and also because my current copy of AutoDebug has expired 🙂 Heap corruptions are usually very serious but hard to exploit correctly, because if controlled properly it can be used to execute code on a users system. I won’t go into that because I simply don’t have the time, concentration nor interest for it. So bear with me on this one, I might do an article on this in the near future.

<script>

// It might not work on your platform due to a ton of reasons.

// tested on WinXP SP2 JRE version 1.6.0_01

function run() {

	var data = '<applet src="javascript:" id="x">';

	y.document.open();

	y.document.write(data);

	y.document.close();

}

</script>

<input name="button" value="Run" onclick="run()" type="button">

<iframe name="y" id="x" src="" frameborder="1" height="200"></iframe>

Source: 0x000000

HTTP Proxies Bypass Firewalls

May 20, 2008 – 7:02 PM

This may seem painfully obvious to some people, but I looked around and couldn’t find a reference to it, so I apologize ahead of time for anyone who already knew this. When we normally think of how attackers use proxies they are almost always just trying to hide their IP addresses. id and I have written papers on bypassing content restricting firewalls using proxies, etc… Those are all fine topics, but that’s not what this post is about. I was pouring through my logs a few weeks ago and came across a number of people attempting to see if I was running an open proxy. Obviously I’m not, and the reason someone would likely check is that it is a robot looking at large swaths of the web for open proxies.

I ran into an open proxy after that and started poking around with it. The obvious way to look for it was to type in “GET http://www.yahoo.com/ HTTP/1.0″ and see if it shows you Yahoo’s homepage. But then it occurred to me that this could be used for Intranet hacking as well. The open proxy doesn’t have to point out to the web. It can, in fact, be pointed inward, to internal addresses. Here’s a diagram of what I’m talking about:

Read the rest of this story…