On a poorly protected system, all current Firebird versions provide the opportunity for arbitrary code to be executed, through the medium of external function libraries, BLOB filters, and custom character set implementations. These external code modules run in the same address space as the server process and with the same privileges.
Accordingly, it is important to protect the server from the possibility of accessing external files and modules that have been written by unauthorized users.
In Firebird 1.0.x, you can configure specific directories to store external code modules and externally mapped data files and apply operating system–level restrictions to prevent unauthorized access. It is strongly recommended that you make use of this capability on filesystems that are capable of supporting it with filesystem access permissions. However, a Firebird 1.0.x server can access external code and data anywhere on the filesystem that is under the host machine’s control.
From v.1.5 onward, the locations of external executables and other external objects can be tightly configured to ensure that the server will throw exceptions if it gets a request to access external objects in the wrong places. For details about these configurations, refer to the notes about external objects at the end of Chapter Configuration and Special Features
Special Risks with Windows Services
Services running under the localsystem profile are considered to be part of the trusted code base (TCB)—they have the same level of implied trust as Windows itself. Running the Firebird service on Windows 2000 and higher carries a recognized risk with regard to malicious exploits designed to execute arbitrary code. The importance of assuring the programmatic integrity of Firebird’s external executables, even under very secure conditions, is crucial. In a Windows environment that is left open to exploits, the fire danger rises to “extreme.”
In short, Windows operating system software on its own provides no credible guarantee of security for database servers, either within a local network or beyond. Potential exploiters must be stopped by tightly configured user access control within the LAN and dependable, third-party firewall products to detect and block attacks.
Windows Embedded Server
The Windows Embedded Server library is, of course, designed to run on machines that do not run a full server. If you have a copy of fbembed.dll housed anywhere on a full server machine, the server security is at risk. Here’s why.
Embedded Server does not use server authentication to verify that a user logging into a database has a right to be doing so. Most application interfaces require a user name and password. Any user name and any password will do —nothing is verified. The internal security of a database designed for embedded server use has to be protected with SQL permissions that limit access to a specific user name. That in itself is a can of worms on a stand-alone machine that is physically available to passers-by.
However, on a machine that is running a Firebird 1.5 server and also has the Embedded Server software on board, a malicious program could be set to run under an Embedded Server when databases are shut down, connect to security.fdb as SYSDBA, steal or damage the user records, read encrypted passwords, and generally please itself by visiting other databases as SYSDBA. When an application connects to each database through fbembed.dll, it locks each database exclusively. A malicious application could hold its connections on databases —including security.fdb —indefinitely.
Embedded Server applications and clients run in the address space of the operating system user. To avoid the risk of a malicious Embedded Server program being dropped into the system, restrict user and group access in the filesystem spaces where databases and Firebird system files live.
Firebird Related Interview Questions
|RDBMS Interview Questions||MySQL Interview Questions|
|Linux Interview Questions||Mac OS X Deployment Interview Questions|
|Windows Administration Interview Questions||Windows Server 2003 Interview Questions|
|SQL Interview Questions||NoSQL Interview Questions|
|Advanced C++ Interview Questions|
Introduction To Client/server Architecture
About Firebird Data Types
Date And Time Types
Blobs And Arrays
From Drawing Board To Database
Creating And Maintaining A Database
Firebird’s Sql Language
Expressions And Predicates
Querying Multiple Tables
Ordered And Aggregated Sets
Overview Of Firebird Transactions In
Programming With Transactions
Introduction To Firebird Programming
Developing Psql Modules
Error Handling And Events
Security In The Operating Environment
Configuration And Special Features
Interactive Sql Utility (isql)
Database Backup And Restore (gbak)
Housekeeping Tool (gfix)
Understanding The Lock Manager
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.