Michal Zalewski on Firefox security

Last month, Michal Zalewski, a well known white hat hacker and author of Silence on the Wire, uncovered some security vulnerabilities in Firefox 2 (some of them already corrected in the latest update). I talked to him to learn more about how hacking happens and his opinion on Firefox and browsers in general.

Mozilla Links: I see that you have researched a number of products including Internet Explorer, SendMail and recently Firefox. And since you found several flaws in a very short time it seems you tend to focus on a specific product for some time. Is this correct? What grabs your attention?

Michal Zalewski: Yup. The reason for this is fairly simple: my public security disclosure
activity is mostly a matter of hobby, not a profession; and I try not to limit myself to a very specialized area of expertise. I toy with various products and technologies, and when I find one of them interesting, I usually look at it for a couple of days or weeks, sometimes finding a couple of flaws in rapid succession.

ML: Do you plan to keep reviewing Firefox or other Mozilla products for some time? How has the experience of diving into Firefox code been so far?

MZ: At the very moment, I’m occupied with a private project; but yes, it’s likely that I’ll do some more research on browser security in the coming weeks.

ML: It makes me dizzy just to think about it, is there a methodology you follow to find security vulnerabilities? something particular in Firefox?

MZ: You usually focus on a particular method of performing security audits, and on a particular type of flaws. This can be reviewing source code in search or buffer overflows, automatically testing a working browser for HTML parsing flaws, or checking for various inconsistencies in Javascript handling, based on published documents.

In the end, though, it’s all about being creative – after all, you’re trying to find errors in the thought process of other folks – engineers, developers, coders; it’s not something you can formalize all the way through.

ML: It is easy to understand a black hat hacker motivations to look for security vulnerabilities, but what makes a white hat like yourself do it?

MZ: Beats doing crosswords. For most of freelance researchers, it’s an interesting mental exercise and a cool challenge; for some, it becomes a way to make a living by legitimate means, working for software vendors.

Ethics of vulnerability research are a different story. There’s no doubt that disclosure of problems, particularly non-trivial ones, helps us better understand and protect our systems. The question is, are we aiding the evil guys, and if yes, should that be a reason to withold information?

This is a hard question, and one that is certainly not unique to computer security alone; similarly, we might wonder whether it’s OK to publicly teach the physics of nuclear chain reactions, or any other technologies that may have malicious uses. The spirits of open source and full disclosure are related, and I subscribe to both.

Some closed source vendors try to subvert free vulnerability disclosure by equating it to aiding terrorists, and claiming that it’s the researchers, not vendor’s own sloppy coding, that is to blame for all the problems we see today. On one hand, it’s usually good to give an advance notice to a cooperative vendor that is known to take problems seriously and resolve them swiftly. But then, warning the public immediately isn’t necessarily a bad thing, either. In the end”resposibly” disclosed flaws get turned into exploits equally (or, paradoxally, more often*) than sanely, but fully disclosed ones, so…

* This is because vendors or companies that pay for vulnerabilities often request working exploits to take a reported issue seriously. And guess what – once written, exploits are more likely to leak out.

ML: Why do you prefer to release security vulnerabilities in the open like the Full Disclosure mailing list instead of low profile reporting to Mozilla security team? I’ve seen you around Mozilla’s Bugzilla so it doesn’t seem to be a matter of “getting along”. Does it disqualify for Mozilla security bounties?

MZ: When reporting vulnerabilities that have no immediate, profound impact on the Internet, I generally see no harm of allowing a public discussion of the problem while the vendor is working on a fix. It seems like a fair thing to do – particularly since there’s really no reason to believe that there are no black hats who had discovered this problem independently, and are already using it to target users. In fact, I sometimes do independently rediscover problems that were previously discovered and reported in a “low-profile” manner by fellow researchers – here’s the kick, sometimes two years ago, without an adequate vendor response!

This way, at least you can detect the attack, or implement workarounds.

I’m often blasted for full disclosure by Microsoft, but I’m yet to see a vulnerability reported by me turned into a dangerous attack before an adequate fix is available.

Open source vendors are considerably more easy on full disclosure. With Microsoft, I don’t even qualify for an acknowledgment in an advisory (because I didn’t tell them six months in advance). With Mozilla, that doesn’t disqualify you for a bounty: they simply want people to help make the browser more secure.

ML: How has the experience of working with the Mozilla developers been?

MZ: Very positive; they sometimes make poor design decisions or sweep old problems under the rug, like most humans do – but in the end, are very open and willing to correct such mistakes. And that’s what matters.

ML: Last year, Mike Danseglio, program manager in the Security Solutions group at Microsoft, said: “Phishing is a major problem because there really is no patch for human stupidity.” He was criticized for it but in the end, it’s hard not to, at least, smile with this and similar comments.

MZ: The problem is, although you can’t prevent stupid users from hurting themselves, you could do far more to help wise but casual users from getting into trouble.

Most of products, for example, tend to flood users with overly complicated and hard to comprehend warnings about most mundane activities, eventually conditioning users to click “OK” in all security prompts if they want a mildly broken webpage to load properly. And then you call them “stupid” for clicking “OK” in a millionth prompt, that happens to ask, in 200 words, not about some mundane form or certificate mishap, but about
installing an ActiveX control on your computer.

Or take these yellow warning bars, my recent pet peeve. [Internet Explorer] and Firefox sometimes display a notification about plugins, updates, blocked popups inside the document window. The problem? Oh yeah, since that happens inside the window controlled by the document, a malicious page can spoof them with 100% realism. The user will simply have no way of telling whether this “Firefox update is available! Click to install” or “A plugin is required to display this page. Download now” notification comes from the browser, or from the author of this site. He might get a different set of contradictory warnings after he clicks on it, but it’s really browser-vs-browser authority conflict ;-) How can aunt Gertrude know what to do?

Poor [user iterface] design decisions are not users’ fault. And we can’t expect users to understand PKI and be skilled system engineers just to use the Internet.

ML: Are software developers responsible for software security to the extent of patching users’ negligence? Is it a matter of economics?

MZ: Software developers should make sure that the options given to the user are given as rarely as absolutely necessary, are presented in a clear and concise form, and can be easily used to make informed decisions.

You won’t prevent a dumb user from installing a malicious ActiveX. But you need to make it possible for aunt Gertrude to know she’s choosing between infecting her computer and not, without the need for pages of techspeak – or better yet, not ask her unless she’d previously established she might need that functionality.

ML: In a bug report you suggest keeping the location bar on sight at all times, a route that Internet Explorer 7 and Opera 9 have already taken. Do you have some other suggestions for Mozilla products users?

MZ: Quite a few, and most of them are not exclusive to Firefox (see the notification bar issue, for example). But that’s a subject for an entire book, I guess ;-)

ML: Is it possible to label a browser (any other category would apply I guess, but let’s stay here) more secure than another?

MZ: I would say that Lynx is fairly secure today. Other than that… I don’t see a clearly superior browser with a functionality comparable to [Microsoft Internet Explorer] or [Firefox].

Thanks to Michal for kindly accepting this interview. To learn more about him, visit his web site.