The Database Hacker's Handbook: Defending Database Servers

Interacting with the Filesystem

The COPY command transfers data between tables and files on disk. The files are accessed under the operating system user privilege that the database runs as. Given the security implications of this command, it is available only to database superusers. The following examples assume access to the database has been achieved through SQL injection in a web application, and that against best practice, the application has connected to the database using superuser credentials.

The COPY command does not accept relative paths (from copy.c: “Prevent write to relative path . . . too easy to shoot oneself in the foot by overwriting a database file . . .”). This prevents using ~ to select the PostgreSQL home directory. The Unix temporary directory, /tmp, is likely to be writable. If the database is version 8.0, configuration parameters such as the database file locations can be determined via SELECT current_settings(<settingname>). The data_directory setting reveals where the database files are actually stored — this will obviously be writable.

An attacker can further compromise a Unix system via the COPY by writing to a number of files:

• .rhosts. If the system is running the rlogin daemon, writing a .rhosts file containing “++” will permit any user to log in as the PostgreSQL user from any host without specifying a password. These days, the security implications of rlogin are well understood and it is disabled by default on most Unix distributions. Furthermore, ...