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 [davidat_private] 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: yinrongat_private <mailto:yinrongat_private> 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.
This archive was generated by hypermail 2b30 : Tue Feb 04 2003 - 13:19:23 PST