Interview with Kenny Paterson, Professor of Information Security at Royal Holloway, University of London

The Information Security Group at Royal Holloway is one of the world’s largest academic research groups in information security, with about 15 permanent academic staff, 50 PhD students and a thriving masters programme. They carry out research in many areas of the subject, including network security. That is one of Kenny Paterson’s areas of specialism, and he teaches their masters course on the topic, and carries out research in the area.

Your research lead you to the discovery of a high-profile vulnerability. Give us some details.

In late 2004, Arnold Yau (a PhD student in the group) and I began an investigation into IPsec security, in particular the security of the “encryption only” configuration of IPsec. The relevant standards are pretty clear that this configuration should be avoided, but they also mandate it be supported, mostly for reasons of backwards compatibility.

We also found quite a bit of anecdotal evidence, mostly in the form of on-line tutorials, that people might be using it in practice as well. So we decided to do an analysis of the Linux kernel implementation of IPsec, to see how it handled the encryption-only configuration and what, if any, weaknesses it might have. Arnold mostly worked on analyzing the source code, and I worked more on the cryptanalysis side, seeing how features of the code might be exploited in attacks.

By April 2005, about 6 months after starting, we had a fully-implemented attack client which showed the encryption only mode of IPsec to be very weak indeed against certain kinds of active attack. In fact, we were able to break the IPsec encryption in a matter of seconds, even when 128 bit AES keys were in use!

In your opinion, what is the appropriate approach to take when announcing a vulnerability? What important lessons have you learned during your vulnerability disclosure process?

We worked through NISCC, a UK government agency, and they were able to put us in touch, through their channels, with a large number of vendors and consumers of IPsec. We also discussed things with people in the IETF, to make sure our understanding of the standards was correct. This approach gave all parties some time to assess the impact of our work for their products and deployments ahead of the official vulnerability announcement from NISCC and the release of our research paper describing the work.

We found the vendors to be largely responsive and cooperative, and I think they appreciated the opportunity to work things through in advance. For some vendors, there was no problem: their products didn’t allow the encryption only setting to be selected; others had more work to do.

At the same time as this, we were getting useful feedback on the real-world implications of our research. That ultimately helped to make our research paper a better informed piece of work. This benefit was a bit unexpected for us: so one valuable lesson was not to underestimate the value of working with the community of implementors and users before going public with your research. The proof that this worked in our favour is that our paper has been accepted for presentation at Eurocrypt 2006, a major international conference in cryptography (that was held in St. Petersburg in May).

In general, what is your take on the full disclosure of vulnerabilities? Should the vendors have the final responsibility?

This is a hard one for me, as I don’t have direct experience of working on the vendor side. However, software should be a product like any other, and I think the seller of any product ultimately has the responsibility to make sure its fit for purpose. Most software companies understand that perfectly nowadays and big strides have been made in recent years.

When commenting your research you said: “The open source nature of Linux made the attacks easier”. Does that necessarily mean that closed source is better than open source when it comes to security?

No, not at all! The open source nature of the IPsec implementation we looked at certainly made it easier for us to experiment and to do work on paper before committing to coding. But the attacks we found were not your usual buffer overflows: they required us to build up a detailed understanding of how the Linux IPsec implementation interacted with the IP stack, for example, as well as doing some sophisticated bit manipulations on packets to get the effects we wanted. So our attacks really say very little about the “closed-source versus open-source” debate, which so often focuses only on the number of exploitable buffer overflows and other “standard” vulerabilities that exist in software.

In fact, our work says more about the complexity of the IETF RFCs and how hard it is for a small team to write an implementation that gets absolutely everything right, from the low-level crypto to the implementation of IPsec policy processing.

Are you satisfied with how Microsoft is tackling the problems in their software with monthly patch releases? Some argue that a premium service that releases the patches as they are ready should be in place for large customers. Should they do more?

One problem they do have is that their patches get reversed engineered on a regular basis, and then tools to exploit the vulnerabilway appear quite soon after.

This wouldn’t be a problem if everyone applied the patches immediately, but they don’t. This is a bit like the concept of “herd immunity” in immunology: an immunization programme only becomes truly effective when above a certain percentage of people have had the jab – sometimes that percentage is as high as 90%. You can’t force people to have immunizations. In the same way, Microsoft can’t force people to apply the patches. Of course, it can be argued that applying patches on a monthly basis is a lot less pleasaninjection every once in a while!

What advice would you give to security researchers?

Persevere – it often takes time, luck and a lot of dead ends to find something interesting. Think about the wider effects of your research, and consider how you can resolve the apparently conflicting aims of getting headlines and of acting responsibly: if you do things in the right way, there is no real conflict.