Re: [Full-disclosure] modest proposal replies

[Glenn Everhart <Everhart@xxxxxxx>]

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/