AltSci Cell

by Javantea Sept 28, 2008

MPlayer Firefox Plug-in

In case you're wondering how I tested the plugin, I went through my database looking for an embedded video.

mysql> select scene,pagenum from page where rant like '%<object%';
+-------+---------+
| scene | pagenum |
+-------+---------+
|   249 |      38 |
|   249 |      64 |
|   249 |      96 |
|   249 |     104 |
|   249 |     156 |
|   249 |     169 |
|   249 |     172 |
|   249 |     182 |
|   249 |     192 |
+-------+---------+
9 rows in set (0.07 sec)

There's always a worry a person has about adding complex functionality to a browser: is it going to become an attack vector? The answer is yes. MPlayer's huge codebase has been exploited time and time again. Enabling this plugin on every page is going to show you how vulnerable you are while showing you beautiful video with audio. How likely is such an exploit hitting an x86 Linux machine? I'd say 1 in a million, but that's all I need. =D

Kanji-lish Firefox Extension

Anyhow, onto another Firefox extension! Kanji-lish is an extension that tries to teach you kanji using a method that may be compared to speed learning. As an autodidact myself, I know that mnemonics come by themselves if you just use the learned idea in a project that is fun and memorable. See if this preview image captures your imagination:

Incredible, right? From my del.icio.us description:
"Every page becomes a hundred required flash cards. I'm never going to visit slashdot, digg, engadget, or boing-boing without this plugin turned on. Soon I'll be a kanji learning machine. Beware though that it modifies your forms which is a huge bug. To fix this, open a new tab." The only problem with this is that the javascript is not fast enough to display huge pages. So far, Digg is the only page that fails the speed test miserably (boing-boing to a less extent). The obvious solution is a patch to the extension that limits the edits to the top 50 words. I'm going to send an e-mail to the mailing list to see what they think.

Unicode Injection

This is definitely a topic for AltSci Concepts, but I thought I'd discuss it quickly here. A few nights ago I found a bug in PHP/MySQL (don't know which it is yet) where a certain unicode character will cause the MySQL query to truncate. This is the first step toward a vulnerability find. I plan to sell it to a white hat firm (if they'll buy it) and release an open source Firefox Extension that tests websites for known and random unknown Unicode injection vulnerabilities. The open source tool won't give away the vulnerability that I plan to sell, of course. It should be pretty fun.

Firefox 3.0.1 Review

The long awaited update to Firefox, version 3.0 was released June 17, 2008 with plenty of time for Blackhat and Defcon*. It found its way into the Guinness Book of World Records for most downloads in one day. Sadly, they released this with a two show-stopper bugs that only affected the Linux platform. Rather unbecoming of them, but I forgive them since they released 3.0.1 soon after. I was able to download and install 3.0.1 on my desktop x86 on Aug 25, 2008. I've used it instead of Firefox 2.0.0.12 since then (a full month). On the coding side, I haven't noticed any huge changes. Being stable means that changing interfaces that are being used by developers is a no-no. In fact, Microsoft has been fighting the whole backwards compatibility war for so long, they've actually rolled around to being both and neither at the same time.

But that wasn't why you came to my blog, you want statistics. Here I am to give them to you. Doing a pretty simple ldd /usr/local/bin/firefox-2.0.0.12/firefox-bin and ldd /usr/local/bin/firefox-3.0.1/firefox-bin gives us the shared libraries Firefox 2 and 3 use. You'll notice that my paths are wrong (woops), but the overall idea is actually the same. I did a sort -r on each, then I removed regex \(0x[0-9a-f]+\) using my text editor (Kate). At this point, a diff worked. Then I used Kate to syntax highlight it for you. See below.

--- /home/jvoss/recent/altscip/docs/ldd_firefox2c.txt	2008-09-28 14:00:19.000000000 -0700
+++ /home/jvoss/recent/altscip/docs/ldd_firefox3c.txt	2008-09-28 14:00:14.000000000 -0700
@@ -1,32 +1,24 @@
-jvoss@ASLinWs01:/home/www/mashomatic_dev/trunk$ ldd /usr/local/bin/firefox-2.0.0.12/firefox-bin
+jvoss@ASLinWs01:/home/www/mashomatic_dev/trunk$ ldd /usr/local/bin/firefox-3.0.1/firefox-bin
         linux-gate.so.1 =>  
         libz.so.1 => /usr/lib/libz.so.1 
+        libxul.so => not found
         libxpcom_core.so => /usr/lib/seamonkey/libxpcom_core.so 
-        libxpcom_compat.so => /usr/lib/seamonkey/libxpcom_compat.so 
         libxpcom.so => /usr/lib/seamonkey/libxpcom.so 
         libxcb.so.1 => /usr/lib/libxcb.so.1 
         libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 
         libstdc++.so.6 => /usr/lib/libstdc++.so.6 
-        libstdc++.so.5 => /usr/i486-slackware-linux/lib/libstdc++.so.5 
-        libssl3.so => /usr/lib/seamonkey/libssl3.so 
-        libsoftokn3.so => /usr/lib/seamonkey/libsoftokn3.so 
-        libsmime3.so => /usr/lib/seamonkey/libsmime3.so 
-        librt.so.1 => /lib/librt.so.1 
         libpthread.so.0 => /lib/libpthread.so.0 
         libpng12.so.0 => /usr/lib/libpng12.so.0 
         libplds4.so => /usr/lib/seamonkey/libplds4.so 
         libplc4.so => /usr/lib/seamonkey/libplc4.so 
-        libpangoxft-1.0.so.0 => /usr/lib/libpangoxft-1.0.so.0 
-        libpangox-1.0.so.0 => /usr/lib/libpangox-1.0.so.0 
         libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 
         libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 
         libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 
-        libnss3.so => /usr/lib/seamonkey/libnss3.so 
         libnspr4.so => /usr/lib/seamonkey/libnspr4.so 
         libmozjs.so => /usr/lib/seamonkey/libmozjs.so 
         libm.so.6 => /lib/libm.so.6 
+        libjemalloc.so => not found
         libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 
-        libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 
         libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 
         libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 
         libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 
@@ -40,12 +32,10 @@
         libcairo.so.2 => /usr/lib/libcairo.so.2 
         libc.so.6 => /lib/libc.so.6 
         libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 
-        libXt.so.6 => /usr/lib/libXt.so.6 
         libXrender.so.1 => /usr/lib/libXrender.so.1 
         libXrandr.so.2 => /usr/lib/libXrandr.so.2 
         libXinerama.so.1 => /usr/lib/libXinerama.so.1 
         libXi.so.6 => /usr/lib/libXi.so.6 
-        libXft.so.2 => /usr/lib/libXft.so.2 
         libXfixes.so.3 => /usr/lib/libXfixes.so.3 
         libXext.so.6 => /usr/lib/libXext.so.6 
         libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 
@@ -54,6 +44,4 @@
         libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 
         libXau.so.6 => /usr/lib/libXau.so.6 
         libX11.so.6 => /usr/lib/libX11.so.6 
-        libSM.so.6 => /usr/lib/libSM.so.6 
-        libICE.so.6 => /usr/lib/libICE.so.6 
         /lib/ld-linux.so.2 

The above data needs a bit of analysis even for the advanced user that I'm targeting with this incredibly geeky display. You can see that Firefox 3.0.1 adds 2 local libraries: libxul and libjemalloc. It removes 14 libraries (in red). This may or may not affect functionality (likely not) and performance (probably) much but it shows that they are in fact making changes. Firefox 2.0.0.12 was 9.3MB while 3.0 is 8.7M. The 0.6MB saved in the binary distribution is probably connected to simple things rather than big things. firefox-bin was trimmed down to a shell while libxul.so is 13MB while the old firefox-bin was 11MB. The root directory contents for firefox-3.0.1 is 17MB while firefox-2.0.0.12 was 14M. Therefore you would expect a slower cold startup of Firefox 3.0. The total Firefox-3.0 size is 25M, equal to Firefox-2.0.0.12.

User experience Firefox 3.0.1 is a minor upgrade to Firefox 2.0.0.x that can actually be replicated by a few extensions. It's almost humorous that Mozilla expects users to not notice a 10% overall slowness and in return they get a few extensions added that cannot be turned off. What exactly does any user benefit from upgrading?

1) Progress: It's an excellent version and we should support it. Progress is made through incremental changes, bugfixes, and revolutionary changes. Incremental changes can be rather small patches that are testable to be able to ensure that it actually works completely. Bugfixes like incremental changes are tiny patches that work on a very small codebase, which means it can be tested in every use case before released. On the other hand, revolutionary changes like the ones found in 3.0, 3.1, and so on are absolutely huge and involve massive code changes that could cause millions of users' systems to be broken (3.0 actually did that by adding two show-stoppers to the entire Linux platform, millions of users unsupported for 1 month). I do not want to make you feel bad not wanting to be one of the millions to upgrade on release day. Release days are always rife with horrific bugs. Someone will certainly say "Firefox 3.0 is 10% slower at loading pages, that isn't progress," but I disagree. Revolutionary code changes often change the way a system works irreversibly. If the old system works and we write a competing system that works 10% slower, we should be appalled at our failure, but that isn't the end of it. Software development is a process like security. If there is a reason to make a large change that affects performance, it needs to be discussed, understood, communicated to the wide audience, and decided upon. Open source is designed so that any failure that people care about can be fixed by those who care about it. Closed source systems lack that, so a system that is closed source and not perfect will always fail the users.

2) Security: Firefox 2.x is scheduled for end of life in December 2008. That's three months away. As bugs are found and fixed, I suspect that Firefox will go unpatched around March 2009. If you want the latest updates, you run the software that gets updated. Firefox 3.x.x.x is bound to have it's own security flaws, but I seriously trust the Mozilla team and the open source community to find and fix those bugs. We can do it better and we have the proof.

3) Firefox 3.1 will feature TraceMonkey, a performance improvement of huge proportions. Does that mean you should wait until 3.1 is released? By the time 3.1 is released, you'd be a fool to still be running 2.0.0.x. See 1. How many months do you want to miss out on progress? And by the way, Firefox 3 is faster at Javascript than Firefox 2.

Reasonable reasons to not upgrade:

1. You're running Gentoo x86_64 aka amd64 (I am on my laptop, j0anna). Try again in a month, it's better than recompiling 2.0.0.x on your next emerge --sync; emerge --update -av world.
2. You'll get to when you're good and ready. (Who am I to rush you? Do what you like.)
3. You're writing exploits for Firefox 2.0.0.x as "proof of concept".**

* Releasing buggy software after Blackhat and Defcon is a common practice in the software industry. It ensures that hackers do not exploit and publish the exploit full-disclosure at these conferences for fame. I am happy to say that Mozilla and many other open source software companies do not subscribe to this practice. Of course, they get exploited and they patch right after Defcon which is always hilarious.

** Another good reason to write exploits for 2.0.0.x instead of 3.x is to force users who don't want to upgrade into submission. Nothing forces upgrades faster than unpatched bugs. =D