Issue Details (XML | Word | Printable)

Key: CORE-4332
Type: Bug Bug
Status: Open Open
Priority: Critical Critical
Assignee: Unassigned
Reporter: PizzaProgram Ltd.
Votes: 0
Watchers: 2

If you were logged in you would be able to see more operations.
Firebird Core

firebird.log file security issue

Created: 05/Feb/14 08:09 AM   Updated: 14/Apr/18 06:08 PM
Component/s: Security
Affects Version/s: 2.1.5 Update 1, 3.0 Alpha 1, 3.0 Alpha 2, 2.1.6, 3.0 Beta 1, 3.0 Beta 2, 3.0 RC1, 3.0 RC2, 3.0.4, 4.0 Beta 1, 2.5.9
Fix Version/s: None

Environment: Windows

 Description  « Hide
Currently (with FB version of 2.1 or 2.5) the only way to protect data inside an FDB file is:

- to HIDE the database file itself

(Possibly on an encrypted volume, with no/fake extension, between many other "temp"/fake files, ... ).
The connection string/Path can be encoded in the client program, so it is a nice and easy way to access it safely.
 (... as I've thought until now :( )

But the log file is revealing this secret !
So a thief/hacker can :
- easily look into the log file
- see the DB path+name where to look for it,
- and copy the whole DB file to a pen-drive in no time :(

So it would be VERY important to be able to DISABLE some kind of data being logged:
log_hide_db_path=1; // would HIDE the database name and location.
log_level=0; // no logging at all for the currently connected database file !

It would be logical to set these parameters by [connection parameters] from the API.

Currently this IS an urgent security issue !
I MUST provide data security to my clients.


 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Dmitry Yemanov added a comment - 05/Feb/14 08:29 AM
I've replied to both your recent comments:

that your understanding of security is wrong. Nothing can help you if a hacker has full access to your server box, period. If you're telling about database being distributed to client computers along with your application, then database encryption is the only solution.

So this ticket is likely to be rejected.

PizzaProgram Ltd. added a comment - 06/Feb/14 03:15 AM - edited
The main difference is Time.
It takes minimum 30 minutes to find the real DB. (If the thief even realizes he's looking at a fake one.)
But the log file makes this possible within 30 sec.

So the question remains:
 - How else is it possible to prevent Firebird engine logging DB filenames and path?
I was searching for any solution in the last 30 hours, but the only one possibility is, when the Engine is configurable of this behavior by connection based.

Thank you VERY much!

PizzaProgram Ltd. added a comment - 25/Feb/14 12:43 PM
I'm trying to solve this issue by creating an external UDF. (Completely forgot about this great feature..;) )
1. ANY client-app. can start it after connecting.
2. The engine will be able to run it with administrative privileges. :D
Hopefully will not block/freeze the running FB engine while overwriting/clearing the firebird.log file.

PizzaProgram Ltd. added a comment - 14/Apr/18 10:16 AM - edited
More than 4 years past.

UDF method isn't working, for many reasons. (example: if someone is deleting the UDF file)
This must be solved from the engine itself!
Please prioritize this task up.
At least in 3.x + 4.x versions.

>> "Nothing can help you if a hacker has full access to your server box, period."

Normally I would agree, but:
- I'm not talking about high-professional hackers, but "simple iT guys", in a ratio of 1:1000
- They have tried many times already during the last 2 years!! (Customers reported to me every time after an attempt.)
- Nobody was able to do it yet. (Luckily!) Because I'm protecting customer's DB in every way I can.
 (access deny, encryption, hiding volume, fake DBs, etc)
- But all those of my effort are useless if someone gets the idea to look at the LOG file, that shows the real path. :(

Please consider: I'm not talking about a THEORY, but real cases, real people, real problems.

From 2018.05.25 on > new European Law regulation is effective about data protection and handling. (2016/679/EU)
I would like to secure all my customers data until than.

Adriano dos Santos Fernandes added a comment - 14/Apr/18 06:08 PM
This ticket should be closed without changes IMO.

Notion of security is completely wrong by the OP.