Blogger: Ramon Krikken

The web browser is one of those peculiar pieces of software, having to accept input from arbitrary sources and then parse and render the data that is sent to it. Part of this it does by itself, and other parts are taken care of by handlers and plug-ins. In doing so, it displays hypertext, images, videos, and even runs active content like Flash, JavaScript, and ActiveX.

But however much we love the browser, we’ve also come to hate the myriad of vulnerabilities that affect it. Everything from cross-site scripting to remote code execution via maliciously formed animated cursor files and Flash content can make browsing a hazardous activity. The browser is sick, and that’s not desirable for a platform we use for important business and personal transactions.

Worsening the browser’s diagnosis is the recent paper from Mark Dowd and Alexander Sotirov, sub-titled “Setting back browser security by 10 years,” which discusses how to bypass Microsoft Vista’s memory protection capabilities with some added effort for the exploit designers. It’s not that all of the techniques are necessarily new, but the browser appears to be particularly vulnerable to easy exploitation.

Surprising? Not exactly, when we take into account that the browser is suffering from the same disease as the general purpose operating system: bloat and compatibility. We expect the browser to do ever more, but everything we used it for before still needs to work as if it were yesterday. It feels a bit like people insisting on using a cardboard box as a safe, and wondering why their money keeps getting stolen.

It’s not like we haven’t been working on the browser’s cure, though. There have been some improvements in the browsers themselves, the operating systems have also implemented compensating controls, but most of all, there has been an enormous push for securing the web applications that deliver the data in the first place. Unfortunately, the latter two won’t help secure the browser in the long run.

The first issue is that not all content will come from ‘nice’ servers, the second that the server can only make an educated guess on how a browser will parse and render a given set of data, and the third that operating system controls have their own limitations, whether by design or implementation (for example needing to re-compile existing code to enable certain protections.) The browser, in the end, has to be mostly responsible for keeping itself safe; the operating system must assist it in doing so.

So we’re in a pickle. The browser is sick (and the operating system is too), but it’s hard to cure it without a redesign that will undoubtedly impact compatibility, the ever-so-desired multi-functionality, or its ease of use. We can layer defenses by using web filtering in the enterprise environment, but in the end – for the consumer market in particular – we need to fix the browser itself. I can think of a few things I think might help:

• Some kind of site security policy  to restrict where the browser loads auxiliary content from, and which data it can ‘trust’, when loading a web page (I’d prefer mandatory enforcement, and adding an HTML tag to be able to indicate blocks of untrustworthy data.)
• Restricted compartments for plug-ins to run in, ensuring that their bugs cannot easily affect the whole browser.
• Better software development practices for the plug-ins and content parsers themselves, so that they’re less vulnerable, and compiled with the latest protection measures to begin with.

All of this means more work, and some of it means a lot of unhappy reactions when things stop working. Even then we will of course still have to deal with additional vulnerabilities, such as those that may be present in hardware, but we will at least have taken prudent steps to ‘find a cure.’

We write to express our firm belief that research on security vulnerabilities, and the sensible publication of the results of the research, are critical for scientific advancement, public safety and a robust market for secure technologies. Generally speaking, the norm in our field is that researchers take reasonable steps to protect the individuals using the systems studied. We understand that the student researchers took such steps with regard to their research, notably by planning not to present a critical element of a flaw they found. They did this so that their audience would be unable to exploit the security flaws they uncovered. . . .

The restraining order at issue in this case also fosters a dangerous information imbalance. In this case, for example, it allows the vendors of the technology and the MBTA to claim greater efficacy and security than their products warrant, then use the law to silence those who would reveal the technologies’ flaws. In this case, the law gives the public a false sense of security, achieved through law, not technical effectiveness. Preventing researchers from discussing a technology’s vulnerabilities does not make them go away - in fact, it may exacerbate them as more people and institutions use and come to rely upon the illusory protection. Yet the commercial purveyors of such technologies often do not want truthful discussions of their products’ flaws, and will likely withhold the prior approval or deny researchers access for testing if the law supports that effort. . . .

Yet at the same time that researchers need to act responsibly, vendors should not be granted complete control of the publication of such information, as it appears MBTA sought here. As noted above, vendors and users of such technologies often have an incentive to hide the flaws in the system rather than come clean with the public and take the steps necessary to remedy them. Thus, while researchers often refrain from publishing the technical details necessary to exploit the flaw, a legal ban on discussion of security flaws, such as that contained in the temporary restraining order, is especially troubling.

It will be interesting to see what arguments the MBTA uses to keep the students from speaking on a topic where all the important vulnerability information seems to have already disclosed. Sure the students haven’t presented a cookbook exploit tool but they have also stated they have no intention of doing so.

Perhaps the court will investigate what the MBTA’s and their technology vendors response has been to the MiFare card vulnerabilities that were disclosed responsibly. If there has been no vigorous response to responsibly disclosed vulnerabilities of many months ago how can they say with a straight face that are truly responding to new security information and just need more time.

We write to express our firm belief that research on security vulnerabilities, and the sensible publication of the results of the research, are critical for scientific advancement, public safety and a robust market for secure technologies. Generally speaking, the norm in our field is that researchers take reasonable steps to protect the individuals using the systems studied. We understand that the student researchers took such steps with regard to their research, notably by planning not to present a critical element of a flaw they found. They did this so that their audience would be unable to exploit the security flaws they uncovered. . . .

The restraining order at issue in this case also fosters a dangerous information imbalance. In this case, for example, it allows the vendors of the technology and the MBTA to claim greater efficacy and security than their products warrant, then use the law to silence those who would reveal the technologies’ flaws. In this case, the law gives the public a false sense of security, achieved through law, not technical effectiveness. Preventing researchers from discussing a technology’s vulnerabilities does not make them go away - in fact, it may exacerbate them as more people and institutions use and come to rely upon the illusory protection. Yet the commercial purveyors of such technologies often do not want truthful discussions of their products’ flaws, and will likely withhold the prior approval or deny researchers access for testing if the law supports that effort. . . .

Yet at the same time that researchers need to act responsibly, vendors should not be granted complete control of the publication of such information, as it appears MBTA sought here. As noted above, vendors and users of such technologies often have an incentive to hide the flaws in the system rather than come clean with the public and take the steps necessary to remedy them. Thus, while researchers often refrain from publishing the technical details necessary to exploit the flaw, a legal ban on discussion of security flaws, such as that contained in the temporary restraining order, is especially troubling.

It will be interesting to see what arguments the MBTA uses to keep the students from speaking on a topic where all the important vulnerability information seems to have already disclosed. Sure the students haven’t presented a cookbook exploit tool but they have also stated they have no intention of doing so.

Perhaps the court will investigate what the MBTA’s and their technology vendors response has been to the MiFare card vulnerabilities that were disclosed responsibly. If there has been no vigorous response to responsibly disclosed vulnerabilities of many months ago how can they say with a straight face that are truly responding to new security information and just need more time.