Slashdot Mirror

Another post mentions that someone is claiming an 0-day exploit in the wild for these issues.

From BT:

Firefox Remote Compromise Technical Details

Before I start, I need to say that this thing has been patched on Mozilla's server. If you take a look at any of the extension install pages on their site, you will see that the install function has a bunch of random letters and numbers after it. Even though this would probably be an easy thing to bypass, I am not going to attempt it because of the uselessness of such a bypass. A patch is already in development and so any more work going into fine-tuning this exploit would be a waist of time.

There are three core vulnerabilities being used in my example. A friend of mine (Michael Krax, http://www.mikx.de/ helped me with the research.

To understand why the example works, one must understand the basics of how Firefox works. Everything you see in firefox is essentially a webpage being rendered by a compiler. This is what the gui is made of, and this is why firefox is so easy to customize. However, it also allows for some security bugs. If one could get one of the chrome pages to request a javascript:[script] url, that individual would be given complete access to the system because chrome urls are given full rights in firefox. My example works by tricking the addon install function into displaying an icon with a javascript url.

However, this would not be enough to compromise the system. By default, the install feature only works when called from a page within update.mozilla.org or addon.mozilla.org. Therefore, another (cross site scripting) vulnerability had to be found to call the install feature from mozilla.org. This vulnerability navigates to a javascript page and displays a link (pointing to a mozilla.org page) within a frame that follows the user's cursor. After the user clicks, the link is navigated to, which fires the onload event. This is a buggy event in Firefox because with it we can now access certain parts of the window object that we shouldnt, such as the history object. After the page loads, we use the history object to navigate backwards to the javascript page. The javascript is executed again, now from update.mozilla.org because when we navigated backwards, we essentially navigated to a javascript:[script] page. Now we call the install addon feature, which displays a dialog with det
ails of the requested addon, including an image with a specified image. This image points to a javascript:[script] url, which gets executed in the context of chrome. Now we have compromised the system :)

Whew, that was quite a mouthful.

I am still trying to gather all the details as to how my research was leaked, but recent conversations are leading me to believe that it was a misplacement of trust, not a server compromise. However, I do not want to jump to conclusions too quickly, as this will only lead to more problems. That's all I will say about that subject, as I don't want to offend anybody.

Also, I would like to let everyone know that this is not the only vulnerability that Mikx and I have found. We still have a couple of tricks up our sleeves, and you can be sure that we will not make the same mistake twice.

If you want to see the original PoC, here is the url:
http://greyhatsecurity.org/vulntests/ffrc.htm

Paul
Greyhats Security
http://greyhatsecurity.org/

firescrolling exploit example.... caution exploit code

been out for atleast 2 weeks..... just because the media does not cover something does not mean it doesn't exist.

Another exploit can out this weekend.

I don't think it is so new - it is fixed by 1.0.1. From the description:

Status The exploit is based on multiple vulnerabilities: bugzilla.mozilla.org #280664 (fireflashing) bugzilla.mozilla.org #280056 (firetabbing) bugzilla.mozilla.org #281807 (firescrolling) Upgrade to Firefox 1.0.1 or disable javascript.

Another exploit can out this weekend. The funny thing is that microsoft antispyware beta 1 detects the execution of the payload file and shows a prompt if you want continue or stop the execution.

This is a bug that has been known publicly for over a month, but apparently Microsoft have other priorities.

If there's no fix for Internet Explorer, then what do you call this?

Oddly, the site you linked says that SP2 users are affected, but Microsoft's page says they're not. Clearly someone must be wrong, or the page you linked is about a completely different bug (it does not mention Download.Ject in its body). What gives?

WIRED: It's been more than a month since the first news of Download.Ject, and you still haven't issued a real fix for Internet Explorer. How long is it going to take?

In case anyone is wondering about Download.Ject, check this link out. It's only a matter of time until a high-volume site gets compromised with this exploit. Scary stuff.

Sadly, Firefox isn't affected.

Step 1: Go to http://www.mikx.de/scrollbar/
Step 2: Drag the scrollbar down a bit and let go
Step 3: Start -> Programs -> Startup

That's just spooky.