On Fri, 1 Oct 2004 17:28:01 -0700, Phantasmal Phantasmagoria <[EMAIL PROTECTED]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > - ------------------------------------ > > On Polymorphic Evasion > by Phantasmal Phantasmagoria > [EMAIL PROTECTED] > ... > - ------------------------------------ > - ---- Future ------------------------ > > Let us consider the final evasion technique displayed in dragon_morphsled. > At first glance there is only one element that is stopping Serna's method > from working, that being the introduction of a jump operation. If we > were to treat the jump opcode used (0xeb) as a junk nop then the sled > would be detected as normal. > > There are two counter arguments to this. Firstly, adding the jump opcode > to the list of junk nops would indeed detect dragon_morphsled, but dragon_nopjump > would remain undetected, provided the jump calls were numerous enough > and that their argument was not in the list of valid nops. This does > of course introduce the possibility for first-time failure of the exploit, > but depending on the circumstance this would not be a significant downfall. > > The second argument lies in the fact that the jumps could be replaced > by any number of 2 or even 3 byte operations, provided that the operation > has no effect or that the effect is reversable by another suitable operation > somewhere in the sled. Some might claim that this is no better, that > these new operations could be added to the list of junk opcodes. The > problem with doing this lies in the sheer number of possible operations > suitable for the technique. Simply put, to add all of these to the list > of junk opcodes would cause an unacceptable level of false positives.
To add onto this several more arguments exist. One being you could not only use single bytes nops; you could also use instructions that take an 8-bit immediate or a 32-bit immediate as nops and simultaneously abuse instruction prefixes. An example of such an instruction is: [ operand size override* ] [ rep/repne instruction prefix* ] [ segment override^* ] [ 32-bit instruction prefix ] [ 4 nops ] [ rep/repne instruction prefix* ] [ segment override^*] [ 8-bit instruction prefix ] [ nop ] * optional ^ dangerous. Doing this would add a large amount of false positives as there are many prefixes and even more instructions that take a 32/8 -bit immediate. An example of such a nop is: 00000000 6466F3B89090 fs rep mov ax, 0x9090 00000006 90 nop 00000007 90 nop 00000001 66F3B89090 rep mov ax, 0x9090 00000006 90 nop 00000007 90 nop 00000002 F3B890909090 rep mov eax, 0x90909090 00000003 B890909090 mov eax, 0x90909090 00000004 90 nop 00000005 90 nop 00000006 90 nop 00000007 90 nop As these disassembles show, this instruction acts as a nop from any position. This allows one to use a number of override prefixes (possibly ones that override each-other) and would force IDSs to add a lot of functionality and/or singly-byte combinations that would lead to more false positives. I have not covered all instruction prefixes for times sake. Another approach to confuse IDSs would be using instructions that use ModR/M and cleverly crafting instructions that are structured like: [ prefix to instruction that takes imm8 ] [ prefix to ModR/M instruction ] [ nop that is safe as a ModR/M ] An example of such an instruction is: 00000000 6A01 push byte +0x1 00000002 F5 cmc 00000001 01F5 add ebp,esi 00000002 F5 cmc IDSs would again have to add a staggering amount of nop signatures to detect very intertwined instructions that could be interpreted in many ways and use a number of techniques such as prefix overrides, 32-bit instructions, and clever use of ModR/M (possibly all in one large nop!) > - ------------------------------------ > - ---- Thoughts ---------------------- > > Being of an entirely detached and unsympathetic nature I did not release > this paper for any one particular purpose. What I mean in saying this > is that I was not in the least interested in how the aforementioned techniques > would affect security. For good or bad, whatever they might be, it doesn't > really matter. What is important, at least to me, is the continual flow > of ideas. As I see it, releasing this paper is an investment in future > ideas from which I myself (and perhaps others in the world) may benefit. -vlad902 _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
