Roman Rokytskyy wrote:

>> While the server is running there is no way to change the executable,
>> the compromise must be done replacing the binaries and the only way (*I
>> can think of*) to check this is to verify the binaries signatures
>> *manualy* before providing any keys to the server.
>>
>
> You forget the code injection directly into the process in memory -
> that's the way exploits work.
>

Yes, but AFAIK the code injection could not put a lot of new
functionality or change the current functionality in a higher degree, it
must substitute the code in place (byte for byte), it's possible, but
the side effect would be minimized for the implicit limitations.

> So, let's see. In order to have access to the database file, user is
> either given that access explicitly or possesses the admin rights.
>

Right

> Former is not interesting for us

Besides we can prevent the stolen data be read without the correct key,
but I agree with you...

> , latter means that the user can also
> execute arbitrary code, which means he has a possibility to run
> privileged code on the kernel level and from there modify the memory of
> the Firebird process to execute some additional code.
>

yep... but only to some degree (as I said above)

> Bad. We can't protect against anybody with admin rights while Firebird
> is running and cached the key in memory.
>
>

There is more... OS move the data on the RAM to SWAP, and thereafter we
have the key on disk :)

>> If the server is compromised at physical level, machine stolen, no one
>> would be able to access the data without a valid password.
>>
>
> If the machine is stolen (and will have to be rebooted), it is enough to
> put the database file on the encrypted drive.
>

of course... that is just a side effect of the data being encrypted, if
we just use TrueCrypt (as I do !) we are protected only with the volume
unmounted, if the database is encrypted we are protected even with the
volume mounted, and if we need protection with the mounted volume there
is no reason IMHO to do it twice (at file level and volume level)

> If the machine is compromised at physical level, we have to distinguish
> whether one can get the admin rights without shutting it down or not.
>
> If no - we do not care, we can always protect the file on the file
> system by means of OS. If yes - see above about the code injection on
> the fly.
>

Ok... I cannot say a lot of in memory code injection, as I understand
it, it's possible, but the possibilities are a lot limited compared to
change the binary for a custom build, change the binary with a custom
build open all kinds of possibilities, while in memory code injection
must be a change of byte per byte, so one cannot do a lot without
breaking the original functionality, or even make the software unable to
run.

>
>> If the server is compromised and the binaries replaced it would be noted
>> by checking the binary signatures by the admin at start-up time or when
>> he needs to provide the keys.
>>
>
> To protect yourself from rootkits, you would have to take the server
> down, access the hard drive from another computer and look for the known
> rootkits. This however does not protect you from the unknown ones.
>

ok

> Without doing this you have no chance to check the signature, since
> rootkit, after activation, can fake you the right binary data when
> accessing the file via normal API calls. Even more, the exploit does not
> really need to modify the binary - it can watch the processes that are
> starting and modify the running process.
>
>

Again.. cannot comment on the in memory modification... But FB would be
as weak as any other program in the world.

>> If the server is running, and in someway one could access the database
>> file, he could not access the data, since all data is encrypted and the
>> key is not on the engine code nor the database file.
>>
>
> It is in memory - can be accessed with appropriate permissions:
>
> "Recovery of Encryption Keys from Memory Using a Linear Scan
> Hargreaves, C.; Chivers, H.
>
> Availability, Reliability and Security, 2008. ARES 08. Third
> International Conference on
> Volume , Issue , 4-7 March 2008 Page(s):1369 - 1376
> Digital Object Identifier 10.1109/ARES.2008.109
>
> Summary:As encrypted containers are encountered more frequently the need
> for live imaging is likely to increase. However, an acquired live image
> of an open encrypted file system cannot later be verified against any
> original evidence, since when the power is removed the decrypted
> contents are no longer accessible. This paper shows that if a memory
> image is also obtained at the same time as the live container image, by
> the design of on-the-fly encryption, decryption keys can be recovered
> from the memory dump. These keys can then be used offline to gain access
> to the encrypted container file, facilitating standard, repeatable,
> forensic file system analysis. The recovery method uses a linear scan of
> memory to generate trial keys from all possible memory positions to
> decrypt the container. The effectiveness of this approach is
> demonstrated by recovering TrueCrypt decryption keys from a memory dump
> of a Windows XP system."
>

And as said before, the key could even be on the SWAP file or the
hibernation file, the former because the memory region could be swapped
out to disk, the later, because all memory would be copied to disk on
hibernation.

We must take into account that:
1.) Temp/Sort files are written to disk and contain potentially
sensitive data
2.) User has legitimate access to the database, and could extract the
data since the server would decrypt it for free, if the user has access
trough your application it can access trough any other application,
views, grants, etc. would limit the amount of data he can see, but if he
can see trough your application, he would be able to extract it as he
wishes.

Every time I talk about it I tend to think that it's an impossible task
to accomplish :)

>
>> When I was learning about reverse engineering (again, I am not a reverse
>> engineer, just try to learn a bit as a hobby and to try to protect
>> myself a bit), I had read something like:
>> If there is code it could be reverse engineered, how hard is to find the
>> right place to change, and how many time it will take could change, but
>> it is always possible.
>>
>
> Yup - and that's exactly what those tools do - make the process complex
> and expensive enough.
>

Yes, but I am not sure that a standard obfuscation package could do a
good job, since it's standard :) The same way could be a de-obfuscation
program that would target all the obfuscated programs by that famous
package.

>
>> The only thing that looks more secure is if part of the code (the key,
>> the integrity check code, and a critical part of the code) is stored on
>> a dongle that is encrypted and tied in someway to the serial code of the
>> dongle so it could not be copied, Without the dongle one has a missing
>> part of the code, inside the dongle is stored the key to decrypt the
>> data or the executable itself, inside the dongle is the validation code,
>> and if the dongle is duplicated the code would be invalid.
>>
>
> Solved as well - one popular business software in Russia was protected
> by such dongle. After short period of time software emulators of such
> dongles were created and keys were available for free.

There is a lot of software that relies on dongles to protection (3D
Studio, Autocad, etc.), the guy who explained me that approach (that I
even don't remember if it's exactly as I described) told me that it's
the only reliable way since part of the code resides on the hardware and
that the hardware could not be copied, don't know how right he was, and
if it's possible or not to make a copy protected hardware. My feeling
from all I have read about anti-piracy techniques is that there is no
100% reliable way. That's is the reason I said "looks more secure" and
not "100% secure" :)

> Even more, for
> some time the support of that company was suggesting to use those
> emulators to solve some compatibility issues on hardware level
> (naturally, they recommended to extract the key from the dongle first to
> have a "legal" emulator).
>

LOL. Pretty good !

> Roman
>

Roman,

I am not saying that my suggestion is perfect and in fact I even don't
know if it is at least a bit good :) The first thing I said on my first
message is that I am not a security expert, I am just asking if that
approach could be used, and if not, where is the weakness (to understand
better the problem). And I don't believe there is any way to have a 100%
secure deployment using embedded or where the user has full control of
the server, It's only a thing that could make the data extraction
process hard enough to be interesting to the average user, or to data
that is not classified as "top secret" or valuable enough.

I don't know how well the OS protects the application memory space from
other applications, I have never gone to study this, so I don't know how
successful and hard to write an application that scans the memory
looking for the valid keys.

I am just suggesting to use an approach that looks "good enough" and is
used by other OS software, that has the same problems as us
(availability to one make a custom build that steal passwords). But as I
can see, with this approach we will be as good as any other RDBMS
regarding database encryption, the same security holes apply to any of
them (root kits, in memory code injection, physical access to the file,
etc.) I am just trying to handle the part they don't have the problem
that the code is open sourced and provides means to a malicious user
build a custom version.

see you !

--
Alexandre Benson Smith
Development
THOR Software e Comercial Ltda
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br