Message-ID: <500A1554.6060401@gce.com>
Date: Fri, 20 Jul 2012 22:35:00 -0400
From: Glenn Everhart <Everhart@....com>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: modest proposal replies

FD folks -
I'd like to thank those who replied to my suggestion. I wanted to reply to a few points.
The suggestion was to use code polymorphism and metamorphism on applications where it is desired
to keep the innards of the application relatively safe.
My thought was that this process would be done to pieces of code in an operation separate from
development of the programs, using some sort of "code transmogrifier" to cause variations in the
instructions used, the layout of the program, and the layout of its data, and to do so such that
potentially every copy of a program would be different. This could make it fairly uneconomical to
attack such code since, while reverse engineering of a copy would be possible, it would give little
help in finding where to attack another copy. (I will use the term "transmogrification" to mean
the modifying of code instructions and layout in a way that nevertheless preserves function.)

It is important that data layouts as well as code layouts get varied, as I think about this.

For this to work, the transmogrifier must not alter the function of the code at all. This might seem
a pipe dream, but the fact is there is malware doing this now. That existence proof is convincing,
and might indicate that somewhere there may be code transmogrifiers already available. Otherwise one
or more would need to be written.

Think of this perhaps as ASLR on steroids. (Perhaps other drugs also <grin>).

Anyhow, on to some points made.
1. This has nothing to do with writing code correctly or not, won't make good code bad or bad code good
if the transmogrifier is implemented right. Nor is the intent to PREVENT reverse engineering. It is to make
reverse engineering economically unrewarding. The intent is also not to hide bad code as such; function
would get left alone. (Besides, how many of the Great Unwashed decide a piece of code is bad because they
disassembled it and found it to be so?)
2. In writing and debugging a piece of code my notion is that you do so, and THEN apply the transmogrification
process. Transmogrified code would still work and still be debuggable, but getting symbol tables and the like
would be hard to do. Some of us have had to debug in octal or hex in our youths and I for one don't much
want to go there again (and published a symbolic debugger that would work remotely so neither I nor others
would need to, way back when too.) Thus the criticism that code debug becomes hard is partly erroneous,
though reports of problems from the field will be harder to reproduce or check. I would imagine that as
a transmogrification process got more mature, such might become easier.
3. A transmogrified program can still be handled as a black box. Its inputs and outputs, whether direct or
via internal system calls, will remain visible. (This scheme would of course be harder to access if the
operating system transmogrified everything on the way in, but even so system calls would have to remain
workable.). At any rate, it is clearly a good idea for anything so handled to have as few system calls as
possible - build it statically linked, built portable, so that libraries and so on are all in there already
(and all get transmogrified with the rest). Then try and make sure inputs and outputs are well guarded,
disguised, encrypted...so that there is not much for outside code to see or alter. This won't help with
everything, but it will make it harder. The system is not 100% protection, and really cannot be. It can
nevertheless hide some things. The thought was that a somewhat obscurely stored key in such a program
might for example be tough to find if it were stored right, in layouts that were scrambled (and preferably
stored in multiple places, or better, partly constituted programmatically.
   Therefore the fact someone can intercept some system calls the program makes has to be understood as a
vulnerability, and programs trying to avoid this happening need to be designed to have as few such points
as possible. Any external calls get outside the transmogrification boundary.
   (This was a good point to make though. A program can be attacked that way regardless, and to some degree
if my program calls system call "fubar", every copy will call that system call and whatever can be gleaned
from that call will work on any copy. If I analyze one transmogrified program, I can get an idea what that
call might do. Of course, being aware of this I can also design my program so that this doesn't threaten
much...
4.  The point here is to raise the cost of attack, and yes, this is security by obscurity. It gives no
complete protection. Where the code's input and output can be encrypted in some way (or encoded so that
it is hard for malware to observe it and understand its i/o [though a human might be able to]), the
code can have some secrets internally which might be used to perform some functions and yet make it
hard for someone to steal the secrets of most of the copies of the code.

The stuff malware does is not all just to avoid detection, but to make it hard to find where to hook
in or to find data structures. If offsets vary and data layout varies and instruction sequences vary,
the only places that will be easy to find will be some global entry points or possibly syscall sites
and immediate arguments thereof. Tracking much else automatically will get to be hard. (Yes, humans can
disassemble code and understand it, but it is a skilled activity and has been tough to teach programs to
do it for years. Rearrangement will be most possible where the code isn't all the way to binary; you
will want to get it before any address relocation is done. I expect something like a special link editor
might be needed.

Imagine an OS that did this kind of thing to its code as it loaded everything just for (far fetched)
laughs. You could of course find main entry points, but finding internal places to patch would become
a monumental pain. I've built such to search for some instructions to be somewhat sub-version-insensitive.
This kind of thing blows that strategy out of the water. (It'd also make writing third party systems code
a whole lot harder, whatever your motives. That's not something I am happy with, but I won't worry just yet ;-)
...

Thanks for all the thoughtful responses though.
Glenn Everhart


Anyhow that is what has occurred to me about this.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists