Dong Jin
dongjin2@illinois.edu
Cyber Security Worm Lab Report
Design Notes
The overall design is described in the flow chart below.
Randomly choose a LAN
address
Yes
Sequentially select Host
Address in the LAN
Launch the attack
End of Host
address?
Download itself from a
fixed locatoin
No
Yes
No
Sending a normal
magic8 message to
magic8d server
Install a place marker
Get response within
time limit?
Fetch /etc/passwd file
Yes
No
Send poison packet
Has the host already
infected?
Address selection: The method of address selection is important in the overall rate of
worm spread across networks. Methods include fully random, local preference
random, and sequential scanning. My approach is to first randomly select LAN
address and sequential scan every host within the LAN.
Pre-scanning: Doing pre-scanning to determine if a host is running a magic8d service
prior to sending data to the host is more efficient (my perl script has not fully worked
yet)
Threading: a single thread results in a slower rate of propagation than multiple threads,
simply because the thread usually blocks until a scan or infection is complete before
moving onto the next host. We should use multi-threading to speed up the propagation
efficiency. (Multi-threading in my c code has not worked yet)
Stack Randomization
Stack randomization makes program non-deterministic. Randomized executables are
more difficult to debug and support.
If the amount of randomization is insufficient, either the amount of virtual memory
area space where the randomization occurs is small, or the period the randomization
occurs is large, then a determined attacker can repeatedly run an exploit and believe
that within a reasonable amount of time, the attack can succeed.
A larger randomness makes the problem harder. However, it does not change its
fundamental nature. With the ability to keep trying, an attacker will eventually get
around any degree of randomization possible on 32-bit systems. Therefore, stack
randomization is not a tool against both local and targeted remote attacks, but a tool to
degrade the economy of automated remote attacks.
Stack canaries and non-executable stack are stronger protections on stack buffer
overflow than stack randomization.
64-bit OS
If the stack randomization is turned off, and no other stack protection methods are
enabled, exploit the magic8 buffer overflow flaw with 64-bit shell code on a 64-bit
OS is same as what we did on a 32-bit OS.
If the stack randomization is on, then it would be much more difficult for an attacker
to guess the correct function return address on stack. It is because at least 40 bits
available for randomization on a 64-bit OS[1]. Memory pages are usually between 4K
and 4M in size. Brute-force attack on 40 bits is not feasible. For a 32-bit OS, at most
20 bits of the available 32 bits are randomized on a 32-bit OS. Therefore, 220 is still
within the range of a practical attack.
Reference
[1] Shacham “On the Effectiveness of Address-Space Randomization” (CCS 2004)