Security DevCenter
oreilly.comSafari Books Online.Conferences.


Information Security with Colin Percival
Pages: 1, 2, 3, 4, 5

MWL: SCO gave the best response? I'm sure a lot of people will find that surprising. I guess it just demonstrates that the people doing the work aren't the same people that are making policy, and that the vendors who aren't taking it seriously will find out just how real-world this can be.

CP: I think it's a bit more subtle than that. SCO is the heir to Unix, so they've had a lot of time to mature; and their customers are probably highly weighted toward the "upgrade once a decade," hyperconservative server end of the spectrum--which is exactly where this is the most dangerous. Companies tend to adopt the same attitudes as the people who buy their products, so I'm not at all surprised that a company that deals with very conservative server-buying customers had a far better response than a company which deals mostly with security-unaware desktop users.

MWL: To an outsider looking in, it seems that this took a long time to work out. A layman might think that you would just have an idea, hammer out some demo code, mail some vendors, and be done with it. I'm sure it's not that simple. What does a security researcher actually do on a day-to-day basis?

CP: Well, I'm not a very good example of a security researcher, in that respect. Most security researchers--or at least, most people who call themselves security researchers--spend most of their time combing through source code looking for bugs. This is certainly useful, but it doesn't require very much skill, and I suspect that this is a task that will be taken over by computer programs before long, since most security flaws fall into the "stupid mistake" category and are very easy to recognize if you look closely enough; I've been particularly impressed in this respect with results from software produced by Coverity.

As for what I think your real question was--why it took such a long time before I announced the problem--well, it all comes down to lots of details. To start with, when I first realized that this was likely to be a problem, I was in the middle of editing my D.Phil. thesis prior to sending it off to my examiners. While walking to and from college every day--I was living in a house about 2 kilometers outside of Oxford, and without an internet connection--I convinced myself that the problem was probably real, but it wasn't until over a month later, when I went back to Vancouver for Christmas, that I had time to sit down and write some code.

By the end of 2004, I had some working code and I had demonstrated that it could steal enough information to make breaking RSA easy, but this wasn't enough to write to people yet. Extraordinary claims require extraordinary evidence, and while I had the necessary evidence, it was scattered between dozens of files and scraps of paper, and nobody would have the patience to read and understand it all it its current form. Consequently, I started to write my paper, "Cache missing for fun and profit," in order to clearly explain why there was a covert channel between threads executing on the same processor core, how this channel could be exploited as a side channel, and how it was possible to defend against this attack.

I finished a first draft of this at the end of February--after being interrupted partway through by my thesis defense--and started writing to security people to inform them of this vulnerability. For the next two months, my role became less that of a researcher and more that of an educator: while my paper was largely self-explanatory, for nearly every point I made there was at least one person who needed me to provide additional explanation, and there were many things--potential fixes, for example, which I had decided wouldn't actually work--that I didn't mention in my paper but still had to explain to several people.

Toward the end of April, I went through my paper making substantial revisions, based on feedback from the various security teams with which I had been in contact, and then I prepared the patch for FreeBSD--only to end up feverishly rewriting the patch during the FreeBSD developer summit the day before my talk, after I realized that my original patch would had inadvertently ended up disabling dual-core systems.

Of course, while I was doing all of this, daily life continued as usual. As a FreeBSD deputy security officer, I was responsible for dealing with the more common "dumb bug" sort of security issues, so I wrote patches and advisories for half a dozen other security problems (including one I found myself) during the period that I was working on this.

I guess the most important point to realize here is that it's one thing to realize that something might be a problem, and another to write the code to exploit it; but it is quite different, and a lot more work, to liaise with over a dozen vendors to explain what the problem is and how it should be fixed.

Pages: 1, 2, 3, 4, 5

Next Pagearrow

Sponsored by: