6.1 Ensure 'Attack Vectors' Runtime Parameters are Configured

Warning! Audit Deprecated

This audit has been deprecated and will be removed in a future update.

View Next Audit Version

Information

Understanding the vulnerability of PostgreSQL runtime parameters by the particular delivery method, or attack vector.

Rationale:

There are as many ways of compromising a server as there are runtime parameters. A combination of any one or more of them executed at the right time under the right conditions has the potential to compromise the RDBMS. Mitigating risk is dependent upon one's understanding of the attack vectors and includes:

Via user session: includes those runtime parameters that can be set by a ROLE that persists for the life of a server-client session.

Via attribute: includes those runtime parameters that can be set by a ROLE during a server-client session that can be assigned as an attribute for an entity such as a table, index, database, or role.

Via server reload: includes those runtime parameters that can be set by the superuser using a SIGHUP or configuration file reload command and affects the entire cluster.

Via server restart: includes those runtime parameters that can be set and effected by restarting the server process and affects the entire cluster.

NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance.

Solution

In the case of a changed parameter, the value is returned back to its default value. In the case of a successful exploit of an already set runtime parameter then an analysis must be carried out determining the best approach mitigating the risk.

Impact:

It can be difficult to totally eliminate risk. Once changed, detecting a miscreant parameter can become problematic.

References:

https://www.postgresql.org/docs/12/static/runtime-config.html

See Also

https://workbench.cisecurity.org/files/2536