Archive for September, 2008


Flash cache… gone in a flash?

Sep 11, 2008 in Security

A neat finding that I ran into a little while back has to do with Flash objects. As you know many people regularly clear their cache and think that no one will know exactly where they have been on the internet and what they have been watching. Well as “Security Professionals” we all know that forensics can find a lot more than what you think is really there.

In the case of Flash and Flash vidoes, Flash stores cookie-like data in objects called LSO or Local Shared Objects.

* Windows: LSO files are stored typically with a “.SOL” extension, within each user’s Application Data directory, under Macromedia\Flash Player\#SharedObjects.
* Mac OS X: For Web sites, ~/Library/Preferences/Macromedia/Flash Player. For AIR Applications, ~/Library/Preferences/[package name (ID) of your app].
* GNU-Linux: ~/.macromedia

So those of you going to those naughty sites to watch those videos in flash, double check your flash cache and make sure that all your cache is cleared. And just to further my concern with these LSOs, “Unlike traditional cookies, LSO’s have no expiration dates, so the information contained in those LSOs may persist indefinitely.” -



Goooogle Chrome

Sep 03, 2008 in Security

As we all know, yesterday was Google’s release of Chrome, Google’s new web browser. Kind of a way to keep taking over the world, I guess… I’m sure there are a million bugs out there for it, but the race to exploit Chrome has definitely started.

An issue exists in how chrome behaves with undefined-handlers in chrome.dll version A crash can result without user interaction. When a user is made to visit a malicious link, which has an undefined handler followed by a ‘special’ character, the chrome crashes. -

To test this, load up Chrome and in the URL type:


Look at that error message… nice error message Google.  “Whoa…”

Click here to view the Error

From here, we would need to just come up with exploit code that could take care of the vulnerability that lies with chrome failing to deal with the POP EBP instruction when pointed out by the EIP register at 0x01002FF4, when introducing the special char.

Just something interesting and will need to be looked at more in detail later.