Palin Hacker Exposes Security Flaw in Security Questions

A number of sources over the past day or so have been filled with the story of Sarah Palin’s email account being broken into by Anonymous.  While there is certainly a lot to be said about this in the political arena, I find that I can’t help but notice another really big story here that isn’t getting a lot of press.  It’s a story which goes well beyond a single politician and has the ability to touch all of us individually, personally, in ways that mean more to any one of us than an additional bit of fire in an already hot political furnace.  The story is those security questions which are so ubiquitous for recovering forgotten passwords, which we should all now be very aware pose real security threats.

According to this report on Michelle Malkin’s blog, the attack agains Sarah Palin basically took place by using her security questions against her.  Now, I take no position on whether or not this is how the attack actually took place or on anything else her blog has to say.  The bottom line is that it doesn’t matter.  The procedure, whether it was used against Palin or not, does describe an actual attack that can be used against Yahoo users.  I know because I set up a test account and tried it.  With all that out of the way, here, finally, is the description:

after the password recovery was reenabled, it took seriously 45 mins on wikipedia and google to find the info, Birthday? 15 seconds on wikipedia, zip code? well she had always been from wasilla, and it only has 2 zip codes (thanks online postal service!)

the second was somewhat harder, the question was “where did you meet your spouse?” did some research, and apparently she had eloped with mister palin after college, if youll look on some of the screenshits that I took and other fellow anon have so graciously put on photobucket you will see the google search for “palin eloped” or some such in one of the tabs.

I found out later though more research that they met at high school, so I did variations of that, high, high school, eventually hit on “Wasilla high” I promptly changed the password to popcorn and took a cold shower…

Thus, our attacker was able to break into Palin’s account using nothng but the password recovery feature and a little bit of research.  And again, just to reiterate, even if you don’t believe this is what happened to Palin, this procedure actually does work.

The good news for most of us is that we’re not Sarah Palin, so the details of our lives aren’t plastered all over a Wikipedia article.  Regardless, the kinds of security questions usually asked are not all that hard to get answers to even for the average person.  Some of the answers, like birthdays and your mother’s maiden name, are all part of the public record and you can get those things for anyone without much hassle.  For those more “personal” details like where you met your spouse, most of us wouldn’t think twice about answering the question in casual conversation.  In all, finding answers to these questions might be slightly out of range of a faceless hacker from Anonymous, but it should be well within the grasp of a less than ethical coworker with an axe to grind or a spouse who suspects some infidelity.

So how do we protect ourselves from the glaring security hole posed by Yahoo and other sites which use a similar type of pasword recovery scheme?  The best thing to do is take Bruce Schneier’s advice and fill the security answer box with as much randomness as possible.  Thinking pehaps a bit more practically, our security answer should be something at least as strong as our password, with the security question acting as a prompt to help us remember the thought process we used in order to create the answer.  At the barest of minimums, your security answer should be something you would never say if you were answering the question in conversation.

In the longer term, I feel it falls to the web development community to find a better way to recover forgotten passwords.  Many sites these days actually do improve the model by refusing to give login credentials through the web browser at all, instead forcing users to check a pre-arranged email address (usually the one entered by the user during account registration) in order to retrieve their password.  While these systems also suffer from weaknesses, they present a much tighter security situation than the wish-it-was two-factor approach used by Yahoo and the like.

And so, I hope that when the dust settles and the political circus moves on to the next town, everyone will stop to take a serious look at the very real security weaknesses exposed by the release of Sarah Palin’s email.  After all, while it may not make national news if an average person gets hacked this way, I can almost guarantee that that average individual will care a lot more about their personal information getting spread around the office (or divorce court) than they do about anything Palin had to write.


Using the Firefox Livemark Service

I spent the afternoon today crawling my way through the Mozilla documentation for what it takes to interact with the Livemark service in Firefox.  As the name suggests, the Livemark service is the set of code responsible for providing an interface to Live Bookmarks for use in extension development.  Although the API is well documented, I had a rather challenging time figuring out how everything fit together into a coherent, and useful, whole.  The reason for the difficulty basically boils down to the weakness of any documentation which would tend to show how the components of the Places system interact.

To really understand the Livemark service, developers need to pay attention to nsILivemarkService, nsINavBookmarksService, and Mozilla’s Places system in general.  The nsILivemarkService interface provides a small set of tools which are specific to interacting with Live Bookmarks, most notably a tool for discovering the feed URL and causing the feeds to reload.  The nsINavBookmarksService interface provides a whole set of utilities for dealing with bookmarks including an observer system which has the potential to be extremely useful.  The Places system, of course, covers everything that you could ever hope to want to do with bookmarks and browser history, making it a treasure chest full of potentially exciting functionality.

The way the Livemark system works is by abstracting RSS feeds into something that looks and acts very much like a directory of bookmarks.  Although I haven’t tested to see how deep the abstraction goes, I do know that an individual Live Bookmark is actually registered in the Places API as a Directory and that each feed item appears to be treated as a regular Bookmark within that Directory.  Each Live Bookmark is able to be refreshed by use of the Livemark service.

Unfortunately for dealing with Live Bookmarks, there is one very notable absence from the field of useful accessors.  Although the nature of a Live Bookmark makes it easy to get the title and URL for every feed item, I have yet to discover any way to get the content of the item from the Places services alone.  Since so many RSS readers have a definite interest in this content information, its omission from the API is somewhat curious, and leaves me seriously considering whether or not I simply missed it in my research.

The good news is that implementing a collector for Live Bookmark content is likely to be very simple.  nsINavBookmarksService allows for the creation of an observer that tracks all sorts of RSS events including the addition and removal of bookmarks.  It turns out that when a Live Bookmark is refreshed, an update is triggered for every item in the feed.  What this means is that, even if there is no elegant way to access an item’s content through the API, it will be possible to retrieve content informaiton during a Live Bookmark refresh and attach it to each new item using the annotation system.

Putting all of this together, it appears that RSS extension authors have a powerful set of tools for building RSS readers on top of the Firefox 3 Livemark system.  The various Places related services appear to provide a rich set of controls to push RSS handling down into the browser core itself, where it will hopefully feel fewer bugs and greater efficiency than extension authors are likely to create on their own.


Firefox Feed Sidebar

Well, I think I’ve finally gotten tired of the Feed Sidebar extension for reading RSS feeds in Firefox.  Pretty much ever since I discovered it, Feed Sidebar has been my preferred extension for dealing with RSS.  In a lot of ways, Feed Sidebar acts and feels exactly the way I believe Live Bookmarks should have been made to work in the first place, presenting a minimalist but usable interface that works neatly from within the familiar browser screens.  Unfortunately, when Firefox 3 came out, the author added some new bugs which have resulted in making the extension extremely frustrating.  With no indication that bug fixes are anywhere on the horizon, I’ve finally decided to take a look at the source code in hope of being able to contribute back bug fixes to make the extension usable again.  This post is essentially my initial list of thoughts on rehabilitating the Feed Sidebar.

To begin with, let me briefly describe the kinds of problems I’ve been having with the extension.  Starting with the Firefox 3 updates, the extension has felt quite a bit slower than it used to and it also leaks memory like a sieve.  For a browser which made a huge deal out of becoming faster and more memory efficient, it’s profoundly disappointing to me that this extension seems to have gone in exactly the opposite direction.  The memory problem for me is so severe that I find myself needing to close the browser every few hours just to keep Firefox running happily within my 1GB of RAM.  Since I would otherwise keep Firefox open for days, this is a major inconvenience and is definitely not right.  Worst of all, it looks like others have had similar kinds of problems.

Right now, my primary theory is that the problem with memory usage is directly related to the new caching feature added in the Firefox 3 release.  According to the author’s blog, the extension now caches all of your feeds, so if you go offline, you still have access to all of the data that was in the feeds, and you can read it while offline. Assuming the user has more than a trivial number of feeds and assuming that at least some of those feeds update frequently, Feed Sidebar might be doing a lot of caching.  Furthermore, I wouldn’t be surprised if Feed Sidebar recaches every item on every refresh, which would cause a lot of resource drain.  I still need to look around in the code to figure out how much of this theory is correct, but it seems like the most likely thing so far.


Fighting with OpenX

Just spent a rather daunting evening trying to get a new version of OpenX up and running.  The pain all came as a result of what I assume to be a PHP bug, but one which is rather beyond my level of interest to fully diagnose and submit a report for.  As it is, I’ve already spent way more time sloshing around through an Apache core dump than I ever wanted to in the course of finding and fixing a segfault which was neatly preventing anyone from logging into my client’s OpenX administration interface.

After reconfiguring Apache and FreeBSD to leave me a core dump of one of the child processes running the OpenX system, I was able to set about clawing my way through to figure out what was going on.  As it happens, the bug was tracable back to an error handler located at DocumentRoot/lib/max/ErrorHandler.php and, in particular, this function:


function startHandler()
{
    $GLOBALS['_MAX']['ERROR_HANDLER_OBJECT'] =  & $this;
    $GLOBALS['_MAX']['ERROR_HANDLER_METHOD'] =  'errHandler';

    //  inner function to handle redirection to a class method
    function eh($errNo, $errStr, $file, $line, $context)
    {
        call_user_func(array(
            &$GLOBALS['_MAX']['ERROR_HANDLER_OBJECT'],
            $GLOBALS['_MAX']['ERROR_HANDLER_METHOD']),
            $errNo, $errStr, $file, $line, $context
        );
    }
    //  start handling errors
    set_error_handler('eh');
}

I have to say that I don’t really understand the purpose of this function. At first glance, it looks like the point was to use a closure to bind an object to an error handler without needing to pollute the global namespace with references to this object. That makes sense, and is actually a pretty clever technique, until you realize that $GLOBALS is part of the global namespace and that set_error_handler() can take an array which allows it to bind an object and its method directly. So I can’t figure out why they did it that way.

But the fact remains that they did, and that this is causing me problems. What apparently happens is, when you go to the administrative interface without having logged in, OpenX does something which triggers the error handler to fire. In this case, the error handler is bound to eh() which is, as seen above, a wrapper for an object method call. As far as I can tell, the call to eh() goes off without a hitch, but something goes horribly wrong when PHP tries to pass the parameters to the object method, causing a segfault.

Fortunately for my purposes, having a fancy error handler doesn’t matter too much, so I was able to dodge the issue rather than trying to tackle it straight on. My “solution” was simply to comment out the set_error_handler() call and allow the default PHP error handler to be used instead. The solution worked and I can now log into OpenX, but it certainly looks as though there’s a bug that needs to be addressed here somewhere.


Hello world!

Welcome to the Mouse’s Cord, my new blog dedicated to my adventures and misadventures in the world of information technology.  With all of the technology blogs already out there on the internet, a natural question to ask might be what will make this one any different.  Well, to make a short stoy long, the only real difference is that I’m writing this one as opposed to somebody else writing it.

If there is one thing I hope to accomplish with this blog, it’s to present the various problems I happen across in my travels and talk about how I managed to solve them.  The concept, however, is more of a narrative than a how-to guide, which means that I plan to be a bit less terse than tech folks tend to be when describing how to do something.

But this blog is also, to some degree, a forum for evangilism and discovery.  There are simply a lot of neat things out there in the world of technology and I plan to make this a place for pointing things out that do a particularly good job of catching my attention.

Exactly how this blog will work is, to be sure, a work in progress.  The nice thing about blogs is that after a while, nobody goes back to see what’s supposed to be going on anyway.  And so, I cast this little blog out into th world to see if I can beat the statistically average single reader that follows these things.  We shall see!