Re: Obfuscated stored procedures (was Re: Oracle and Postgresql) - Mailing list pgsql-general

On Tue, Sep 16, 2008 at 09:39:03AM -0400, Jonathan Bond-Caron wrote:
>
> I agree here. I hope there's a consensus that it does offer some level of
> protection.

There is not, in fact, in the security community a consensus that it
offers some level of protection.  There are some security people who
think that obfuscation and secrets are one of the tools (and one of
the weakest) to protect the computing infrastructure.  There are
others who claim, as strongly and with as great authority, that
anything that cannot be secured even if the attacker knows all about
it (excluding the private key itself) cannot be secured at all.

> After some research, I found this article that I believe will make a
> stronger use case:
> http://www.iosn.net/network/news/Managing%20the%20insider%20threat%20through
> %20code%20obfuscation

That article is not evidence for your conclusion.  Obfuscated code in
the example cases in the article would not be a good investment.

In the first example, an insider who is an expert in the system
deleted a key file: it would make no difference if the code were
obfuscated, because an expert operator doesn't need to understand the
innards in order to be able to know which files are critical.  (Your
expert operators _have_ to know which are critical, because they have
to pay more attention to those files.)

In the second example, of Mallory the disgruntled employee, we don't
have any information about what Mallory knows; so either Mallory's
defeat of the access controls (which is the real problem) will give
Mallory access to a system she understands, or else she'll have to
comprehend a complex system on the fly while evading detection of the
access control failure.  Obfuscation isn't likely to provide
additional defence against a vandal, which is what the
disgruntled-employee scenario represents.

Finally, the bigger example of distributed code that is decompilable
doesn't prove much, either.  If you are analysing the code in order to
attack it for a given end, you can do this just as easily with opaque
bytes (if you couldn't, Windows wouldn't be plagued with the security
problems it is: there wasn't a remarkable rash of new exploits that
appeared after the apparently leaking of the Windows source).

Obfuscation is mostly useful against the casual attacker.  There are
better and less costly measures against such attackers.  In
particular, careful management of access controls is far more
important.

The important thing to remember is that, if the secrecy of the system
is your main or only defence, you're going to be in trouble because
such systems are brittle.  When they fail, they fail spectacularly.

All of that said, I can in fact think of use cases where casual users
not being able to view the source of a function could be useful.
These cases have more to do with corporate governance and internal
"Chinese walls" than any real security.  They're the sort of thing
that would make auditors happy, and for that reason they might be
worth implementing.  So far, I don't believe anyone's had an itch of
this sort strong enough to scratch.

A

--
Andrew Sullivan
ajs@commandprompt.com
+1 503 667 4564 x104
http://www.commandprompt.com/