Ivan Ristic

Bitfrost (OLPC) solved the desktop security problem

I've run into a very interesting presentation from Ivan Krstić (via Risque Management) who, as director of security architecture for the One Laptop per Child (OLPC) project, designed a new code execution platform—Bitfrost—to avoid the security issues that plague the desktop systems in use today. Bitfrost uses capabilities to restrict what each program can do, irrespective of the user account it runs under. You may be familiar with the concept from SELinux, GRsecurity or AppArmour, or, more recently, Caja.

By designing Bitfrost, OLPC did something remarkable: it gave up compatibility (with other platforms) in exchange for a secure execution environment. It's a decision so unusual that it must be applauded. So it's no wonder that Ivan resigned in March of 2008 after OLPC had appeared to have changed focus and Windows XP on its laptops became a reality. Judging from the status page, it appears that Bitfrost is not complete yet, so I wonder how it will progress now that Ivan is not with OLPC any more.

The presentation is full of interesting observations that I fully agree with. For example, the main point:

We have failed as an industry, and modern desktop security is completely broken as a result.

And this statement:

Key symptom: desktop security relies on the user to make informed, sensible choices... About things they don’t at all understand.

And this one:

So we weasel off responsibility to the user, stick our head in the sand, and pretend this was the right thing to do. But the user knows as much about computer security as they do about gravitational waves, closed strings and D-branes.

Please go and read the presentation for yourself so that I don't have to quote it here in its entirety. (What's a D-brane?)

Backward compatibility, by the way, is the main reason why everything is so insecure today. We made these very bad choices years ago, when the circumstances were vastly different, yet we are refusing to put things right today. It is a genuine challenge, even if you put the interests of various industries aside. If you were to come out with a perfectly secure operating system today people wouldn't jump to use it only because it's secure. Only Apple could have pulled that off, by doing things right in Mac OS X, but they wasted that opportunity.

The really sad fact is that the next opportunity to fix things is passing us by at this very moment. The whole world is moving to the Web, where desktop applications don't matter, but, instead of doing things right, we are just moving from one insecure platform to another.

I've come to the conclusion that people (e.g. developers) must be forced to do the right thing by not allowing them to do the wrong thing. The low adoption of the Java security model is a perfect example of this. Java has had a very good capabilities-based security model since version 1.2 (released in 1998), but hardly anyone is using it today. Why? Because it's optional.

Firefox 3 improves handling of invalid SSL certificates

I have downloaded the beta of Firefox 3 to check out the improvements related to SSL. First, there's the added support for Extended Validation SSL certificates, but I am not very excited about that (I wrote about this previously in Extended Validation SSL certificates not going anywhere, as predicted). It's a nice feature, but it's not going to bring much good overall. On the other hand, I am very happy with the improvements to the handling of invalid SSL certificates.

Firefox 2.x allows users to simply click-through their way to a site that uses an invalid certificate.  There is a warning of some sort, but who reads warnings anyway? (Internet Explorer is not much better in this respect, although at least its warning is very clear about not recommending the user to proceed.)

With Firefox 3.x, the situation is much better. First you get the same style of error response as you would for any other network problem:

The beauty of this page is that it does not allow you to proceed to the site. To go through you have to create an exception, which is a multi-step process that you can start by clicking on that link at the bottom. You then get the following:

Another warning; very good. Clicking the Add Exception... button gives you the form that is used to actually create exceptions. There's a nice final warning on the top of the form, which will hopefully deter those who will be attempting to create an exception for the wrong reasons:

The changes represent a great step forward, and significantly reduce the likelihood of successful man-in-the-middle attacks. Still, I wouldn't mention exceptions at all on the error page: advanced users will find a way to do what they must, but normal users are better-off not knowing anything about exceptions.

Update (7 May 2008): My request to make hide the functionality to create exceptions from the error page was rejected. It's good to know that the issue was considered, even if the decision is not the one I would have made. Daniel Veditz pointed me to Johnath's blog post, which describes the history behind the new SSL error page. Very interesting.

 

Changes to British law target criminals, but affect the entire security industry

Back in 2006, at a computer security panel at Infosecurity London, I found myself criticising the proposed changes to the Computer Misuse Act (CMA), which would essentially outlaw any tool or information that could be used to assist in computer crime. Two years later things are pretty much as they were, and the changes are expected to become effective in England some time this year. They are already in effect in Scotland. There's been an attempt late last year, by the Crown Prosecution Service (CPS), to clear things up by releasing the promised Guidance to Prosecutors, but that did not help (see here and here, with additional coverage at Heise Security).

The key proposed addition in reads as follows (a marked-up copy of the changes is available, courtesy of Clive Feather):

3A Making, supplying or obtaining articles for use in offence under section 1 or 3

1. A person is guilty of an offence if he makes, adapts, supplies or offers to supply any article intending it to be used to commit, or to assist in the commission of, an offence under section 1 or 3.
2. A person is guilty of an offence if he supplies or offers to supply any article believing that it is likely to be used to commit, or to assist in the commission of, an offence under section 1 or 3.
3. A person is guilty of an offence if he obtains any article with a view to its being supplied for use to commit, or to assist in the commission of, an offence under section 1 or 3.
4. In this section “article” includes any program or data held in electronic form.
5. A person guilty of an offence under this section shall be liable—
   • on summary conviction in England and Wales, to imprisonment for a term not exceeding 12 months or to a fine not exceeding the statutory maximum or to both;
   • on summary conviction in Scotland, to imprisonment for a term not exceeding six months or to a fine not exceeding the statutory maximum or to both;
   • on conviction on indictment, to imprisonment for a term not exceeding two years or to a fine or to both.

The main issue is the ambiguity of the word likely in "[...] likely to be used to commit, or to assist in the commission of, and offence [...]", which effectively criminalises a large number of security professionals who are just doing their jobs.

As any computer security professional will tell you, criminals use essentially the same articles (tools, books, papers and sources of information) as those in charge of making things secure. Making the articles illegal is not going to stop the criminals from using them—they will be too busy committing the actual offences to care—it will just push the articles underground and out of the reach of the good guys. I am guessing the intention of the proposed changes is to reduce the availability of such "dangerous" stuff by restricting the distribution channels. That, however, is a pointless exercise, as it cannot possibly succeed.

A much bigger problem is that the new law leaves too much to interpretation. The risk is just too high: do you want to be in a position to defend your actions in front of a jury that will almost certainly fail to understand the subject matter? Even if you are successful in your defence, such an event will require significant financial resources, disrupt your life, cause you and your family endless pain, and most certainly kill your career.

What are the possible outcomes?

Possession it not likely to be criminalised (from the Guidance: "[...] does not criminalise possession per se unless an intent to use it to commit one of the other offences in section 1 or 3 CMA can be shown.") so it will probably still be safe to research computer security in private, but exchanging information with others might become dangerous. With the threat of persecution hanging over their heads, most people in the UK are likely to stop publicly discussing what they know.

Full disclosure—no matter what you think of it—will be criminalised, but it won't go away. Those who believe will continue to release vulnerability information, but they will likely take precautions to keep their identities secret.

Tool authors will have a choice to make. If they don't change their distribution practices they will risk becoming a target of investigation and, possibly, prosecution. The Guidance seems to imply the safe way to distribute the tools is via a vetted list of computer security professionals. This is not feasible for most tool writers as they cannot afford the overhead of such a process. On top of that, even if such practices are followed, there is still no guarantee that you won't be persecuted. Each case will be reviewed on its own merits. Thus the alternatives—ending further development or moving the tools underground—seem far more likely.

Criminals are taking over the Internet

A parallel world is being created on the Internet, as many science fiction writers had predicted. Our faults and virtues, the same ones that have existed for thousands of years, are now shaping the virtual world, and it's not pretty. The criminals are taking over. To commit crime on the Internet is so easy, so convenient, that they are abandoning their real-life efforts in great numbers.

I've recently had a pleasure of attending a talk by Merlin, the Earl of Erroll, where he discussed the changes forced upon our society by rapid adoption of technology. The talk was sponsored by Breach Security, as part of a promotional party organised here in London, at the Company of Information Technologists. Merlin is a well-know figure in Britain, and it was refreshing to hear someone give an honest opinion about where we are heading, and about the state of security and privacy in the UK.

One thing that made an impact on me was his account of how criminals are actively taking advantage of Internet technologies, and exploiting the loopholes in the current organisation of the police force and the justice system. One problem is that these organisations were designed to tackle large problems, whereas most crime that takes place on the Internet is, individually, low in value. The cost of pursuing a large number of small cases is simply prohibitive. In aggregate, however, the cost to the society is much higher, but we are lacking mechanisms to deal with it. It's even worse when you take into account inefficiencies of collaboration across jurisdictional boundaries. These have a significant impact even within one country, but really are devastating when crime crosses over.

Can we do anything to deal with the problem? It's obvious that we stand no chance to investigate and prosecute most of such crime cases, so we should focus on prevention. We should focus on making it more difficult for criminals to make money. What that exactly means is not clear, but I'd really like us to start by adopting a method of payment more secure than credit cards. The technology is already available, all we now need is will.

Threat modelling: real-life asset devaluation example

Threat modelling is a risk assessment technique. Simplified, you systematically assess your environment to identify your true assets and the likely adversaries, along with the possible ways for them (the adversaries) to obtain the assets. The main point is to base the analysis in reality, allowing you to identify what is likely to happen while ignoring the ever-present noise. At the end of the process you end up with a prioritised list of threats, and then use your budget (resources) to address the most dangerous one, using one of the mitigation strategies available to you. You then repeat the process until you run out of resources. It is a simple and elegant technique, and one of my favourite security tools.

One of the most useful generic mitigation strategies is asset devaluation. The logic behind the concept is simple. Attackers are typically driven by their desire to obtain assets. If you remove the asset from your environment, or lower its value, then you also remove the reason the attacker is looking at your system. Without the asset to obtain, he will simply go elsewhere.

One of the best examples of asset devaluation is not storing credit card numbers on e-commerce web sites. While some merchants do need to store them, most need the credit card numbers only initially—to process the transactions they were submitted with—and never use them again. What a wonderful opportunity to reduce one's attractiveness to attackers! By removing the credit card numbers from your systems, and telling the adversaries about it, you stay out of trouble.

Although I've used this example many times during my talks on threat modelling, yesterday was the first time I actually saw the technique used in real life, as I was making a purchase from Introversion, an indie game developer from Britain. Here's a partial screenshot:

An added bonus is that this kind of thinking also makes consumers happy. When I saw the note, I instantly perked up, happy in knowing my beloved credit card number is not going to be stored at yet another web site.

Wouldn't it be great if all web sites disclosed details of their inner workings in a similar manner?

Extended Validation SSL certificates not going anywhere, as predicted

According to Netcraft, there are around 4,500 web sites using Extended Validation (EV) SSL certificates, one year after this new type of certificate was introduced. At the same time, over 800,000 sites continue to use the old-style certificates. Embarassingly enough, even the certificate authorities themselves are not valuing the new technology, with some of their sites that were using EV SSL certificates a year ago reverting back to plain SSL certificates since.

This practically means the EV SSL certificates are dead. Admitedly, there is very little reason for web sites to deploy EV SSL certificates today, as the majority of users won't see any difference in their browsers. The new certificate type is supported in IE7 on Vista, with a manual update required  on Windows XP is required to enable the feature.  (Confusingly, the update didn't work for my Windows XP laptop, and I have no idea why.) Firefox, in version 2.x (the current version at the time of writing), treats EV SSL certificates as any other certificate, although version 3.x (which is around the corner) adds support. There is a very slight chance the support for EV SSL certificates in browsers will, in turn, raise interest in the technology, but I wouldn't hold my breath waiting for that to happen.

Not that it matters anyway. I wrote about EV SSL certificates last year, arguing that they are too little, too late. If we wanted to raise the level of security we should have simply mandated thorough verification of all new SSL certificates. We would have to wait for the current SSL certificates to expire, but we would eventually end up with an improved situation. With the current approach, a lot of people are going to put a lot of effort to achieve nothing: very few web site will choose to use EV SSL certificates and even fewer people will know the difference [PDF]. Phishing will continue to be a problem.

In addition to all this, EV SSL certificates are simply addressing the wrong problem. Internet needs trust, but identifying legal entities behind web site addresses is not going to help with that.  I do not need to know the identity of whoever is on the other end of the connection. What I really care about is knowing if it is safe to place the order, and this I already know how to determine with a reasonable amount of certainty: I am going to base my decision on the reputation of the merchant. In real life, I am unlikely to make a significant purchase in a seedy part of the town. Equally, online, I am unlikely to make a significant purchase from a web site I've just come across. I am going to make the large majority of my purchases with a well-know retailer, for example Amazon.com.

People prefer to make incremental changes because they are easier to do, but large problems are often too big for a series of small improvements, and require radical actions to solve.

Is PCI 6.6 good for web application firewalls?

PCI requirement 6.6, which endorses web application firewalls, raises the profile of this technology but leaves a lot to be desired. Requirement 6.6 is a part of Section 6, which deals with development and maintenance of systems and applications. Sections 6.1 through 6.5 are all sound, dealing with issues such as patching, change control and secure development practices. At a glance, Requirement 6.6 seems sound too:

"6.6 Ensure that all web-facing applications are protected against known attacks by applying either of the following methods:

• Having all custom application code reviewed for common vulnerabilities by an organization that specializes in application security
• Installing an application layer firewall in front of web-facing applications.

Note: This method is considered a best practice until June 30, 2008, after which it becomes a requirement. "

One issue with the text is that it puts two very different techniques against each other. Organisations are going to choose only one technique to achieve compliance, where, in reality, they should be using both. Looking past that, the wording works very well for web application firewalls, in the sense that most organisations are likely to choose to deploy a WAF rather than go through a very long and very expensive process of code review.

And that is exactly what causes me to worry: organisations looking for PCI certification are going to choose web application firewalls because they are the less ugly choice. Not because of the merits, of which there are many.

As someone making a living from web application firewalls, I should probably be more optimistic about the whole affair. After all, there is no doubt the level of interest in web application firewalls is rising, in no small part due to the PCI standard. The sales are increasing too. And I am sure many organisations will attempt to use the products they've purchased; some of them will like them. PCI 6.6 may actually lead to a wide adoption of web application firewalls. But it still troubles me that many of the purchases of this remarkable technology are going to be made for the wrong reasons.

At the moment the addition of web application firewalls to the PCI standard looks like an afterthought. There is a slight danger that the products will be bought and installed, but not actively used. The PCI standards needs to give WAFs at least the same treatment it currently gives to intrusion detection systems: prescribe not only the installation, but a continuous use, including various options such as blocking, detection-only deployment, virtual patching and the use of WAFs for traffic logging and monitoring.

Tide is turning for web application firewalls

There is a long-running tradition in the web application firewall space; every year we say: "This year is going to be the one when web application firewalls take off!" So far, every year turned out to be a bit of a disappointment in this respect. This year feels different, and I am not saying this because it's a tradition to do so. Recent months have seen a steady and significant rise in the interest in and the recognition of web application firewalls. But why is it taking so long?

Having been involved with the industry for many years, I come up with many valid theories to explain the apparent slow adoption of web application firewalls. Here are some of them: 

• It's a brand new type of product that requires effort to learn how to use. Articles, books and papers need to be written, conference talks need to be scheduled and best practices need to be established. We need a critical mass of people with access to the technology in order for discussions to take place and for users to start to be comfortable.
• Network security people are the likely ones to be tasked to deal with application security. To deploy a WAF one needs at least a minimal understanding of application security, but to achieve this, in a field where attacks are still evolving at a rapid pace, is not easy.
• Many organisations are yet to assign people to deal with application security full-time, let alone web application firewalls.
• It is often not clear who is supposed to manage the technology. Does it fall under network security or application development? Or should we assign it to the application security team instead (where it exists)? This decision is made more difficult by the fact that some web application firewalls can be deployed inline (e.g. as a bridge or a reverse proxy), where they impact performance (not necessarily in a negative way) and create a point of failure.

Above all, the perception seems to have been that web application firewalls are not something we cannot live without. At the same time, the opposite is true for network firewalls. This has to do with the differences in risk distribution in network security and application security. In the network application space virtually all organisations run off-the-shelf products on their servers. Once vulnerabilities in these products are exposed exploits are written. These exploits are easy to deploy in an automated and indiscriminate manner, and this sort of thing is happening on a massive scale. The likelihood of being hit by such an exploit is very high, although the damage coming from such an attack might not be. When you add to this the fact workstations (whose numbers by far outweigh those of the servers) are also targets, it becomes clear why firewalls are viewed as essential.

In the application security world most attacks are still carried out by hand. One reason for this is that people haven't started automating the attacks yet (but this is changing, as demonstrated by recent automated SQL Injection attacks); the other that most web applications, unlike network security products, are custom-developed and thus require manual exploitation. The net result is that some organisations are hit by application security problems and some others aren't, although most are equally insecure. Lack of mass-scale exploitation is contributing to the feeling there is still more time to act.

This, of course, is an illusion. Organisations without web application firewalls are playing a game not unlike that of Russian roulette, hoping they won't be affected. But in this game you get hit—eventually. It's just a matter of time. We are seeing the increased interest now because people are starting to get fed up with web application security issues appearing left and right. Every new day sees a new type of problem discovered. Every day we hear of a new massive attack with damages running into millions. (The Web Hacking Incidents Database project is particularly good at documenting these.) People are waking up to the fact that addressing their problems before attacks take place is going to be much less painful (and far less costly) than doing the same afterwards.

In other words, and to simplify greatly, we haven't seen mass adoption of web application firewalls so far because that market was too young. The time was not right. But it will be right this year. I think.