Oracle listener static service hi-jacking

We must be careful about the services that are registered to a listener because the user connects to them with a good idea of the database she wants to connect to, but another database or PDB can dynamically register a service with the same name, and then get the connections which were expected another destination. Of course, as a security best practice, user/password should not be the same in different databases, but what if the connection is done by a common user in multitenant? By creating a service, you can hi-jack the connections to CDB$ROOT and have them connected to your PDB.

You may think that static registration (the SID_LIST_LISTENER in listener.ora) is a solution, especially with the (STATIC_LISTENER=TRUE) introduced in 12cR2, but this defines only the target instance. The PDB is resolved dynamically.

This post is there only to raise awareness. I’ll not expose the possible exploits. But you can imagine: something that is scheduled to run as SYSDBA on CDB$ROOT can be high-jacked to be run on a PDB where you have more privileges to attempt some privilege escalation.

Here is my CDB1 database with PDB1 pluggable database. In addition to the default services, I’ve defined a static service CDB1_DGMGRL.

# lsnrctl status

LSNRCTL for Linux: Version 19.0.0.0.0 - Development on 05-JAN-2019 18:06:26

The registration is not a problem, as it goes to the same instance. The problem is that the instance knows that service as belonging to PDB1. Then, when a common user connects with this service his session switches to the PDB1 container:

Solution(s)

Basics: be careful with powerful privileges, such as INHERIT PRIVILEGES, which can allow a PDB DBA to overwrite a common user procedure with authid current_user.

Safe attitude: when you expect your connection to run in CDB$ROOT be sure to do it explicitely with ALTER SESSION SET CONTAINER=CDB$ROOT

Isolation: dedicate a listener for your system administration. Another listener will be the target of REMOTE_LISTENER for dynamic registration.

Least privileges: when you need only to access to CDB$ROOT connect with a user that has no CONNECT privilege on the PDBs.

DBaaS: if you are using multitenant for database on-demand provisioning where the user can choose the name of the PDB then be sure that the name cannot be the same as a static service you use. Naming conventions may help there.