MWL: It sounds as if it would have been easier to write an exploit for this than to bring this to vendors correctly as you did!
CP: Quite likely, yes. Of course, considering the wide range of operating systems affected by this, I wouldn't want to distribute exploit code even if I had written it, so the route I took was the only reasonable approach to ensuring that everybody could fix the problem (even if some of them seem to have not bothered).
MWL: You're also a part of the FreeBSD security team. I'm sure you get a fair number of emails from panicked users, false bug reports, "security holes" that are actually the result of incorrect sysadmin practice, and so on. What's it like being on the FreeBSD security team? Are there any choice tidbits you'd care to share from that experience?
CP: Many people have said that war is "months of boredom punctuated by a few minutes of hell"; being on the FreeBSD security team isn't quite that intense, but there is certainly a similarity. Most of the time, there aren't any major problems that need to be dealt with, but we never know when the next big attack is going to happen. Of course, that's only one side of the security work I do with FreeBSD; in addition to handling security issues as they are found, I've spent much of the past two years improving our infrastructure for distributing updates. It doesn't help very much to discover and produce a patch for a security flaw if none of your users actually apply the patch, for example, so I wrote a tool called FreeBSD Update that allows people to securely download and install security updates very easily.
As for choice tidbits: there are inevitably some amusing things that happen, but I'd rather not give specifics; people have confidence that they can write to the security team to tell us about potential problems without having their correspondence discussed outside of the security team, and I don't want to betray that trust.
MWL: Your updating tool sounds promising; would you care to give our readers a brief description and tell us what problems you're trying to solve?
CP:Sure. To start with, you have to understand that FreeBSD is an open source operating system; all of the source code used to build it is available, and anyone who knows what they are doing can take this source code, make changes to it, recompile it, and thereafter run their own personal version of FreeBSD.
This is all great, but it leads to a certain disconnect between the
developers--for whom "remove
| S_IRGRP | S_IROTH from line 105
of sys/dev/iir/iir_ctrl.c and recompile" makes sense--and normal
users, who aren't interested in writing code but instead simply want a system
that works. Historically, security issues have been handled in FreeBSD by
distributing a source code patch along with a list of instructions for applying
the patch and rebuilding; this had the effect that most users would decide that
applying the security patches was far too much work, and would instead simply
leave their systems insecure. A doctor once remarked to me that it's one thing
to diagnose an illness and another to prescribe the correct treatment, but
that the really hard part is making sure that a patient actually takes the
medicine--the situation is exactly the same with security issues, in that the
really hard part is to make sure that users actually keep their systems up to
This is where FreeBSD Update comes in. I take the source code patches that fix security problems, and recompile everything; then I check to see which files have changed, package the new files together, and put them online for people to download. Instead of needing to apply the source code patch and recompile everything--which can take well over an hour on a slow machine--users simply run the FreeBSD Update client, and watch as it downloads any necessary security updates for them--very much the same way as Windows Update works.
Incidentally, there has been one very interesting spin-off benefit of my work on FreeBSD Update: In order to speed up the downloading of binary security updates, I wrote a simple "delta compression" program, which compares two files and outputs a small "binary patch," which encodes the difference between them. Since people normally have an old, insecure version of the files for which they are downloading security updates, it is usually possible to download this much smaller patch file. Much to my surprise, I discovered that the patches my utility was producing were several times smaller--and thus faster to download--than patches produced by any other available software. Since then, my binary delta compression utility, bsdiff, has been increasingly widely used, most notably in OS X (for distributing software updates) and in the next major release of Mozilla Firefox.
MWL: You've provided ideas for people looking to make crypto useless on hyperthreaded machines, created software used by major companies to reduce the cost and complexity of software updates, and nailed down your Ph.D. What's next?
CP: As I think I mentioned before, my attack is just the latest in a long series of side-channel attacks on cryptographic implementations. The unfortunate fact is that the existing libraries of cryptographic functions were either written before side-channel attacks became well known or were written by people who were largely unaware of the problem. Each time that a new attack is published, cryptographic libraries are rewritten to protect against that latest attack, but there has been no attempt made so far to produce a library that is designed from the ground up to be immune to entire classes of side-channel attacks. As I mention in my paper, this can be done by adopting a more restricted model of computation, which prohibits data-dependent branches or memory accesses. Assuming that I can find some funding to support this, I'd like to write such a library.
In the longer term ... well, when Guy Consolmagno was appointed the Vatican astronomer, he was given three words of instruction: "Do good science." That's the sort of job I'd love to have: one with no strings attached, nobody telling me what research I should or should not be doing, and nobody telling me what I can or cannot publish--just absolute freedom to do research. Realistically, I suspect that the closest I'm ever likely to get to that ideal is if I get a tenured appointment at a university, so that's where I'm currently hoping to end up; but wherever I go, I intend to continue doing research. The problems I do research into are often inspired by practical issues, as with my delta compression work, so it is quite likely that I'll continue to produce useful software; but that is simply a side benefit. My real interest is the research.
MWL: Good luck, and thanks for your time.
Return to the ONLamp Security DevCenter.