Detections
Analytics

6.1 Understanding attack vectors and runtime parameters

Information

PostgreSQL runtime parameters can be set at the cluster, database, role, and session levels. How an attacker can view or modify a given parameter, the attack vector, depends on where the parameter is set and what access the attacker has already obtained. Understanding this relationship is a prerequisite to correctly configuring and protecting the runtime parameters addressed in subsequent recommendations.

Runtime parameters control security-relevant behavior of the RDBMS. A change to any one or more of them, executed under the right conditions, has the potential to compromise the RDBMS. Mitigating risk is dependent upon one's understanding of the attack vectors, which include:

 - Via user session: those runtime parameters that can be set by a ROLE and persist for the life of a server-client session.
 - Via attribute: those runtime parameters that can be set by a ROLE and assigned as an attribute of an entity such as a table, index, database, or role.
 - Via server reload: those runtime parameters that can be set by the superuser using a SIGHUP or configuration file reload command and affect the entire cluster.
 - Via server restart: those runtime parameters that can be set and effected by restarting the server process and affect the entire cluster.

NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance.

Solution

In the case of a changed parameter, set the value back to its documented approved value and reload or restart the server as required by the parameter's context. In the case of a successful exploit of an already set runtime parameter, an analysis must be carried out to determine how the parameter was changed, remove the access that permitted the change, and prevent future exploitation.

See Also

https://workbench.cisecurity.org/benchmarks/26344

Item Details

Category: CONFIGURATION MANAGEMENT

References: 800-53|CM-6, 800-53|CM-7, CSCv7|18.11

Plugin: PostgreSQLDB

Control ID: 61ac0d5fb0b51bd4cb49c30052c87d7fe7e5a0266683c92416242957843d1733