18.104.22.168 Incomplete Sensitivity
The same as the VPStatic model, our STT proposal only models the control ﬂows of programs without tracing any predicates in their branches. As a consequence, it still suﬀers 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 buﬀer-overﬂow attack targeting this limitation in , without tracking predicates, illegal system call sequences < sys1, sys4 >and < sys2, sys3 >will be mistakenly accepted by our model after the str is overﬂowed. 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.
22.214.171.124 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 eﬀects on the outside of the segment. Of course the precision of such an intrusion detection model can be improved by reﬁning 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-oﬀ: the improvement of the precision is at the cost of eﬃciency 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 eﬃciency.
4.5. Discussion and Conclusion 79
126.96.36.199 Mimicry Attacks
Mimicry attacks refer to speciﬁc 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.
We have proposed an eﬃcient 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 eﬃcient. 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 eﬃciency of the VPStatic greatly without reducing its precision, which alleviates the historical conﬂict between the eﬃciency and precision, which is suﬀered by similar intrusion detection models.
Anomaly-based Lightweight Hypervisor Against Kernel Rootkits
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 suﬀer from various types of problems, which have been discussed in Chapter 2. In this chapter, we aim to design a completely diﬀerent lightweight hypervisor named Barrier that can bypass these problems and well protect the OS integrated from being aﬀected by kernel rootkis. Before describing our proposal, we ﬁrst 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 ﬁle system to modify or delete important ﬁles.
• Data Integrity: They tamper with both the control and no-control data in other kernel modules. The modiﬁcation of control data such as function pointers will subvert the system control ﬂow. 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 ﬁles 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 diﬃcult. For the other threats like the DMA attacks, we can directly integrate Barrier with existing solutions.