Vigilante: End-to-End Containment of Internet WormsM. Costa et al. (MSR) SOSP 2005
Shimin ChenLBA Reading Group
Overview: Automatic Worm Containment
Vigilante: a person who ignores due process of law and enacts his or her own form of justice when they deem the response of the authorities to be insufficient.
Self-certifying alert (SCA): machine-verifiable proof of a vulnerability
Can be honeypot
What is an SCA?
A sequence of messages, when received by the vulnerable service, cause it to reach a disallowed state
Verification: send messages + check
Detection: message logging + detector
SCA Types
Arbitrary Execution Control Jump to arbitrary existing code in a service’s
address space Specifies how to jump to an address supplied
in a message Arbitrary Code Execution
Code-injection vulnerability Specifies how to execute an arbitrary piece of
code supplied in a message Arbitrary Function Argument
Data-injection vulnerability Specifies how to invoke a specific critical
function with an argument supplied by a message
SCA Format:
Vulnerable service Alert type Verification information:
Where in the message to put the supplied address/code/function argument
Sequence of messages
Alert Generation
Log message and network endpoints Remove old messages (e.g., an hour old) Remove messages in generated SCAs Log is small in a honeypot system
Any detection methods: (in this paper) Non-executable pages Dynamic dataflow analysis
Upon detection, search the log to generate candidate SCAs and verify them
Non-executable pages
Low overhead Upon catching an exception:
1. Search messages for the address or the code of the faulting instruction
2. Use a single message as a candidate SCA3. If this is not verified, add more messages
until the log is empty4. (On a honeypot, at step 3, add the entire log
if the log is less than 5 messages long)
Dynamic dataflow analysis
A flavor of taintcheck Metadata:
One bit per 4K page: if a page is entirely clean For dirty pages, keep one identifier per
memory location: Identifier: an integer – represents the input
message and message offset A separate list mapping identifiers to messages
Propagate for only data movement instructions: MOV, MOVS, PUSH, POP
Alert Distribution
Assume some kind of secure overlay Flooding: each host sends the SCA to all
its overlay neighbors Problems discussed in paper
Compromised hosts may flood the overlay with bad/old SCAs
Must prevent worms to use the overlay for propagation
Evaluation
Prototype: x86 + Windows Dell Precision workstations with 3GHz Pentium 4,
2GB RAM, 100Mbps Ethernet Real worms:
Slammer: MS SQL Server CodeRed: MS IIS Server Blaster: RPC service (2 message attack)
Alert Generation
The moment the last worm message is received till the detector generates an SCA
No verification Only worm messages in the log
Alert Verification
Verification time when VM is already running The verification VM has low overhead normally:
Less than 1% of CPU cost About 84 MB memory
End-to-End Experiments
5 machines: 1-2-3-4-5 1 is the detector 5 is the vulnerable host 2,3,4 are intermediate overlay nodes
Time from worm probe reaching 1 till 5 verifies SCA Slammer: 79ms Blaster: 305ms CodeRed: 3044ms