Is It Time To Stop Malware—Forever?
An approach to stopping malware via small hardware changes
Rich DeMillo is a theorist who has also been: the head of all computer science research at Bellcore/Telcordia, the first Chief Technology Officer of HP, and the Dean of the College of Computing at Georgia Tech. All this and he has also made important contributions to theory, software engineering, and security.
Today I want to talk about computer malware. Just having a name—malware—for worms and viruses is a problem. We tend to name things that are important, or is it things become important when we name them? Whatever we call them, it is time, I believe, to say:
I’m as mad as hell, and I’m not going to take this anymore!
I quote the actor Peter Finch—as Howard Beale—in the great movie Network of 1976. In my version, the this in his quote refers to malware—it’s time to stop malware.
In the beginning there was ARPANET. Of course before the beginning there was nothing, but thanks to Bob Kahn and his colleagues the ARPANET was created about fifty years ago. This was the first time computers could send and receive messages and files from each other—it seems so obvious today, but then it was a ground breaking application.
I recall watching with envy my colleagues, like Anita Jones, check her ARPANET account for messages. Since at the time I was not funded by ARPA, I was not able to get an account; hence, no messages for me.
Eventually, those of us on the outside, those of us without ARPANET accounts, decided to act. The key event happen during the summer of 1977, when Rich DeMillo and I spent two month visiting Larry Landweber at Madison. Larry wanted to get out of theory, he was trained in recursion theory, and get into some more system area of computer science. After many discussions, we converged on the project of creating an ARPANET type system that would connect US theorists together.
DeMillo, who is a great and fast writer, sat down and wrote a draft of the proposal in a day or two. For a variety of reasons, Larry became the PI of the proposal: he submitted it to NSF, he got the project funded at Madison, and TheoryNet was born. This became successful quickly, and led NSF to create NSFNET. Thus, we went from email for few—those who worked for ARPA—to email for some theorists, to email for all NSF scientists, to eventually email for everyone.
I have no doubt we would have email today even if Rich and Larry had not started TheoryNet in 1977, but they did create TheoryNet. And it led directly to NSFNET, and so on. I bring this history up for two reasons. First, I think that Rich’s role in the creation of email is not as well known as it should be. Actually, it is probably completely unknown. Second, I created one of the first instances of a “spoofed” message over an email system.
After Larry was funded his programmers wrote a simple and primitive email system, based a central computer, a UNIVAC. A user connected to the mainframe and ran the mail system. There was no need for any complex mail protocol, since all the accounts were stored on one central machine.
One day at Madison, Larry proudly demonstrated the system to Rich and myself—the system was still being debugged. We sat down at adjacent terminals and Larry showed each of us how to login into the email system, and how to send and receive messages. After a while I decided to have some fun and sent the following message to Rich:
FROM: SYSTEM ADMIN
TO: ALL USERS THE THEORY-NET SYSTEM IS GOING DOWN DUE TO A FATAL ERROR.
PLEASE LOG OFF IMMEDIATELY.
Larry was instantly upset: he said he had no idea what was happening. After a minute I pointed out I had sent the message—it was bogus, there was no problem with the system. We all laughed: I think Larry was amused anyway.
At the time it seemed a silly joke, but it was not silly. It pointed out one of the fundamental flaws in the system—email had no security. One could send anything to anyone. The silly joke was a warning—one we laughed off—of things to come. Malware.
Why is There Malware?
The fundamental reason malware is such a problem is money: dollars, euros, yen, and Today malware is a multi-billion dollar a year business. My spoofed message was a harmless joke for Larry and Rich—just two people. Later, malware was still “jokes”, but jokes that could affect millions of people and do millions of dollars in damages. Robert Morris’ famous worm, for example, was an experiment that went very wrong. He was not out to make money or to harm anyone. But, he did cause damage anyway.
Today jokes are gone: malware is a big business. The creators of malware are out to make money. They plan to steal your accounts, to steal your money, to trick you into paying for worthless goods, and in general to make money illegally.
Soon the situation will be even worse. Besides stealing money we are starting to see attacks that affect the security of whole nations. This is one of the most scary, in my opinion, changes in malware. Malware for fun was a problem, malware for profit is a huge pain, but malware that attacks national infrastructure is very scary. Such attacks could destroy on a huge scale.
Prevention and Protection
There are many ways to attempt to detect and stop malware—the keyword is attempt. These attempts can be thought of as a game of warfare between M, the malware creator, and S your computer system. There are two basic ways for S to try to defeat M; one way is syntax based, and the other way is semantics based.
Syntax based methods: These methods attempt to recognize malware by its source code. After M sends a piece of malware and it becomes detected, S can “look” for other copies of the malware. If S detects a piece of code that matches the known malware, then it can delete the code or stop it. To make the search for the malware code more efficient, almost always a signature method is used. A hash function is used to build a signature for each piece of known malware: this greatly speeds up the detection of malware.
The problem with these methods is simple: M can make the malware change as it spreads, and thus not have a constant signature. There are many ways this can be done and it is an on-going battle between M and S to create useful signatures. However, the major problem with syntax based methods is they work only after the malware has been detected and its code is known.
Semantic based methods: These methods attempt to recognize malware by its behavior. There are two main variations: simulation based and real-time based methods. Suppose that some code is about to be executed, in the simulation approach S executes the code instruction by instruction. This allows S to “see” exactly what is happening at all times, and hopefully allows S to detect any suspicious behavior. If during the simulation, S detects the code doing something strange, then the code is labeled malware. For example, if the code tried to erase a key block of the disk, then S would easily be able to classify the code as malware. In this case the code will not be allowed to be executed.
The problem with this method is simple: M can make the malware have a complex behavior. The malware might not do anything obviously bad, or it might only misbehave after some time or in certain situations. Even more impressive some M have written malware that can tell it is being simulated. This sounds impossible, but such malware can detect whether it is running on a real processor or on a simulator.
How is this possible? My colleague, Wenke Lee, who is an expert on malware, says malware can detect slight differences in a real execution vs a simulation. Processors are very complex and there are almost always small—but detectable—differences in how a simulator works. I find this scary, since it shows how clever M’s can be.
Besides simulation there is another semantic based method based on real-time monitoring of the execution of code. Since the code in this case is actually being executed, the monitoring of the code is not instruction by instruction. Rather, in these methods S looks at the execution patterns of all running code. If S detects some “strange” behavior, then it decides the running code is a potential piece of malware.
The problem with these methods are the same as the problems with the simulation methods: M can make the bad behavior of the malware hard to detect.
Malware Uses Replay Attacks
Can we stop malware once and for all? We will never stop software from having bugs that allow malware ways to penetrate the security of a system. However, I do believe we can change the “game” in a fundamental way: in a way that makes it extremely hard—if not impossible—for malware to work.
The key idea is that we must break one fundamental assumption that M relies on:
Malware uses replay attacks.
In cryptography a replay attack is the re-use of a message to fool an encryption system. No one, today, would forget to add time stamps to their messages; otherwise, an attacker could simpler resend a message and defeat their security. If I see you send the message, “buy this stock ”, then I could—if you do not prevent replay attacks—simply send the same message again. This may not be what you want.
Yet the writer of malware, M, relies on this very type of attack everyday. If M has malware code capable of getting control of one machine, then it will also be able to get control of millions of other machines. This is a replay attack on a grand scale.
How To Stop Replay Attacks?
In order to stop replay attacks, I propose that we change the hardware so they are impossible. This is not a new idea, but I have two points:
- If we do not stop M from using replay attacks, I think we are doomed to fight a battle forever. A battle we may not win.
- Today we are finally in a position to stop replay attacks by malware in ways that were impossible before.
I have several ideas on how we can make M’s job very difficult. Since this discussion is running a bit long, I will give one example today and more in the future.
Imagine a future processor that has registers—there is nothing special about , but let’s pick this as an example. This processor has one special extra register , this register cannot be used by any of the standard instructions. Assume for the moment that is set by some “magic method.”
The processor executes instructions as before. Well almost as before: there is one critical difference. Let the registers be . Each instruction that uses a register is checked by the hardware to satisfy this condition: the bit of the special register must be . If it is not, then a hard fault is thrown and a special recovery routine is called.
Another way to explain this idea is: call a register poisoned provided . All instructions must avoid using poisoned registers; any using such a register causes a detection routine to be called.
What is the point of all this? The key is that not all the registers are free to use; say only of the registers are not poisoned. Thus, when a piece of malware is executed for the first time, when it uses a register it has a chance of being detected. Note, this does not depend on the method the malware uses to get its code executed. It can use a buffer overflow, a out of bounds error, or any other method. The method the malware uses to get instructions executed is immaterial. Since the value of is a secret that is unique to each processor, the malware is stuck.
Of course the probability of detection on the first use of a register is only . There are several points about this low probability:
- First, if the malware executes several instructions the probability of detection goes up exponentially. The malware can try to look at the “good” code to figure out , but if that takes instructions, then the probability the malware gets by is only .
- Second, suppose that only of the malware is detected. This still means a mass attack—the most likely kind—will be easily detected on many machines. The detection of the malware instantly should allow the signature and other methods to stop the rest of the attack.
- Third, the simulation method of running code to see if it is malware will now work with very high probability. Even if the malware can detect a simulation from a real execution, as long as this detection takes instructions the probability of getting by is again very small,
- Finally, there is nothing magic about . If we have a set of registers and only allow to not be poisoned, then the detection probability becomes .
There are some issues that I need to explain. The main one is how will the magic register be set or accessed? This is critical, since if the malware can set the register, then all is lost. I will discuss this soon.
There are several research questions that arise from this approach. I thank Mustaque Ahamad the head of GTISC for pointing out two key ones:
The first is: how will dynamically loaded code, be able to get into the system and execute correctly? I have several ideas on how to do this, but I do not have a complete solution. Obviously, as he says, malware must not be able to exploit a code download channel to craft a targeted replay attack.
His second point is: what if the malware only uses one register? Then, the probability of not being caught will be low. Of course, the malware code may run slower, but performance is a poor defense in security. The hardware could force code to use more than one register—precisely any code that uses one register might be suspect.
Can the method outlined here be used to defeat malware? Can the research questions discussed be solved? Can we defeat malware by some other means? What do you think?