• 検索結果がありません。

Discussion and Conclusion

ドキュメント内 Countermeasures Against Malware Constructing Botnets (ページ 91-97)

4.5.1.1 Incomplete Sensitivity

The same as the VPStatic model, our STT proposal only models the control flows of programs without tracing any predicates in their branches. As a consequence, it still suffers the limitation named IncompleteSensitivity. However, we should notice that most variables in predicates are located in the stack so that we can access them while walking the stack. Then this limitation may be well eliminated if we track and verify the value constraints that these variables should satisfy at consecutive system call sites.

For example, within the buffer-overflow attack targeting this limitation in [29], without tracking predicates, illegal system call sequences < sys1, sys4 >and < sys2, sys3 >will be mistakenly accepted by our model after the str is overflowed. However, if we check the constraint that the value of the predicate variable user should stay the same at the two consecutive system call sites, this attack can be well detected. The challenging issue is how to detect and model these constraints of predicate variables via static analysis.

4.5.1.2 Incomplete Set of Events

This limitation is due to the fact that our STT model is constructed on system call level and intrusion detection is performed only when system call events are captured.

Therefore it will miss those attacks occur within a segment between consecutive system calls and have no effects on the outside of the segment. Of course the precision of such an intrusion detection model can be improved by refining its monitoring granularity. For example, we can make use of code instrumentation to monitor user calls or even every instruction instead of just system calls to detect those carefully crafted attacks targeting this limitation. However, such kind of improvement is just a trade-off: the improvement of the precision is at the cost of efficiency decreasing. What we really need is a good balance that increases the hardness of attacks as far as possible under the premise of guaranteeing the efficiency.

4.5. Discussion and Conclusion 79

4.5.1.3 Mimicry Attacks

Mimicry attacks refer to specific skills used by attackers to transform their attacks that are detectable in its original form in such a way that the resulting sequence can be accepted by the intrusion detection model [29, 99]. The same as the VPStatic model, since our STT proposal monitors both the system call sequence, program counter and call stack, it’s hard for an adversary to launch a mimicry attack to forge correct call stack and program counter information along with the sequence of system calls that is equivalent to the original attack.

4.5.2 Conclusion

We have proposed an efficient anomaly-based intrusion detection system against code injection. The normal behavior model used by this system is a provably DPDA, which is similar to the classic VPStatic model. We replace the automaton in the VPStatic with a state transition table and the automaton walk in VPStatic is replaced by a search in the STT, which is more efficient. We solve the state explosion problem of the STT and no redundant states and corresponding transitions existing in the automaton of the VPStatic exist in our STT model. As a result, the memory use is greatly reduced. In our experiments, the memory overheads of the STT for three Linux self-contained programs are all reduced much more than half compared with their VPStatic models. We also prove that our STT model has the same precision with the VPStatic. Thereby, we improve the memory efficiency of the VPStatic greatly without reducing its precision, which alleviates the historical conflict between the efficiency and precision, which is suffered by similar intrusion detection models.

81

Chapter 5

Anomaly-based Lightweight Hypervisor Against Kernel Rootkits

5.1 Introduction

Kernel Rootkits are designed for concealing malware by directly subverting the kernel.

As we mentioned in Chapter 2, to well prevent this threat, a better way is to move the prevention logic into the Hypervisor, which is an additional software layer between the OS and the hardware. However, current hypervisor-based countermeasures suffer from various types of problems, which have been discussed in Chapter 2. In this chapter, we aim to design a completely different lightweight hypervisor named Barrier that can bypass these problems and well protect the OS integrated from being affected by kernel rootkis. Before describing our proposal, we first present the threat models and the design goals in this section.

5.1.1 Threat Models

When designing Barrier, we assume the following four attack scenarios. (1) The attacker gains the root privilege of the system, and then utilizes a shell command such as insmod to load a malicious kernel extension as the kernel rootkit. (2) The attacker exploits a vulnerability existing in a benign kernel module to make it the host of a rootkit.

The target module can be either a static module or a dynamic extension. (3) The attacker

hides his malicious codes in a normal kernel extension and attracts unprofessional users to download and install this extension. (4) The attacker may also construct return-oriented rookits, which do not load any new code but re-use the existing code within the kernel to launch attacks.

When the adversaries succeed in these scenarios, they may damage the kernel integrity in the following properties:

Code Integrity: (1) They may modify the codes in other kernel modules to change their behaviors. (2) They may execute critical codes in other modules that they should never execute. For example, call critical functions in the file system to modify or delete important files.

Data Integrity: They tamper with both the control and no-control data in other kernel modules. The modification of control data such as function pointers will subvert the system control flow. In addition, they may also tamper with both control and non-control data in the kernel stack. Stack integrity is an important property of data integrity.

Data Privacy: They may read and leak private data in other modules that they should never access. For example, a malicious network driver may read important data such as a list of running programs and then send them to the remote hackers.

5.1.2 Design Goals

Barrier focuses on defending against the above threats so as to enhance the kernel integrity. Of course, this does not cover all the kernel security threats. For example, Barrier does not deal with those persistent rootkits targeting the kernel files on the disk. Also, our system does not consider the situation where the attackers directly use some malicious hardware devices to subvert the kernel memory through DMA accesses.

However, the attacks discussed in this research are most common and difficult. For the other threats like the DMA attacks, we can directly integrate Barrier with existing solutions.

ドキュメント内 Countermeasures Against Malware Constructing Botnets (ページ 91-97)