Execution of Arbitrary Code - Firebird

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.

Firebird 1.0.x

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.

Firebird 1.5

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.


All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

Firebird Topics