dynamic and static code injection as well as population concept

["Peter Huang" <yinrong () rogers com>]

First of all, thank a lot for your comments and (dis)encouragements. I will
not trumpet my "brand-new" old idea here.

Anyway, I would like to briefly discuss the my further analysis of the SQL
Sapphire Worm.

Code Offset        Functionality
; 000-060 ---- Buffer Buster
; 061-064 ---- Critical Jumping Board (JMP ESP)
; 061-07C ---- Unnecessary left-over from original C code,
;              showing a signature of 6 byte of 01 if it means anything
; 07D-093 ---- Worm-rebulding process
;              Probably can just do with "sub esp, 068h"
; 094-141 ---- Run-time function pointer manipulation
; 142-177 ---- Worm Replication Process

There are four critical places that allow the SQL Slammer Worm to be
successful.

1. The data block 000..060 serves the buffer overflow to enable the late
exploitation possible.
2. The precise location of the jump board (two bytes of executable FF E4) at
0x42B0C9DC located in sqlsort.dll
3. The two critical function pointers for LoadLibraryA and GetProcAddress
exist at predictably locations in sqlsort.dll.
4. Executable Stack

If the sqlsort.dll has been rebased to a different location as David
Litchfield [david () ngssoftware com] suggested, then the SQL server would not
have that "jumping board" at that particular location. Then, the Worm would
just do something unpredicable before it crashes. Unfortunately, there are
quite a few places where executable "FF E4" bytes in the sqlserv.exe (not as
constant across service packs as that in sqlsort.dll though).

In this particular Worm, it (ab)uses the two critical function pointers for
LoadLibraryA and GetProcAddress. Probably, the worm can dynamically search
through the intact PE header for the executable (quite a lot exe files at
0x400000) for these two function pointers even if they are not present in
sqlsort.dll. Of course, both must be present for the exploitation to happen
(or the worm has to use lots of hardcoded addresses, which is not good at
all). For sure, rebasing and installation-time exe file linking definitely
will not solve all the problems. However, it does help to make the
exploitation of existing vulnerabilities difficult. It definitely helps to
secure if OS zero out unused info such as PE header in memory (is PE header
info used at all after an exe is mapped into memory?).

So, if any of 4 factors above is negative, then this worm would not explode.
By the way, the SP3 seems to patch the first hole. However, the remaining
three are still valid (even the function addresses, FF E4 at 0x42B0C9DC (if
not rebased) ). So, if someone discovers another buffer overflow hole, (s)he
does not have to work that hard to fully exploit the discovery.

Enough said about the dynamic code injection, let me briefly explain a
static vulnerability of PE format. I dub the exploitation of this PE
vulnerability as "Mobile Executable Element or XPoson" in comparison to
transposon in biology. Probably, some W32 viruses might have utilized the
concept presented as http://members.rogers.com/yinrong/articles/XPoson.htm
and http://members.rogers.com/yinrong/articles/XPosonDetails.htm. Due to
very limited resources, I do not know which W32 viruses fit in this
catagory.

In contrast and complement to dynamic code injection, an XPoson exploits the
vulnerability of PE .exe file (DLL files and Unix/Linux's ELF files need
further investigation) and utilizes the two functions of LoadLibrary and
GetProcAddress and statically injects code into an .exe image file. If all
of the two function imports are not present, the XPoson creates a new
IMPORTS section to compensate. In contrast of W32 Klerz virus which abuses
the .resource section and implements a very complicated scheme to kill/evade
the detection of Anti-virus program, an XPoson runs in the context of the
infected program either as a normal function hookup or as a separate thread.
A generic XPoson element can infect the whole population of different
executables on one machine. A specific XPoson, delivering some Trojan
functions, can hide anywhere and wait for its turn to attach to the target.
Without diversification of an executable population, one particular XPoson
can work well with all the same executable on different machines. So, some
popular programs such as PGP can be a target of an particular XPoson and
then RSA mechanism is being attacked at its root: its keys. Even with the
diversification (I mean installation-time-linking), more intelligent
functions such FLIRT (Fast Library Identification and Recognition Technology
http://www.idapro.com/) and Substractive Identification of Libraries (SIL,
to be defined later) can be embedded into an XPoson to break through the
wall and peek into what an XPoson is designed to. For sure, an XPoson needs
the first kick somehow to roll down the hill.

As a Chinese proverb says, it is not that late to mend your fence after you
lost a sheep. So, let's mend the fence.

Alright, thanks a lot for your time to respond. I appreciate that.

Best regards

Peter Huang
Tel: (613) 254-5747
Email: yinrong () rogers com <mailto:yinrong () rogers com>
URL: http://members.rogers.com/yinrong

P.S.
Please let me know there might be a job opportunity for me if you have time
to check my resume http://members.rogers.com/yinrong/PeterHuang.htm or
http://members.rogers.com/yinrong/. No flame please.