IDS mailing list archives

Re: On Polymorphic Evasion


From: Marius Huse Jacobsen <mahuja () c2i net>
Date: Thu, 21 Oct 2004 00:03:17 +0200

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello Phantasmal,

Saturday, October 2, 2004, 2:28:01 AM, you wrote:

PP> On Polymorphic Evasion
PP> by Phantasmal Phantasmagoria
PP> phantasmal () hush ai

PP> What is important, at least to me, is the continual flow of ideas.
PP> As I see it, releasing this paper is an investment in future ideas
PP> from which I myself (and perhaps others in the world) may benefit.


Your approach tries to "gather" all execution paths into a big vein
leading to the heart, which is not necessary. I've encountered pieces
of code that disassembled successfully nearly whichever entry spot you
chose, though in those examples the circumstances (register settings
etc) would be life or death for each path. Note however, that these
were not designed for it, and if someone spends the time to carefully
design such a piece of code, it will do the trick.

Safe reads/writes will be quite possible, assuming that some register
is set to some valid value. And since the stack pointer is most
certainly valid...

Second generation of that would be a generator, that generated such
code from parameters of length and optionally a random seed.

Your reference to the anti-virus fight against polymorphic detection
is quite apt. To my knowledge several adapted execution emulation to
unravel the polymorphic 'shell' around the virus itself, to enable
signature detection. This came at a tradeoff of speed, but was
effective, a lesson that should be noted by IDS writers.

To properly detect nop sleds, it would then have to run the code,
sandboxed or emulated, and of it ended up in the same 'end' state
every time (each time at a different entry point) that would be the
end of the nop sled which could then be flagged correctly. Add a
little fuzz to detect sleds that has intentional failures (parent
post's "jump args") for escaping detection, or cases of 'partial'
sleds which doesn't cover the whole 'sled space' as one knows around
where it will hit (filling the rest with garbage)

However, running that on each bit of data passing the interface would
demand computing resources beyond most. In this respect, filtering and
only scanning data "foreign" to a protocol might help. For cases with
exploits through datafiles, it might be worth passing the file data of
those protocols to file analyzers, which then might feed data those
find foreign into such a scanner.

- --
Best regards,
 Marius                            mailto:mahuja () c2i net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)

iD8DBQFBYmFDl9nYJJam7WsRAlOkAKCscVp/PPshNiHhjSZ1fkvOvAEvNACfbsjt
kRAhx60G5O9nYok5xMClBZ4=
=up96
-----END PGP SIGNATURE-----


--------------------------------------------------------------------------
Test Your IDS

Is your IDS deployed correctly?
Find out quickly and easily by testing it with real-world attacks from 
CORE IMPACT.
Go to http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708 
to learn more.
--------------------------------------------------------------------------


Current thread: