Full Disclosure mailing list archives
Re: On Polymorphic Evasion
From: Vlad902 <vlad902 () gmail com>
Date: Sat, 2 Oct 2004 11:18:21 -0700
On Fri, 1 Oct 2004 17:28:01 -0700, Phantasmal Phantasmagoria <phantasmal () hush ai> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - ------------------------------------ On Polymorphic Evasion by Phantasmal Phantasmagoria phantasmal () hush ai
...
- ------------------------------------ - ---- 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
Current thread:
- On Polymorphic Evasion Phantasmal Phantasmagoria (Oct 01)
- Re: On Polymorphic Evasion zero (Oct 02)
- Re: On Polymorphic Evasion Ali Campbell (Oct 02)
- Re: On Polymorphic Evasion Andrew Farmer (Oct 02)
- Re: On Polymorphic Evasion Ali Campbell (Oct 02)
- Re: On Polymorphic Evasion Vlad902 (Oct 02)
- <Possible follow-ups>
- Re: On Polymorphic Evasion PERFECT. MATERIAL (Oct 01)
- Re: Re: On Polymorphic Evasion xbud (Oct 01)
- Re: Re: On Polymorphic Evasion PERFECT.MATERIAL (Oct 01)
- Re: Re: On Polymorphic Evasion xbud (Oct 01)
- Re: Re: On Polymorphic Evasion r00t3d (Oct 02)
- Re: Re: On Polymorphic Evasion James Tucker (Oct 02)
- Re: On Polymorphic Evasion zero (Oct 02)