What is it about?
Vigilare system, a kernel integrity monitor that is architected to snoop the bus traffic of the host system from a separate independent hardware.
How is it done?
They made prototype of the Vigilare system on Gaisler's grlib-based system-on-a-chip (SoC) by adding Snooper hardware connections module to the host system for bus snooping.
What about the performances?
detected all the transient attacks without performance degradation
Why about past researches?
the snapshot-based monitor could not detect all the attacks and induced considerable performance degradation as much as 10% in our tuned STREAM benchmark test.
INTRODUCTION
Recent efforts on this kernel integrity monitoring can be categorised into two groups: hardware based and hypervisor based approaches.
Recently hypervisor based approaches gained more popularity. However as hypervisors become more and more complex, security issues are induced to them. Any padding security layer will enhance the security temporarily but also have its vulnerabilities. Finally the only solution is to monitor hypervisor with hardware — this looks quite inefficient.
Most of the existing solutions to kernel integrity monitoring make use of snapshot analysis schemes. They use external hardware component to save memory contents into a snapshot. Then they perform periodic analysis on the samples to try to find the traces of a rootkit attack.
There is a weakness since they are missing the evanescent changes in between the intervals.
An attacker can hide itself between snapshots using scrubbing attack.
HyperSentry addressed this by making it impossible for the attackers to predict when the snapshots will be taken. However, if the traces are left in the memory for a short time, there is a chance that it can avoid being captured in snapshot. HyperSentry was not designed against this.
TRANSIENT ATTACK
Transient attack is an attack whose traces do not incur persistent changes to the victim's system. In such scenarios, the evidence of malicious system modification is visible for a short time period.
VIGILARE SYSTEM REQUIREMENTS
1. Vigilare System need a selective Bus-traffic Collection and Sufficient Computing Power.
2. Handling Bursty Traffic
Just filtering out some traffic may not allow sufficient time to process all collections of traffic to Verifier. Filtering can help but is not perfect. Adding a queue also.
💡 Point important
A better approach is to build a more abstract, interpretable data from the raw bus-traffic data in Snooper
3. Integrity of the Vigilare System
The memory of the Vigilare system contains all the programs and data used by the Vigilare system. The host system must not be able to access this memory in any way
Two possible ways of meeting this requirement:
- The use of separate memory for the Vigilare system is the first option.
- The second option is to implement a memory region controller which specifically drops all memory operation requests from the host system.
The second option may reduce the cost of hardware implementation compared to that of building a completely separate memory for Vigilare.
PROTOTYPE DESIGN
These are regions that should never be modified after boot:
- Kernel code region
- System call table
- IDT: maps interrupts to handlers, https://en.wikipedia.org/wiki/Interrupt_descriptor_table
EVALUATION
The evaluation focuses on transient attacks, main problem faces by SnapMon security.
💡 Point important
In case of SnapMon, the interval of snapshots significantly affects both performance degradation and ability to detect transient attacks. We varied SnapMon's interval to observe its effect on both detection rates and performance degradation. SnoopMon does not have any parameter that possibly affects the result of experiments so we used only one type of SnoopMon.
LIMITATIONS
1. Dynamic Kernel Region Manipulations
Statement: SnoopMon and SnapMon only protect static, immutable kernel regions. But modern rootkits don't always use this, they can use "Direct Kernel Object Manipulation"
Future plan: Extend Vigilare to detect control-flow integrity violations.
2. Relocation Attack
Statement: SnoopMon monitors specific address ranges in physical memory. If an attacker copies parts of the kernel code elsewhere and jump to it, the monitor could miss it.
3. Power Consumption
Statement: Adding an external hardware monitor will increase power usage
4. Platforms dependence
Statement: The prototype runs only on a simple embedded SoC. Real systems are more complex.
⚠️ Attention
The paper presents several limitations that are only discussed at the end of the document. Consider these constraints when evaluating the practical applicability of this solution.
To conclude
I find this solution very interesting since it seems that it really solves a problem that were not totally solved by other researches. It overpasses the performances of the hypervisor solutions by far and provides a more robust solution.
However, there is still a lot of limitations which the document only talks about at the end. In the main body of the paper, the solution is presented as perfect and it just shows how well it is working. I would have preferred to see objective critics on the results, problem faced during development and remaining question and inconvenient. This "nearly perfect" image given by the paper can just give the impression that tests has been led to fast and that researchers have stopped when they have seen good results. Maybe it is not the case of course.
Also, some other questions that the ones discussed by the document remains. For example, how to manage the detection of a kernel compromise? Other example, is it only usable for detection or also for preventions? Is seems that the SnoopMon is the "IDS" of the kernel, can it be enhanced — for example by beeing used with the Snapshot System — to allow system recovery?