Re: Re: On Polymorphic Evasion

[James Tucker <jftucker () gmail com>]

Having not used shell code exploits of this type before I found the
paper quite interesting. Several principles and facts were confirmed
to me.

1. Due to the fact that the exploit vector must exist in the form of
an illegal jump, it is in fact the final jump in a sequence that is
important.
2. Polymorphic code will always have some "section" for the DE; at
present this section is in fact not hard to find (for a human). I
believe that you could use backwards chaining reasoners and search
techniques to find the end jumps.
3. Search and reasoning are slow by comparison to regexp, but regexp
clearly can be made to fail WITH EASE as it is after all working on
simple patterns not logical deduction (which may be made intractable
at some later date).
4. There are many mathematical constructs which shell coders would
find useful for creating round-robin vectors for the SLED. It is
possible, mathematically so, to create a series of instructions which
over an area will always lead to a particular jump, even with a bad
offset (which should be abused more often too I feel, and what about
hiding data in those variable length opcodes?)
5. The only important part of this technique and focus is the
assembler, and it is the assembler which is seldom understood by most
"kiddies". The result of this is that many exploited systems in which
this technique was used, the code is largely unchanged. It is true
that while this is the case, we still should not ignore the fact that
it is easy to break the regexp matches.
6. A chunk of data flowing in a pipe seldom looks like processor
instructions. Furthermore it will, at worst, contain a number of
opcodes but it is even less likely that it will contain viable
addresses or opcode combinations. An IDS should IMO as an addition
simply detect with fair certainty opcodes pertaining to the platform
under surveillance. In other words, a jpeg with opcodes in it will be
inspected more thoroughly, if it contains a number of blocks of
legally formed opcodes, it may be deemed to be carrying a program.
There are few systems which send binary programs over the wire, and if
you have any my recommendation would be rapid removal.
7. Checkpoints ideals of now performing deep packet inspection and
verifying every packet for well formed protocol messages will be some
effective protection against many vectors used in conjunction with
shell code, providing protocols are made with this in mind (many are
good anyway).

I agree with the statement that most of the C code posted was
unnecessary. I disagree that the discussion is entirely useless, no
matter what the detail level. Everyone has to learn somewhere.

Perfect Material - yes, there are others (clearly, as the technique is
so damned obvious) who have published similar information before.
Having said that, one of the things his paper does point out is that
non-kiddie custom exploits will get under your IDS. Consider it a
gentle reminder that empty logs don't mean your safe. Granted thats a
lot of C code to remind you of such a thing.

xbud - the Internet is anonymous unless you have physical evidence
that someone was interacting with the other end of a terminal; even a
named account may not be who it is supposed to be. Not knowing is not
knowing, no matter what the 'evidence' you see. I would not consider
mail headers viable 'evidence' anyway. Remember, anonymity only
matters if you have reason to care who the other end is. Why should
you care?

When you two are done pissing on each other, why don't you actually
release some better code for this technique. What about building an
app for building your loaders? Consider the possibilities of
statistical (another thing seldom used, but very effective) analysis
being abused for making judgements and for making exploits themselves.
On the note of certain SLEDs not working every time (due to the
unpredictability of the incoming jump), maybe try to improve the
technique using some careful crafting. At this level coding is not an
ART it's a MATH. Optimal solutions DO exist and proofs can be made.


On Fri, 1 Oct 2004 23:46:52 -0700, r00t3d <r00t3d () gmail com> wrote:
> Dear friends,
>
>   The friendly staff of #MSNetworks would like to say that we support
> PERFECT.MATERIAL 110% on his statements. We got your baq e-homie.
>
>    Love,
>       #MSNetworks
>
>
>
> > > It never ceases to amaze me that some egotistical coward asshole
> hiding behind
> > > an anonymous hush,hushmail or in this case gmail account will jump on any
> > > opportunity to insult others work with negative criticism.
> >
> >
> > I didn't mean to offend you; if you learned something from the
> > Fantabulous Fornicators piece of work, then that is really cool and I
> > am pretty fired up for you.  Next time someone posts something that
> > bores me to the point of inspiration, this egotistical coward asshole
> > will be sure to give kinder "feedback" as if said egotistical coward
> > asshole was a first grade teacher commending advances in
> > fingerpainting (I bet you were good at fingerpainting)
> >
> >
> > > Wether this material was worth the read and/or time spent releasing it (I
> > > honestly thought it was the first attempt at discussing security on a
> > > security mailing list in over 10000 emails) but never the less, it was an
> > > attempt.
> >
> >
> > So you didn't understand the paper?  Don't feel bad, there is probably
> > nothing wrong with valuing honesty and good intention over
> > intelligence anyway, I guess that's what good people do.
> >
> >
> > > If you have this much time in your hands to read through this doc and make a
> > > gmail account directly to insult a contributor why not provide some useful
> > > feedback or do everyone a favor and shut the fuck up?...
> >
> >
> > I'm sorry for not using the FIRSTNAME.LASTNAME electronic mail account
> > naming convention that seems to make everyones dick hard.  I will
> > attach a photo id to my next post.
> >
> > Fuck you pussy [I had to use the F-word like you did or my homeboys
> > would have told me I got bitched or something]
> >
> > PERFECT.MATERIAL
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html