The worm exploits a buffer-overflow vulnerability in OpenSSL 0.9.6d (and older). A description of the exploit follows:
The buffer-overflow vulnerability is on the heap. A description of heap-based buffer-overflows is presented here:
· Good overviews: anonymous (Phrack Vol. 11, Issue 39, file 9), Matt Conover (w00w00 Security Team)
· Very detailed description: MaXX (Phrack Vol. 11, Issue 39, file 8)
The worm’s exploit is based on the OpenSSL exploit written by Solar Eclipse. It is titled openssl-too-open. Solar Eclipse’s readme-file provides a nice tutorial on how the exploit works. The worm’s exploit is very similar to Solar Eclipse’s. (However, the two exploits might not be coded identically, e.g., the first half of their heap exploit-code may be different. We did not thoroughly investigate differences between the worm's exploit and Solar Eclipse's.)
Below are two figures, and some commentary, that we’ve provided to assist in understanding both Solar Eclipse’s tutorial and the worm’s exploit code. Figure 1 shows the buffer overflow. It uses the technique of placing a “fake chunk” on the heap. The fake chunk’s “chunk size” has a flag set to indicate that the previous chunk (“altered chunk”) is not in use. When the overflowed chunk (struct ssl_session_st) is freed, the fake chunk will thus trick free() into writing the contents of bk to the location pointed at by fd (minus 12 bytes).
Figure 1
The next figure shows how the buffer-overflow data sets the bk and fd fields. free()’s function pointer is overwriten in the symbol table.
In building the exploit, the location of the free() function pointer can be found via this command:
Objdump –R /usr/sbin/apache | grep free. Solar Eclipse’s tutorial describes how to find the exploit-code’s address on the stack.
Figure 2