Hi,

just a thought - but maby it is possible to bind the database lib
somehow to the database file? The database process identity might be
secured using binary encryption (in this case for ELF (linux)):

http://www.theparticle.com/files/txt/hacking/phrack/p58-05.txt

Those people encrypt the binary process - so the installer could take
care of encrypting the file. I'm not sure wheater it was described in
that document - but I have heard about implementations, that must either

1) enter a password before executing the binary
2) the binary can only run on a specific computer (bound to the
processors id)

to execute a binary

3) or it can be executed only 5 times ...

so in that case, the database can only be accessed using a specific
libfbclient.so - you can make backups etc. using the correct sysdba's
password on that machine using that lib - but on other systems / using
other libs it might not work.

The problem would be transportablility between the plattforms ...

Chris

Am 15.10.2008 um 02:13 schrieb Alexandre Benson Smith:

> 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
>
>
>