There are no absolutes
here. Obfuscation has its place. I use Xenocode's Obfuscator for my .NET code. I
do not do it to try to hide bad code from intense scrutiny from potential
attackers. I do it to hide business logic from the looky-loos who have tools
like Reflector and may want to blatently rip it off. (which has happened
before)
Weighing my risks accordingly, I expect
that once the byte code is converted to native instructions on the target
system, that any competent person can easily look at the disassembly and do
their bidding. If they are gods with disassemblers, all the power to them. But
they can do that with any code on the system, be it driven from bytecode
converted to native or directly linked with the linker. So
the threat level is the same at that point.
Obfuscation is just another layer of
defense for business logic from what I would consider 'layer one'
attackers. Depending on the tools you use it can work, and work well. It's
designed to mitigate against a certain type of threat. However, anyone with
enough patience, a copy of Gary and Greg's
"Exploiting Software" and a copy of IDA Pro will be able to break the
shackles of such tools and get deep into the bowels of the executing code.
Nothing is going to stop that.
Now let's look at your original example of
being able to get a great deal of information about the internals of
databases etc. The reality is that such information shouldn't be IN
the application in the first place. When possible secrets like db passwords
should use the native operating system's security mechanisms (ie: Trusted
connections, Windows Authentication, DPAPI etc when working
on Windows) to store and manage credentials. Rather
that concatinating query strings (which are harder to obfuscate btw) try to
use things like stored procedures (where appropriate) that keeps the
db structure on the server while at the same time giving another layer of
validation control for input. I know I am preaching to the choir here.
My point is that no matter what the
language is, and what the threat is you are expecting to mitigate against,
different tools can do different things. Obfuscation has it's place. As does a
deep hole, some cement and a shovel. You can dig your own bunker however you see
fit. How strong you make it depends on what sort of attack you are fretting
about.
From: [EMAIL PROTECTED] on behalf of Kenneth R. van Wyk
Sent: Thu 12/15/2005 7:09 AM
To: Jose Nazario
Cc: Secure Coding Mailing List
Subject: Re: [SC-L] Managing the insider threat through code obfuscation
On Thursday 15 December 2005 09:26, Jose Nazario wrote:
>
if the person can develop exploits against the holes in the code, what
>
makes you think they can't fire up a runtime debugger and trace the code
>
execution and discover the same things?
Nothing makes me think that at
all; in fact, I was quite skeptical of the
various product claims, which is
why I wanted to hear about others'
experience with
them.
Cheers,
Ken
--
KRvW Associates, LLC
http://www.KRvW.com
_______________________________________________
Secure
Coding mailing list (SC-L)
[email protected]
List information,
subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List
charter available at - http://www.securecoding.org/list/charter.php
_______________________________________________ Secure Coding mailing list (SC-L) [email protected] List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
