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."

My Firefox 1.0.6 says there are no updates.

[Anonymous Coward]

If I have firefox (win32) check for updates in the Tools, Options menu, it says that there are no updates. WTF?

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.

Re:Exploits as remote administration tool?

[Anonymous Coward]

Yes, a few people have used Back Orifice [bo2k.com], a renowned trojan, for legitimate tasks. Firefox root exploits are unlikely to be used for good though...

Re:Security through obscurity?

[tepp]

Firefox doesn't allow ActiveX which again limits it's utility.

Not really. I use firefox everywhere and there is only two sites I cannot use.

One is our local in house bug program called TestDirector. The other is Windows Update.

So I use IE to go to TestDirector or Windows Update, and Firefox for everything else, and never had an issue with ActiveX being needed. Every site I visit is either in Flash or in Jave or just in plain HTML, with the exception of those two, which I don't just meander to anyway, so it's not a hassle.

Re:Not quite...

[Dehumanizer]

It showed up yesterday in my sister's 1.0.6. She didn't even have to check for updates manually.

(not to me, though, as I'm using 1.5b1)

To prevent their servers from crashing and burning, they make "spread out" auto-update to a couple of days. I'm guessing 1.5 will put an end to that.

ActiveX

[Anonymous Brave Guy]

ActiveX is the one thing left in IE that makes it truly, the most insecure browser out there.

It's also the major reason large numbers of huge companies aren't adopting Firefox, since it's the technology many of them base their Intranets on. It's a security risk when outside sites can use it, but not having it for internal pages is a PITA at times.

Re:Screw it...I'm moving to Lynx!

[Anonymous Coward]

OK, here you go [google.com].

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:Why Firefox is still better than IE...

[Warlock7]

Problem is, that doesn't really remove it. It just hides it. Go to Windows Explorer, in the address bar type in your favorite URL, like http://www.slashdot.org/ [slashdot.org] for instance, then watch as your innocent little Windows Explorer essentially becomes IE...

The DOJ never really made MS remove anything, IE is WE is the system browser. It's all a load of sh|t.

Re:Patch

[Anonymous Coward]

To the best of my memory, most of the biggest exploits for Windows in the last couple of years or so have utilized holes for which patches were already available. In fact, there is some evidence that the exploits were written based on Microsoft's vulnerability disclosures from the patches. This is probably also what happened with this hole - the developers were not being proactive but rather included a fix for a security hole in an update and someone else took a look at the changes and figured out the exploit. Another possiblity is that the exploit was written by the original finder of the hole, and that this person agreed to hold off releasing it until a fix was available.

Re:Even without root things can get nasty

[raddan]

It's not tedious at all:

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

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

Re:Tip-toe through the TPS.

[pyrotic]

Ideally you install Firefox once as Admin (coz we trust those Firefox developers not to put anything nasty in the installer), then login to a user account. The user account has permission to run Firefox, but not as Admin, so won't have permission to modify Firefox, the kernel, or whatever. In case of an exploit, you can still destroy your own user files though.

Unix, traditionally having a less granluar permissions model than NT, has a lot of programs that when run as a user, change themselves to run as Admin. An example is traceroute, which is SUID root. An exploit in one of those, and the game is up.

All this is largely academic though, as Windows doesn't use its permissions model properly by default. Explorer for example is usually run as Admin, allowing a single exploit to destroy your files, the kernel, whatever.

Re:Where's the beef?

[Waffle Iron]

So when are the Fedora update directories going to see 1.0.7

From the linked article, it appears that this exploit uses the CAN-2005-2871 bug. That bug was patched in the Fedora 1.0.6-1.2.fc4 update issued back on Sept. 9, so unless I'm mistaken, it's not critical to upgrade to 1.0.7 if you've already installed the 1.2.fc4 patch.

Re:Tip-toe through the TPS.

[TheRaven64]

The problem with this is laziness. OpenBSD and NetBSD both include Systrace, a facility that allows every system call made by a program to have its inputs validated and then run either as the user or as root (so, for example, you can allow a web server to bind to port 80, but not do anything else as root). The problem is that very few people get around to creating the required rule sets. Eventually they may grow some useful pre-defined setups for common apps, but it's going to take a lot of effort for someone.

Java myth revisited

[aaronl]

No, it's quite to the point provable and true. For example, I use Azureus because I haven't found another suitable client under Linux. I would never run it under Windows because the UI is slower, the startup is horrid, and it takes more resources than other programs. It is responsable for 60MB of RAM and a 380MB VM footprint. It is consuming 1.3% of my Athlon 2600, and 7% of my total 768MB of RAM.

Java is slow to start and requires more memory than an equally competently written native code program. This is always going to be the case, because it imposes both the overhead of the C libraries and the overhead of the JVM itself.

The case where Java is *not* slower is where it can do run-time optimizations. Then it is sometimes faster than native code. In the other cases, Java is just not *as* slow as it used to be, that's what has changed.

It could be said that the "Java is fast" people are being equally unreasonable because they're ignoring many of the more important places that Java is slower in. The right answer is that Java is faster than C for some things, slower than C for others. During execution, they are comparable. In shutdown and startup, Java is slower. Java also has the issue of the UI handling, which is not as nice as the established UI toolkits available to other languages. The UI response is also not as good as a native program.

Also, this is the same NASA that is known for so many inefficiency and poor choices. Are you meaning to imply that Java is another of these? The thing is that NASA could have chosen almost any language and accomplished the same thing. They just decided to use Java. Is that supposed to prove something? Or was that supposed to be that you named three apps that were written in Java, and have better native equivalents on many OS'? I already mentioned Azureus, WURM is OpenGL with Java logic, and jdiskreport is yet another program that solves a solved problem.

That's like my saying "No, C/C++ is just the right answer, because Windows, Linux, OSX, BSD, QNX, BeOS, Firefox, Gaim, Office, etc. is written with them." It has no bearing on anything.

If you want counterpoint, fine, I don't think I've ever used a Java app where the UI was decently responsive. That includes Azureus, LDAP Browser, Dell OpenManage, HP WebAdmin, parts of OpenOffice (like the DB portion in 2.0 beta), the Java control panel, and the Solaris installer.

So no, Java is still slow enough to be impractical on the desktop. The Java UI toolkits suck, and the whole language suffers as a result. Fix the UI, fix the load times, and fix that you need another instance of the JVM for each app. Then you have it good for desktop apps.

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/ [martiansoftware.com]

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:Even without root things can get nasty

[John Whitley]

But such fine-grained controls are incredibly tedious

Hogwash. The grsecurity [grsecurity.net] patches to the Linux kernel provide one approach to fine-grained access control that greatly eases the tedium of managing fine-grained rulesets. In short, grsecurity's approach is based on automatic learning -- let the system run in a permissive mode doing the things it's supposed to do, then generate a ruleset based on that activity. The system then runs with the generated permissions ruleset. The admin may need to tweak the ruleset for various reasons, but the tools provide a huge leg-up over any manual attempt to lock down a system that wasn't designed for it. And there's the rub... design.

With an OS that provides robust fine-grained access control, new software patterns and system tools emerge to manage the complexity. We didn't go from teletypes to OpenGL in one leap... For example, what if the only entity in the system that could even know the password database existed, much less access it, was the password service? Shadow passwords pale compared to that kind of isolation. What if the default permissions for an application effectively sandbox that app in a jail that makes Java in a chroot look like a toy? You'd then have to build additional infrastructure to allow the apps (and thus the user) do their work.

It's all quite possible, and folks are working on it now. This is the shift in mindset from allow-all by default to allow-nothing by default, and the work necessary to make that approach practical at the level of an OS. Take a look at http://www.coyotos.org/ [coyotos.org] and its predecessor http://www.eros-os.org/ [eros-os.org] for examples of current work on a OS (kernel and support infrastructure) designed for security (and performance) from base principles.

It's a daunting task, but damn well worth the effort IMO.

Re:Even without root things can get nasty

[ultranova]

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

It needs to be able to talk to X server to render graphics. If some webpage takes over the browser, and makes it execute arbitrary code, can it be made to hack the X server to delete the files in your home directory - for example, by launching xterm (or finding a running instance) and sending the neccessary commands to it ? Or, worse yet, can it use some X buffer overflow to insert code that runs at root privileges - after all, X needs these privileges due to the horribly broken design of the display subsystem of at least Linux (and propably BSD's too) where the graphics hardware is handled partially in user space...

It isn't enough to secure just one single program, you need to secure all the programs it needs to talk to, and all the programs that they talk to, and so forth. You'll end up needing to make profiles for every program installed on system to make a truly secure system.

1.5 Beta Simple Fix

[Anonymous Coward]

Note that users of Fx 1.5b1 can just go into about:config and set network.enableIDN to false (and restart Firefox) to be protected against this exploit.

Re:Browser shmouser

[gcauthon]

Java is not interpreted, nor has it been for a VERY long time.

That's news to me. It's news to Sun [sun.com] as well.

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).

Re:The real problem--SpyWare

[strider44]

the user can't install any extensions from a site other than update.mozilla.org without jumping through a few hoops first.

Re:Security through obscurity?

[Minna Kirai]

As proof, I will point out that the "Disable Javascript" option found in Netscape 4.0 (the predecessor to Mozilla) is missing, along with the ability to prevent image loading.

Everyone else is giggling at you, but I'll spoil the joke.

Run firefox. Go to the "Edit" menu, and pick Preferences. In the icons on the left, hit "Web Features". Six checkboxes come up in the main panel. Look at the ones labelled "Load Images" and "Enable Javascript", and think hard about what they might do.

Via extensions? Good luck.

[Anonymous Coward]

You DO realize that you have to first *whitelist* the extension in order to install it, and only certain Mozilla controlled sites are whitelisted by default, right?

Oh, and it's not an easy pushbutton thing, either. You have to find the setting in your browser (probably under about:config or somewhere) and add it that way. Should be more than enough to intimidate someone who isn't bright enough to know better than to install a spyware extension.

How to stop stack/heap exploits for *GOOD!*

[iamcf13]

This coder's approach makes sense AND WORKS!

(Note: I am not a shill/user of his software but am a fellow coder always on the lookout for good, elegant, useful code and ideas to use in future projects....)

From

http://www.slproweb.com/download/ProtoNova_ID.chm [slproweb.com]

Discussion on Security

[snip]

Before I conclude, I have one other thing I wish to mention that defines security. This is the fact that ProtoNova is the only web server in existence guaranteed to be free from Buffer Overflow attacks on the stack at the application level. Let's see you try to get a guarantee like that from Apache or Microsoft. While I can't control problems with the underlying OS or libraries, I can control how I write my own code. Here's my secret to how I can make such a guarantee: Dynamically allocate all memory I use on the heap. 90% of all bug fixes for exploits (potential or otherwise) coming out of various organizations (ahem, Microsoft) are for Buffer Overflow attacks on the stack. A buffer overflow on the heap is far less dangerous than a stack-based overflow. If you don't know the difference, let me show you that I really do know what I'm talking about (whereas most journalists generally have no clue) using some C code - that is, the language most web servers are written in:

// Include necessary headers to compile
#include <stdio.h>
#include <stdlib.h>

// Start of the "main" function - used to tell the OS where
// to start processing source code.
int main(int argc, char **argv)
{
// Tells the computer to create 256 places in memory _on the stack_ for storage.
char str[256];

// This just tells the user how to use the program.
// Not really important, but useful.
if (argc < 2)
{
printf("Syntax: BadProgram TypeInAReallyLongString");
exit(1);
}

// This copies the data the _user_ specified into str.
strcpy(str, argv[1]);

// This prints the contents of str.
printf("%s\n", str);

return 0;
}

(For you programmers out there, please ignore the comments. I realize they are "basic/newbie," but I'm attempting to explain source code to newbies).

The example above is extremely dangerous. Why? It is because there is only room reserved for 256 places in the computer's memory. What happens if the user enters data for 1000 places? This is where the danger comes in. The stack is where function calls like "main" are stored. When 1000 memory locations are copied from the user to str, the stack beyond the 256 is overwritten with whatever the user has entered. Typically, this will result in a crash when the function "main" "return"s...however, if those 1000 places in memory are carefully crafted, they can execute arbitrary code when "main" "return"s. This could be anything from a virus to a complete system takeover.

So, what is the solution to this? It should be obvious: Don't put anything the user enters, even remotely related, onto the stack...ever:

// Include necessary headers to compile
#include <stdio.h>
#include <stdlib.h>

// Start of the "main" function - used to tell the OS where
// to start processing source code.
int main(int argc, char **argv)
{
// Tells the computer to create a place _on the stack_ for
// storage of a pointer to memory _on the heap_.
char *str;

// This just tells the user how to use the program.
// Not really important, but useful.
if (argc < 2)
{
printf("Syntax: BetterProgram TypeInAReallyLo

Re:What patch?

[csk_1975]

I dont know how up to date this list is [safecenter.net]. But a quick google will show you plenty of other lists of unpatched IE flaws. Personally I gave up using IE when my system was crapped out by 180 solutions spyware that was using a variation of a supposedly patched flaw (the patch was later updated).