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
