EP11-00-007400 - The EDB Postgres Advanced Server must prevent non-privileged users from executing privileged functions, to include disabling, circumventing, or altering implemented security safeguards/countermeasures.

Warning! Audit Deprecated

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

Information

Preventing non-privileged users from executing privileged functions mitigates the risk that unauthorized individuals or processes may gain unnecessary access to information or privileges.

System documentation should include a definition of the functionality considered privileged.

Depending on circumstances, privileged functions can include, for example, establishing accounts, performing system integrity checks, or administering cryptographic key management activities. Non-privileged users are individuals that do not possess appropriate authorizations. Circumventing intrusion detection and prevention mechanisms or malicious code protection mechanisms are examples of privileged functions that require protection from non-privileged users.

A privileged function in the DBMS/database context is any operation that modifies the structure of the database, its built-in logic, or its security settings. This would include all Data Definition Language (DDL) statements and all security-related statements. In an SQL environment, it encompasses, but is not necessarily limited to:
CREATE
ALTER
DROP
GRANT
REVOKE

There may also be Data Manipulation Language (DML) statements that, subject to context, should be regarded as privileged. Possible examples include:

TRUNCATE TABLE;
DELETE, or
DELETE affecting more than n rows, for some n, or
DELETE without a WHERE clause;

UPDATE or
UPDATE affecting more than n rows, for some n, or
UPDATE without a WHERE clause;

any SELECT, INSERT, UPDATE, or DELETE to an application-defined security table executed by other than a security principal.

Depending on the capabilities of the DBMS and the design of the database and associated applications, the prevention of unauthorized use of privileged functions may be achieved by means of DBMS security features, database triggers, other mechanisms, or a combination of these.

In Postgres, a user or group role that has been granted the SUPERUSER privilege can perform any action in the database. As such, the SUPERUSER privilege should only be granted to a limited set of approved users. The SUPERUSER privilege can be assigned to a role when the role is created. It can also be assigned or removed from a role via an ALTER ROLE statement.

Postgres also provides the CREATEROLE, CREATEDB, REPLICATION, and BYPASSURLS privileges that can be granted to non-superuser roles to allow them to perform a limited set of privileged activities such as creating databases, creating user and group roles, managing replication slots, and bypassing row level security restrictions. Although not as all-encompassing as the SUPERUSER privilege, these privileges must only be granted to users who are approved to perform these activities. Like the SUPERUSER privilege, these privileges can be assigned to a role when the role is created. They can also be assigned or removed from a role via an ALTER ROLE statement. The PostgreSQL CREATE ROLE documentation provides more information about these privileges. See: https://www.postgresql.org/docs/current/sql-createrole.html

In addition to the SUPERUSER, CREATEDB, and CREATEROLE privileges, a user may be granted one or more default roles that provide access to certain privileged capabilities and activities. A listing and description of the default roles provided with Postgres is documented at the following link:

https://www.postgresql.org/docs/current/default-roles.html

Roles and privileges on database objects can be granted to or revoked from a user using the GRANT and REVOKE statements. Users that are granted a role with the ADMIN OPTION can in turn grant the role to other users and roles. The ADMIN OPTION should only be granted to user and group roles that are approved to grant the roles. A description of the available privileges that may be granted to the different types of Postgres database objects is documented at the following link:

https://www.postgresql.org/docs/current/ddl-priv.html

Also in Postgres, for most object types, object owners can perform any action on the objects they own, including dropping or altering them and assigning or revoking privileges on them. As such, database objects should only be owned by users who are approved to own them.

Another security risk to consider, is that Postgres can be extended with additional procedural languages that can be used to create user defined functions (i.e., not provided by EDB Postgres Advanced Server out-of-the-box). Some of these languages, such as pl/Python and pl/R are defined as 'untrusted' languages. Any users who are granted access to these untrusted languages are able to run user defined functions to escalate privileges and perform unintended functions. These languages allow a Postgres database to be extended with additional capabilities that may be of benefit to a system. However, usage of these languages should only be granted to approved users for documented and approved purposes.

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

Solution

Update system documentation to accurately identify all user and group roles that are authorized to perform privileged actions.

If the SUPERUSER, CREATEROLE, CREATEDB, REPLICATION, or BYPASSRLS privileges have been assigned to a user or group role that is not approved to have these privileges, remove the privilege using the ALTER ROLE SQL command as necessary.

The syntax is:
ALTER ROLE <role> NOSUPERUSER
ALTER ROLE <role> NOCREATEROLE
ALTER ROLE <role> NOCREATEDB
ALTER ROLE <role> NOREPLICATION
ALTER ROLE <role> NOBYPASSURLS

Examples:
ALTER ROLE testuser NOSUPERUSER
ALTER ROLE testuser NOCREATEROLE
ALTER ROLE testuser NOCREATEDB
ALTER ROLE testuser NOREPLICATION
ALTER ROLE testuser NOBYPASSURLS

If an unapproved user or group role is the owner of a database object, change the owner to an approved user or group role using one of the following ALTER SQL commands as appropriate:

The syntax is:
ALTER DATABASE <database name> OWNER TO <new_owner>
ALTER SCHEMA <schema name> OWNER TO <new_owner>
ALTER TABLE <table name> OWNER TO <new_owner>
ALTER SEQUENCE <sequence name> OWNER TO <new_owner>
ALTER VIEW <view name> OWNER TO <new_owner>
ALTER FUNCTION <function name> (<args>) OWNER TO <new_owner>
ALTER PROCEDURE <procedure name> (<args>) OWNER TO <new_owner>

Examples:
ALTER DATABASE test_db OWNER TO app_admin
ALTER SCHEMA test_schema OWNER TO app_admin
ALTER TABLE test_tbl OWNER TO app_admin
ALTER SEQUENCE test_seq OWNER TO app_admin
ALTER VIEW test_vw OWNER TO app_admin
ALTER FUNCTION test_func (p1 numeric, p2 text) OWNER TO app_admin
ALTER PROCEDURE test_proc (p1 numeric, p2 text) OWNER TO app_admin

If a user or group role has been granted an unapproved role or object privilege, execute the appropriate REVOKE command as documented here:

http://www.postgresql.org/docs/current/static/sql-revoke.html

Update the system documentation to identify the intended use, scope, and justification for any 'untrusted' procedural languages that are being used for user defined functions as well as the users who are approved to use these languages and corresponding functions.

If an unapproved user defined function exists, remove it from the database by executing the DROP FUNCTION SQL command as documented here:

https://www.postgresql.org/docs/current/sql-dropfunction.html

If an unapproved procedural language is installed, remove it from the database by executing the following SQL command:

DROP EXTENSION <extension_name>

Item Details

Audit Name: EDB PostgreSQL Advanced Server v11 DB Audit v2r2

Plugin: PostgreSQLDB

Control ID: a0d5cd96c050b4e675b6d7cd9780f058579904709ab03b41465f7eeb9ae9f1ec

Detections

Analytics

EP11-00-007400 - The EDB Postgres Advanced Server must prevent non-privileged users from executing privileged functions, to include disabling, circumventing, or altering implemented security safeguards/countermeasures.

Warning! Audit Deprecated

Information

Solution

See Also

Item Details