Keywords: self-healing computing, computer security, automated patching, zero-day attacks, patch creation
I got excited seeing the title of this article, but
Building a Reactive Immune System for Software Services doesn't really contain any immunology. There's no immune system involved, per say, it's just that it's a self-protecting system of sorts.
The idea is quite clever. First, the bug must be found using some extra instrumentation. Then, once the fault has been pinpointed, the code is recompiled so that the problem section can be run in an emulator. The emulator makes a backup version of the state before executing any code, and if, for example, a buffer overflow occurs (the emulator checks for memory faults), the program is reverted to the pre-fault state. Thus, when it returns to non-emulated code, there will be an error since some code has not been executed, but the hope is that this error is something which the rest of the application can handle. The emulator tries to make intelligent guesses about return codes with some heuristics: -1 if return value is
int, 0 if
unsigned int, some cleverness with pointers so that NULLs won't be de-referenced.
I wasn't too sure if blocking out random sections of code was really all that viable, but it turns out that servers really are pretty robust that way. They tested with apache (Where would academia be without open source software to play with?), and tried applying their technique to 154 functions. In 139 of the 154 cases, their tests showed that the altered apache did not crash, and often all of the pages were served. Results for bind and sshd were similar. Tests with actual attacks showed that rather than crashing, the servers could continue execution and serve other requests. It certainly sounds promising for servers that need to have high-availability!
The performance impact for this selective emulation is not
too severe, but it does require access to the source code to compile in the patch, and there needs to be some fairly heavy instrumentation to determine where the patch should be put. There is also some risk that the emulation will open up new security flaws -- imagine what would happen if the emulated function was required for input validation.
But overall, I found this pretty interesting. I'd been working on a somewhat related idea for a term project, and the talk given by Dr. Keromytis about STEM has gotten me thinking that what I thought was a fun but not-terribly-viable idea might actually be worth pursuing.
I'm hoping to look at all the papers cited in the related works section of this one, but for those looking for a little bit more right now, I direct you to
Val's summary of the failure-oblivious computing work. Neat stuff!
Keywords: computer security, automated patching, zero-day attacks, patch creation
As mentioned in the previous post, I went to see a talk by this author and was really interested in what he's been doing, so I'm looking through his papers. This little 3 page magazine article,
Patch-on-Demand Saves Even More Time? is a very short introduction to a problem in security patching: how do we make sure it happens fast enough? Right now, quite a lot of the newsworthy security issues are related to flaws that have been known (and patched) for months, but not
all of them are like that. The idea of a "Zero day attack" is that it's possible for the flaw and exploit to occur on the same day, leaving users with no advance warning in order to prepare their systems. There's great worry that these will become more common.
So how should we handle this issue? His answer: Automation! Actually, it's a pretty common answer, it's just that the system he's looking at creates the patches as well as applying them, whereas most of the systems we see are all about applying existing (human-created) patches in an automated or semi-automated way.
Automated patch creation is not a perfect answer, but it's got a lot of potential... for good and bad. How can we be sure the cure isn't worse than the disease, as it were? "The risks of relying on automated patching and testing as the only real-time defense techniques are not fully understood." While I doubt they'll ever be
fully understood, I am curious if there's any way we can understand them in a general way short of implementing a bunch of ideas and generalizing.
Anyhow, he's had some good results (which he discussed in the talk I attended) with such an automated patching system that took source code and basically emulated the bits that were known to have problems. I'll probably talk about his system later, but I thought I'd mention paper first as an easy read and introduction to this particular problem, before I start looking at proposed solutions.
Keywords: graduate studies
I talk a fair bit to people about what I do, because I find it interesting, and it seems that dangling conversational tidbits like "I'm an AI Researcher" or "I work with artificial intelligence for spam detection" is enough to get people to ask about what my job entails. (This is a big change from when I used to say "I'm a mathematician" whereupon people's eyes would glaze over and they'd change the subject.) Among the things I get asked by fellow students or would-be students is whether I have any advice or readings that helped me figure out what to do. Most of what I know about academia comes from chatting with my mentors and friends at the university, so I don't usually have much to suggest.
I was looking at the website for someone who I saw speak earlier this year as part of a digital security seminar series, and he had a link marked as "a must-read for all Ph.D. students." Curious, I thought I'd give
Networking on the Network a read-through.
It turns out that this is an absolutely fascinating essay. It's an elabourate explanation of the social structures involved in academia, including all those unwritten rules, why they're there, and how they should be followed, and how doing this will help you. That makes it sound kinda dry and preachy, but it's really not. It answers questions I wouldn't even think to ask. To be honest, I don't know how much of this is true, because I'm really a novice academic, but there's plenty that was familiar to me. And, of course, I've learned that I'm doing some things all wrong, and other things are exactly what I would do already.
I probably would have been paralyzed with fear if I'd had all this information available to me before I went to my first academic conference. It was terrifying enough as is without having a picture of the possible social structures involved. Reading this makes me more scared that I'll accidentally mis-step at the next conference. However, as NotN emphasizes, you are dealing with real people here. People can be pretty forgiving to confused new grad students, in my experience.
I'm bookmarking this one for future reference, since there's a lot more there that I'm going to absorb in a day. Plus, a lot of it (like the process of finding a job and getting tenure) is going to be more relevant to me later, so I want to be able to read it then, when I'm more likely to understand it.
I think it's interesting not only because this is the world I'm working in, but because it's a pretty interesting glimpse at what makes this different from other societies. Try skimming a single section (say, the one on conferences) to see if this will interest you before trying to sit down and read the whole thing.
Introduction
If all goes well, I'll be doing a lot of reading over the next few months. I have a decent system for handling references now, but I thought perhaps making myself a log of some of the most interesting papers would be a good idea. (The idea is loosely borrowed from
Val's blog.)
For one, it forces me to talk a bit about papers I read, a process which I've found incredibly useful in my biological security course. It also gives me an excuse to share what I found interesting with other people. I expect some of it will be fairly unusual, given my interest in how biology can be used to create better computer systems. There have definitely been papers I've read that I would
love to see talked about in linux/free software/open source communities, but I suspect most people never encounter these things. So I'll do my part to share the tidbits I find.
This is all a bit of a thought-experiment for me, to see if it helps supplement my existing system for handling my readings. Please feel free to comment on anything I say here, or suggest other related work that I might find interesting.
