Firefox Exploit Adds Fuel to Browser Security Feud

An anonymous reader writes "Washingtonpost.com is reporting that a fairly nasty exploit has been released for a security hole that Firefox patched just yesterday. This is sure to add fuel to the ongoing heated debate over whether Mozilla is any safer the Internet Explorer." From the article: "This is not your run-of-the-mill proof of concept exploit code. It appears to be quite comprehensive, and would allow any attacker to use it with only slight modifications. According to the advisory, the code is designed to be embedded in a Web site so that anyone computer visiting the evil site with Firefox or Netscape would open up a line of communication with another Internet address of the attacker's choice, effectively letting the bad guys control the victim computer from afar."

Comments

What patch?

[Anonymous Brave Guy]

Please note my comments earlier in the thread: since the patch hasn't hit the auto-updates yet, even if you check for it manually, this patch does not exist for most users. There is an exploit for it in the wild. Hence most Firefox users are not safe from this exploit.

There, I put the actually relevant bits in bold for you, just to make it clear. Firefox is a great product for many reasons, but let's not kid ourselves that its security policy is perfect right now, OK? If my Firefox browser had popped up within a few minutes of the patch being released and invited me to download it, you'd have had a case, but it didn't.

Where's the update?

[sshore]

I clicked "Check Now" in the Software Update section using Firefox 1.0.6, and no update was shown. The Firefox box was checked. Anyone else seeing this, or is this just a proxy issue?

This was well over a day after the release of 1.0.7. What URL is used to check for updates, and do they have appropriate options set on server to prevent long caching?

Re:Even without root things can get nasty

[raddan]

It's not tedious at all:

http://www.citi.umich.edu/u/provos/systrace/

It shouldn't be that hard to figure out what a simple program like a browser needs.

Re:Browser shmouser

[alienw]

I've programmed quite a bit in Java. It's surprisingly fast -- for an interpreted language. Which basically means it runs 5x slower than native code instead of 30x slower. Of course, this might not be very noticeable for something like Azureus which is basically a GUI bolted on to some network code (most of which is native code that is part of the JVM or the OS). However, you will notice that the GUI is fairly sluggish compared to a native application, especially if your processor is not very fast. If you wrote firefox in Java, it would be a major memory hog and also very slow.

Re:Java myth revisited

[Dan Farina]

http://www.martiansoftware.com/nailgun/

Also, why would you CARE about the VM utilization? Also, Azureus (as I recall) has a multi-megabyte (up to 32?) cache for blocks it have recently been sent to attempt to reduce I/O, so it's sensible that it would take up more memory, JIT aside.

I have noticed that Azureus generates incredibly copious amounts of garbage though.

Re:Browser shmouser

[Quantam]

Utter nonsense. Do you use Azureus? Perhaps you've played WURM Online? Do you need to clean up your hard drive?

The Java is slow myth is a load of hogwash that opponents of the technology use to justify their stance against it. It's simply not true, and hasn't been true for a very long time. And if you don't believe me, talk to NASA.

In fact I do use Azureus regularly (it's my primary BitTorrent client). But in all seriousness, it's horribly slow (enough to literally make your reference to it laughable). Try benchmarking creation of a torrent, and compare it to a native implimentation of the hash algorithm (SHA-1, I think it was). It's mind-bogglingly slow. Not only that, but it's mind-bogglingly bloated. It's not unusual for it to take 60-80 megs when I'm downloading one torrent (and runs some 3 threads or so per connected peer). A friend (who downloads way more stuff on BT than I do) says it's not unusual for Azureus to take hundreds of megs of RAM on his computer.

As for myself, I did some benchmarking of my own. When .NET first came out, I assumed it (specifically the JITed MSIL) would be slow, probably as slow as Java (although at the time I didn't have a clear idea of how fast Java was; just that it was "slow" - i.e. the stereotype). So I did some benchmarks. Compared to a native implementation of ZLib in C, the same code compiled to MSIL (managed C++) was 2/3 as fast (that is, it took 1.5x as long to compress the same data). The Java version (this was an actual Java port of the ZLib source, not the built-in, native implementation in the Java runtime), on the other hand, was half as fast (2x as long to compress). This actually raised my opinion of .NET, as it proved a fair bit faster than my expectations (while Java was also faster than my expectations, it fell unambiguously below .NET in terms of speed).