Message-ID: <f8f8ff7304100211182258b5f@mail.gmail.com>
Date: Sat, 2 Oct 2004 11:18:21 -0700
From: Vlad902 <vlad902@...il.com>
To: phantasmal@...h.ai
Cc: full-disclosure@...ts.netsys.com, bugtraq@...urityfocus.com,
   focus-ids@...urityfocus.com
Subject: Re: On Polymorphic Evasion


On Fri,  1 Oct 2004 17:28:01 -0700, Phantasmal Phantasmagoria
<phantasmal@...h.ai> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> - ------------------------------------
> 
> On Polymorphic Evasion
> by Phantasmal Phantasmagoria
> phantasmal@...h.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

Powered by blists - more mailing lists