Archive for the 'Security' Category

The return of NS_ABORT_IF_FALSE

Thursday, July 17th, 2008

After five years in hiding, NS_ABORT_IF_FALSE has returned. Please use it instead of NS_ASSERTION in situations where failure is likely to lead to memory corruption. By aborting rather than asserting, you ensure that debug-build users focus on the cause of the corruption rather than whatever random crash results from the corruption. This leads to happier debugging and better bug reports.

Of course, sometimes it's better to prevent the memory corruption entirely, e.g. by adding a run-time check or by making all builds abort (not just debug builds).

New security features in IE8

Friday, July 4th, 2008

Microsoft has announced interesting new security features that will be in Internet Explorer 8 Beta 2. They are following other browsers such as Firefox on some issues, and taking bold new steps on others.

Firefox users are already filing bugs asking for us to match some of these features.

Ask Jesse answers

Thursday, May 29th, 2008

Asa has published my answers to the questions you asked me. They include my opinions on full disclosure, what makes security hard, and more.

Gecko assertions

Tuesday, November 27th, 2007

Assertions frequently help me find bugs that would be difficult to catch otherwise. I've filed 479 bugs on assertion failures, excluding bugs that also causes crashes or hangs, and 223 of those have already been fixed. (Thanks to Brendan, I can safely file bugs when I see assertion failures, knowing that my bugs aren't invalid.)

Many assertion failures indicate that assumptions were violated in a relatively harmless way, merely causing incorrect layout or slow performance in an edge case. But sometimes they indicate the presence of a bug that could lead to a serious memory safety violation. For example, "ASSERTION: Some objects allocated with AllocateFrame were not freed" in the FrameArena destructor has helped find dozens of bugs that lead to leaks and/or dangling pointers.

Gecko developers have added many useful assertions lately, and it looks like more are on the way. Regression tests for assertions are improving, too.

I have a list of assertions that I ignore during automated testing. Whenever a developer fixes a bug on that list, I remove the bug and the corresponding assertion from the file, so if I hit the assertion again after that point, I'll notice it.

In addition to helping to catch bugs, assertions also serve as "living documentation" about the code's invariants. We notice if they become out of date, unlike Wiki pages and comments. In my dream world, assertions would also serve as waypoints for an automated theorem prover ;)

A dangerous ambiguity

Wednesday, November 7th, 2007

Brian Krebs recently posted a blog entry, Hiding In Plain Sight, about the continuing problem of executable files disguised as other types of files. Brian explains how to make file extensions visible on Windows XP and wonders why Microsoft didn't make that the default.

But hiding the extension by default is only part of the problem. Most users can't be expected to memorize the meanings of dozens of three-letter filename extensions. Even advanced users can't be expected to check the extension every time they download a 15-second video clip.

The real problem is that the same action -- double-clicking on a downloaded file -- has a completely different meaning depending on whether the file is a document or a program. In the first case, it means "view this document"; in the second case, it means "grant this program all of my privileges".

Mac OS X 10.5 "Leopard" tries an interesting solution: "quarantining" just-downloaded programs. If you download a program using Safari or Firefox, you get a concise dialog reminding you that it was downloaded from the Internet.

Unfortunately, Apple botched an important part of this dialog: the button label. The OS X HIG suggest that button names should be verbs that describe the action performed, so if users only read one word in the dialog, it will be one that differentiates one action from another. (Windows, in contrast, is notorious for using "Yes" and "No" as button labels.) Apple chose the verb "Open", which suffers from exactly the same problem as double-clicking: it has a vastly different meaning for documents and applications!

There is concern that because the dialog is "in the way of what you were doing", many users will click through no matter what the dialog says. So perhaps a better solution is to take a hint from the Web application security model, and grant fewer privileges to most local applications. Why should running a screen saver or local game be so much more dangerous than visiting a web page?

A third possible solution is to make the action to launch an application explicit. In a command-line setting, this action might be "chmod +x". On Mac, a natural choice would be dragging the application to the Applications folder, since that is already a normal part of installing an application.

For now, my workaround is to drag files to VLC (as a habit) instead of double-clicking them. I suggested this in the "Handling downloaded files" section of Security tips for Firefox users.

Conflict of interest

Monday, August 20th, 2007

Consumer Reports "State of the Net" (via johnath):

In the past six months, [spyware] infections prompted 850,000 U.S. households to replace their computers.

I imagine that most of the new machines run Windows. Microsoft's near-monopoly position may mean that the company brings in more revenue by allowing spyware to thrive. Never mind the fact that the cost of designing secure code and safe user interfaces would eat into any company's profits due to software insecurity costs being an externality. Hampering spyware could hurt Microsoft's revenue.

Script restrictions for mitigating XSS vulnerabilities

Sunday, August 5th, 2007

It looks like Robert Sayre is implementing Gerv's Content Restrictions proposal. This will give web sites a way to specify where in the page scripts are allowed to appear. The idea is that if a site using Content Restrictions has an XSS hole (e.g. due to incorrectly escaped text or incorrectly sanitized user HTML), it won't be exploitable in browsers that support Content Restrictions.

I'd rather see anti-XSS effort focused on improving server-side libraries. For example, if web applications were written in terms of "constructing an HTML DOM tree" or "pushing and popping HTML elements", much less code would have to be audited for "remembering to escape output" (I hate that phrase). But it's hard to argue against something that seems like it will help mitigate holes in existing web applications.

Readers who found this interesting might also enjoy Mozilla's metabug for anti-XSS proposals (dependency tree).

Opera is finding jsfunfuzz useful

Saturday, August 4th, 2007

Opera has posted a build with fixes for several crashes found by jsfunfuzz. Cool!

Opera community members posted dozens of comments about it, and I replied to several.