Archive for the 'Security' Category

Mac bugs

Sunday, July 17th, 2005

The Mozilla Foundation is letting me use a Mac laptop during my internship. Firefox (trunk) seems buggier on Mac than on Windows, although to be fair, I am used to Firefox's bugs under Windows. I spent a lot of last week filing, testcasing, and voting for bugs as I ran into them. One Mac-specific bug I ran into is a potential security hole in addition to being annoying.

Banks and https

Saturday, May 28th, 2005

Here's what happens when you go to the web pages of some large US banks, and what happens when you try changing the homepage URL from "http" to "https" or vice versa.

Bank http https
Bank One Insecure login form. Works.
Wells Fargo Insecure login form. Works.
Wachovia Insecure login form. Works.
Bank of America Insecure login form. Redirects to http.
Washington Mutual Insecure login form. Redirects to http.
US Bank Insecure login form. Error: Connection closed.
Citibank Link to secure login form at "". Error: 404.
HSBC Link to secure login form at "". Certificate hostname mismatch.
Suntrust Redirects to https. Works.

Most of these banks make Critical SSL/TLS Mistake #1, having the login form be http and only submit to https. This protects against passive attacks, but does not protect against man-in-the-middle attacks. An attacker who can mount a passive attack can usually mount a man-in-the-middle attack with only a little more work, so these banks are barely more secure than sites that do not use https at all.

Of the banks that use https login forms at all, many make two smaller mistakes: their main page is http, which invites http links and bookmarks, and their login forms have long hostnames like "", which are harder for users to verify than e.g. "" or "".

Many of the largest targets for financial fraud in the US are only defending themselves against passive attacks. Do they believe authenticated encryption isn't important in the US? Aren't these the same banks that blackmailed Mozilla developers into adding two of its most-hated features, "autocomplete=off" and "Cache-Control: no-store", claiming that any browser without these features was not secure enough for use on their sites? Banks in the US are heavily regulated, so why aren't they mandated to use https correctly?

Users either don't look for the lock icon at all, or can be tricked by the combination of a lock image and a statement in the page like "The moment you click Sign In and before your ID and passcode leave your computer, we encrypt them using Secure Sockets Layer (SSL) technology." Why is that? What can be done? What should be done?

The Advogato trust metric is not attack-resistant

Thursday, May 26th, 2005

The project for the graduate algorithms class I took in Fall was to compare two algorithms for a problem of our choice. I chose to compare two trust metrics, the Advogato trust metric and Google's PageRank. Trust metrics attempt to solve the following problem: "Given a directed graph where an edge from A to B means 'A trusts B', whom should I trust?".

In the case of Advogato, the nodes are Advogato accounts and the edges are explicit certifications. In the case of Google, the nodes are web pages and the edges are links.

A good trust metric makes it difficult for an attacker to gain a large amount of trust. More specifically, we might want the amount of trust an attacker gains to be at most linear in the cost of the attack. It helps to think in terms of "bad" nodes, which are controlled by the attacker, "confused" nodes, which trust bad nodes, and "good" nodes, which are neither bad nor confused.

Proving a statement about the cost of an attack requires assuming something about the cost of compromising or confusing each node. Advogato assumes that the cost of confusing a node is closely related to the node's capacity, which is a function of the node's distance from the root. PageRank assumes that the cost of confusing a page is closely related to the page's popularity, which is in turn estimated by the page's PageRank score.

I discovered a problem with Advogato's security proof: it bounds the trust by the final capacities of the confused nodes rather than their capacities before the attack. An attacker can confuse a single expensive (high-capacity) node and many cheap (capacity 1) nodes, then tell the expensive node to trust the cheap nodes. Now there are many confused nodes with substantial capacity, and the attacker can get get an amount of trust equal to a constant times the square of the cost of the attack.

PageRank does not have this problem. The PageRank score gained by the attacker is bounded by a small constant times the total PageRank-score-before-attack of the confused pages, no matter where the attacker makes confused or bad nodes link.

For more details, you can read my paper for the algorithms class.

Security holes in Firefox 1.0.3

Monday, May 9th, 2005

Paul and Michael Krax found a few security holes in Firefox and put them together to form an arbitrary-code-execution exploit. Links: Paul's notes, private bug, public bug, Secunia advisory, MozillaZine article.

To protect yourself against all of these holes, disable JavaScript. (Some people have suggested only disabling software installation. If you only disable software installation, you will still be vulnerable to the XSS hole used in the exploit. XSS is sufficient for stealing cookies, saved passwords, intranet web pages, etc.)

Two of the security holes involve javascript: URLs, which have been the source of many security holes in Firefox and other web browsers. Brendan suggested tracking where javascript: URLs came from so they run with the correct privileges as a way of reducing the number of these holes in the future. Meanwhile, Hixie suggested disallowing chrome: code from using javascript: URLs.

Paul's exploit was leaked on Saturday. After the leak, I noticed that was publicly listable (fixed as of Sunday). My guess as to how it was leaked is that someone else had noticed that the directory was listable and checked the directory every few days for new exploits. It is ironic that a security researcher's site had this kind of hole, but then again I have horrible habits with passwords and use Windows.

Ask Jesse answer: Finding security holes

Thursday, May 5th, 2005

Jeff Walden tried to ask:

How do you find security holes?

This isn't a very coherent answer, and I don't know which parts are the most correct or most useful.

I'm good at ad-hoc testing, where I try to find and report as many bugs as I can. From this perspective, a security hole is just a bug that can be abused by an attacker in a way that hurts the user.

I frequently ask myself "What might the author of this code not have considered?". Sometimes I ask myself "How can I prove that this code is correct and secure?" instead.

I spent a lot of time triaging and testcasing Mozilla bugs, so I know a little about many Gecko and Firefox features. I know of many JavaScript and DOM features that tend to hurt security: getters and setters, eval and the version of setTimeout that takes a string, the with statement, prototype chains, and dynamic typing with implicit coercions. I know of several other Mozilla features that tend to lead to security holes: javascript: and data: protocols, synthetic events, security dialogs. I know of some security checks that are scattered and frequently missing: same-origin checks, CheckLoadURI calls.

I take note of places in Gecko where user data interacts with pages: visited link coloring, file upload controls, pasting from the clipboard. These exceptions often interact with other features to create security holes.

Even though I usually have access to source code, I rarely use it. Using Mozilla source is slow for me because lxr is slow, Google Desktop Search refuses to index my Mozilla source tree, and I'm not good at reading Mozilla source. Testing Mozilla like a black box is fast for me because I have tools like the JavaScript Shell.

List of security holes I’ve found

Thursday, May 5th, 2005

I have compiled a list of security holes I have found in Mozilla and Google products. Most of the holes I've found in web sites could be found without much thinking by anyone who has read my security tips for web developers. The security holes I find in Mozilla tend to be more interesting and clever.

Ask Jesse answer: Mozilla internship

Wednesday, May 4th, 2005

michaell also asked:

Good news about the [Mozilla Foundation] internship - any idea what you’ll be doing when you’re there?

I will be a Technical Contributor, Browser and Gecko Security. I haven't yet discussed with Chris Hofmann, Dan Veditz, etc. what I will be doing to make Firefox more secure.

Ask Jesse answer: Mozilla security process

Wednesday, May 4th, 2005

michaell asked:

I know you’ve criticised the mozilla security process (that is, what happens in practice rather than the documented process) previously, but haven’t seen you say anything about it recently. Do you think things have improved? What concerns do you still have?

Dealing with vulnerabilities that are found

There are many problems with Mozilla's vulnerability-handling process:

  • For bugs that are disclosed by the reporter, patches usually appear quickly, but fixed releases take too long.
  • For bugs that are not disclosed by the reporter, patches and fixed releases take too long.
  • Reporters of security holes sometimes don't get any response for a week, which may make them inclined to disclose the hole sooner.
  • For bugs that are not disclosed by the reporter, fixes are checked into public CVS days, weeks, or months before the release. Anyone can look through Bonsai and identify which checkins correspond to security holes without looking at code. (Checkins with references to hidden bugs, branch checkins, and checkins with vague comments without bug numbers are likely to be security holes). They could then look at the source code changes and, in many cases, reconstruct an attack based on understanding the vulnerability in the old code. Mozilla's security group needs a secret CVS repository for security patches.
  • Bugzilla, Mozilla's bug-tracking system, has holes that can lead to the disclosure of information about security-sensitive bugs. One such bug is itself marked as security-sensitive and has been for years even though multiple people have filed duplicates.

I posted an older version of this list in a comment on Asa's blog. Security researcher "mikx" knew about the CVS problem and it was one of the reasons he chose to disclose holes in Firefox before a fixed version was released.

Eliminating grandfathered vulnerabilities

I'm sad how long my Security tips for users document has to be. I believe that most of the vulnerabilities in Windows and Firefox mentioned there can be fixed with little impact on usability in non-attack cases. They could certainly be fixed with less impact on usability in non-attack cases than making all users read that document ;)

Getting users to keep Firefox updated

Firefox's update notification is too subtle, and updating requires too much bandwidth and effort. Plans for software update in Firefox 1.1 are moving in the right direction to fix these problems. One issue that will be hard to address is users not updating due to abandoned extensions.

Avoiding "missing security check" holes

There have been several fixes that eliminate the need for a class of security check. These fixes make it easier to write secure C++ and JavaScript code and make it unnecessary to sprinkle easy-to-miss security checks throughout Firefox. I hope to see more fixes like these in the future.

Avoiding holes in Firefox's security UI

Someone (maybe me) should keep a list of all the security UI in Firefox and ensure the necessary precautions are applied. For example, users should see clear, accurate information to help them make security decisions such as entering passwords, opening downloaded files, and granting elevated permissions to specific web sites.

One aspect of security UI that requires a lot of attention is dialogs where users make security decisions. In addition to everything above, security dialogs should have safe default actions, clear button labels, and protection against race-against-the-user attacks.

Firefox is doing better on the security-UI front than IE and Opera. IE's and Opera's "what do you want to do with this file" dialogs are still vulnerable to race-against-the-user attacks almost a year after I informed Microsoft and Opera Software. That means that if you're using IE or Opera, a web site can own you pretty easily.

Working with other browser vendors

The Mozilla security group has coordinated security fixes and PR with Opera Software when Firefox and Opera have shared vulnerabilities. This is a good thing.