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.
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 "web.da-us.citibank.com". | Error: 404. |
| HSBC | Link to secure login form at "www.ebank.us.hsbc.com". | 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 "web.da-us.citibank.com", which are harder for users to verify than e.g. "www.citibank.com" or "citibank.com".
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 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.
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 http://greyhatsecurity.org/vulntests/ 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.
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.
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.
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.
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?
There are many problems with Mozilla's vulnerability-handling process:
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.
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 ;)
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.
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.
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.
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.
You are currently browsing the archives for the Security category.
