Ivan Ristić

Security is difficult; open source security sometimes even more so

I have prepared a presentation on Open Source security for the Open Source Specialist Group of British Computer Society (BCS OSSG):

• A_Look_at_Open_Source_Security  (PDF)

The main aim of the presentation is to give an overview of the current state of security in open source projects. I discuss why security is difficult (hint: it's because few people care), and why security in open source is sometimes even more difficult. At the end, I give a simple 3-point strategy for quick evaluation of the security posture of open source projects.

D.J. Bernstein, I salute you!

I have long held a view that we get the software we deserve. The lack of quality, which manifests itself through defects, crashes, security and usability problems, is just a result of our buying decisions. By accepting to use crappy software we encourage software publishers to continue to give us more crap.

So it is a breath of fresh air to see D.J. Bernstein respond to a security report for djbdns:

Even though this bug affects very few users, it is a violation of the expected security policy in a reasonable situation, so it is a security hole in djbdns. Third-party DNS service is discouraged in the djbdns documentation but is nevertheless supported. Dempsky is hereby awarded $1000.

Not only that, but he apologises:

In the meantime, if any users are in the situation described above,
those users are advised to apply Dempsky's patch and requested to accept
my apologies. The patch is also recommended for other users; it corrects
the bug without any side effects.

D.J. Bernstein, I salute you!

Is that open source project secure (enough)?

Type the words "open source security" into a search engine and you will get dozens of links to articles, blog posts, emails, forum messages, and research papers. You can try to read them all, but I don't think you should bother. The opinions mostly fall under one of the following categories:

1. Having access to source code is better than not having access to source code.
2. Community-produced software is better than vendor-produced software.
3. The freedom to modify source code is a fundamental right of every software user.
4. Open source developers are careless, disorganised and fickle.
5. Commercial vendors only care about money.
6. Who are you going to blame when an open source product fails?
7. Open source is dangerous, but you can pay us to help you deal with it.

Most of these claims have a grain of truth in them, but they almost always miss the point in trying to distil complex realities into simple convenient truths. That just doesn't work. The simple truth is that every single project is unique, and must be observed on its own merits. But therein lies the difficulty: how do you determine if a given software product is secure?

I know the proper answer: design an assessment methodology (or use one that already exists—the Software Assurance Maturity Model is nearing completion; Building Security In Maturity Model is expected in a week or so), then use it to make informed decisions. While this approach is suitable for academia, it is too inefficient in real life, where you need to make your decisions quickly and effectively. So what do you do?

Did I mention that I spent almost 6 years of my life working on a fairly popular open source project? In that time I struggled to use my limited resources to do what's best for the project, security being only one of my concerns. I did reasonably well, but made many mistakes along the way. That experience (along with a similar experience in developing closed-source software) has given me an insight into what makes software developers tick and, especially, what makes open source software tick.

So I came up with an idea to avoid measuring the quality of code itself (because that's too difficult and time consuming), instead focusing on the external manifestations of good and bad practices. I call it a Project Security Posture Review. A review might focuses on the following aspects:

1. Does the organisation follow good software development practices?
2. How are security issues handled?
3. Are there any public-facing services available (e.g. source code repository, issue tracking, wiki, etc.)?
4. Is the source code tidy?
5. Is the project mature and popular?
6. Does the project have a reputation for quality?

The idea is that you can answer most of the questions by simply looking at the project's web site, browsing through its code and documentation, and looking at the experiences of other people with it. The obvious advantage of this approach is that it is quick, even though it may be somewhat inaccurate.

If you think the above list is, well, vague—you are absolutely right. I am currently working on a comprehensive list, which I will present during the Open Source Security talk for the Open Source Specialist Group (OSSG) on March 30th.

Update (March 5th): BSSIM is available at http://bsi-mm.com.

The world is full of penetration testers

Mark Curphey has a nice little rant over at his blog: Are You a Builder or a Breaker.

[...] I personally find it is disappointing that after a decade of it being considered a discipline in it’s own right, it is still predominantly made up of breakers and not builders. It’s still predominantly made up of an army of skilled hackers focused on better ways to break systems apart and find new ways to exploit vulnerabilities than “security architects” who are designing secure components, protocols and ultimately secure systems.

I feel the same way. The world is full of penetration testers, who are paid to break things. While I don't have anything against that—they are doing the people they work for a valuable service—it is a shame that we don't have more people who are willing to work to increase security. It is very indicative that only very few people work on the defence side because they passionately believe in making things better. Sometimes it feels the only people on this side (my side) are those are paid for it. (Truth be told, I am paid for my work these days, but it wasn't always like that.) It's really sad, but at most conferences you will find that the most popular talks are those who will mock the current state of security on the Web.

We should pay more attention (and help!) to the efforts that are designed to improve security, for example the Intrinsic Security Working Group at OWASP.

Stop picking on Google Chrome

Chrome, the new browser from Google, apparently has some security issues. So what. Chrome is a brand new application, exposed to the public for the first time, and marked as beta. It's expected to have security issues. The whole point of having a public beta release is expose a product to a wide audience and deal with the discovered problems prior to a stable release. The existence of security issues in Chrome is in line with our current inability to develop software free from security issues. Thus, people should not be distracted by the small problems that are now discovered. We should be  looking at the big picture instead. Chrome is a browser that's been designed from the ground up with security in mind. That's bound to have a positive impact. We'll know more about the impact once the details of its architecture surface.

On the other hand, we should put pressure on Google to stop it from abusing the beta moniker like they did with GMail. Bluring the line between beta and stable is simply not acceptable. How else are users going to be able to judge what is acceptable for production use and what isn't?

Defect-free code is vulnerability-free code

I've come to realise that our efforts to improve the state of security through focus on the software development life cycle (SDLC) are flawed. Although we may see some improvement in the short term (a span of a few years), such an effort is a waste of time as it cannot solve the problem. If you think it can then you are looking at the wrong problem. (Borrowing Mark Curphey's favourite line.) Underneath all our security issues lies our inability to write defect-free code. Solve that and we've solved the security issues. Focus on the security alone and we won't solve anything.

Changes to Computer Misuse Act will turn security professionals into criminals

ComputerWeekly has just published my opinion on the forthcoming changes to the Computer Misuse Act (CMA). From the article:

The most recent changes to the Computer Misuse Act will give power to prosecute those who help or enable others to commit computer crime. While I am very supportive of this addition, I am also in great fear of this change and its consequences - the amendments are so vaguely worded that they will instantly turn security researchers into criminals once they come into force later this year.

If you are new to the story you'll find more facts in my previous post: Changes to British law target criminals, but affect the entire security industry.

The CMA seems to be intentionally written to be ambiguous in order to cover all sorts of activities, including the legitimate ones, leaving it to prosecutors to decide what is crime and what isn't. Frankly, I think that is ludicrous.

No one disputes that we need to be able to prosecute all criminal activities, but we shouldn't be destroying the innocent people's lifes in the process. Good intentions only count before laws are passed. Afterwards, laws just have lives of their own.

Verizon's Data Breach Investigations Report is a pot of gold

Verizon's 2008 Data Breach Investigations Report is worth its weight in gold, even when you print it on the thickest paper available.

Data breaches. You’ve gleaned all you can from the headlines; now you have access to information directly from the investigator’s casebook. The 2008 Data Breach Investigations Report draws from over 500 forensic engagements handled by the Verizon Business Investigative Response team over a four-year period. Tens of thousands of data points weave together the stories and statistics from compromise victims around the world.

This sort of detailed information has so far only been available to a selected few, while the rest of us have had to speculate. That is now over, and anyone can make decisions based on facts now.

I know different people are going to focus on different aspects but, for me, these stand out:

1. In 62% of the cases errors contribute significantly to data breaches. This means that even if you erradicate insecurity in your applications the breaches are still going to continue.
2. In 53% of the cases the attackers took days, weeks and months to compromise a system after making a successful entry.
3. In 55% of the cases no skills or low skills were used to carry out the attacks.
4. In 85% of the cases the attacks were entirely opportunistic.

I urge you to read the report in full, and a few times over.

Eliminating session hijacking... forever

Jim Manico, over at Manicode, is doing an interesting thing: he is trying to convince the maintainers of every web application stack component everywhere (e.g. browsers, web servers, libraries) to implement the HttpOnly mechanism  (read more on HttpOnly in Mitigating Cross-site Scripting With HTTP-only Cookies). Actually, he is doing more than that—in many cases he is fixing things himself and submitting the patches. It's his HttpOnly Crusade.

The general idea behind HttpOnly is to prevent the disclosure of session tokens to JavaScript, which would, in turn, reduce the likelihood of session hijacking attacks. It's a noble idea, but one which is very difficult to succeed. The problem is that we are dealing with a leaky bucket. HttpOnly deals with one of the leaks, but it doesn't do anything about the others. And there are many leaks to take care of. If you go through Jim's blog posts, you will find that AJAX requests will also need tweaking (to hide the cookies marked with HttpOnly), and there is not even mention of session tokens embedded in request URIs, or embedded in request parameters. There is no doubt that an implementation of HttpOnly in all software components would raise the bar and make us more secure, but it won't solve the problem. In this particular case I would prefer to replace the entire bucket.

Our real problem is that session management is not standardised, forcing every application platform (and many applications) to provide its own implementation. Why is this bad?

1. Implementing session management correctly is not trivial. First versions of many implementations have been found to be incorrect and, thus, insecure.
2. It's a waste of time. Session management is best abstracted and handled by the underlying platform or library.
3. Application-level implementations of session management (all implementations today) are inherently vulnerable to session hijacking. We must move session management to a different layer in order to be able to implement it securely (see below).

Why is session hijacking possible in the first place? The HTTP authentication model, as originally envisioned, is not vulnerable to session hijacking because it requires authentication on every request. Session tokens are still needed to identify which requests are part of a session, but since authentication always take place there can be no hijacking. The HTTP authentication model was lacking in many other respects (e.g. there were no provisions to log people out, expire sessions, and so on), so most people simply decided not to use it. In the currently dominant session management model authentication is done only once per session, which turns session tokens into time-limited password surrogates, and thus valuable. Anyone who knows a session token can resume the session it refers to.

There are two ways to solve the session hijacking problem cleanly:

1. Perform authentication on every request, thus making session tokens worthless (as far as hijacking is concerned). You can do this today in certain circumstances, for example if you are willing to use any of the HTTP authentication methods (Basic or Digest), or if your application uses client SSL certificates (in this case all you need to do is to attach the client's SSL certificate to the session, and check that it is the same on every subsequent request).
2. Start a new RFC effort to define session management, and then implement it in a layer other than HTTP. We already have the ideal candidate for this function—SSL. SSL actually already understands sessions (they were added to version 3 to increase performance) so only a few tweaks would be needed to make the mechanism suitable for web applications.

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.