In my last blog post “CREATE ANY DIRECTORY”=DBA=SYSDBA ! Ouch ! i talked about the potential threat that can represent the PREPROCESSOR feature introduced in oracle 11gr2 in a consolidated environment and how to develop a systemtap live patch to help preventing that.As Frank Pachot also stated a new parameter “PDB_OS_CREDENTIAL” was introduced in oracle 184.108.40.206 which is meant to prevent that in CDB databases:
As Kamil Stawiarski explained in some great articles :
“A lot companies consolidates databases into one appliance – like for example Oracle Exadata. So you can have a lot of different databases in one physical cluster. And what if I tell you that you can execute any OS command as an oracle user, having just access to a database user with appropriate privileges? What if I tell you that DBA=SYSDBA? And not just SYSDBA for one database but for every database in a cluster?” Ref1
This is possible using only three elements thanks to the PREPROCESSOR feature introduced in oracle 11G Ref2 :
There are many useful systemtap scripts out there that can be used for troubleshooting performance problem or any other tasks. In some case it could be handy to extend them with session information to have a better picture of what’s going on.Based on my previous work on Dynamic tracing tools : Easier access to session/process address [ksupga_] here is some examples :
Here is a vulnerability i recently discovered inside the CDBView package (Create the cdb view) on my Database Patch Set Update : 220.127.116.11.161018 (24006101) .The package is granted to the “EXECUTE_CATALOG_ROLE” Role by default.
The package is not even wrapped, but this is not a problem as we can easily unwrap it anyway :
This is my third blog post about DB Link encryption/decryption.In the first one i demonstrated how we can find the database link password in clear text using GDB and Intel pin tools.In the second one i have given more information about how it was encrypted/decrypted (AES in CBC encryption mode).It’s now time to reverse engineer it !
In one of my previous posts i showed a way to recover the DB Link password in case we forgot it but i haven’t given any information on how it was encrypted/decrypted.So here is some info that may be helpful for future work such as writing a bunch of PL/SQL code to decrypt the password without the need for other tools (as in previous release ) .
I just published a blog post on how to get the oracle database link password if for some reason we have forgotten it.Brian Fitzgerald respond to me with :
@Hatem__Mahmoud if you can trace listener across fork, you can get anyone’s password
— Brian Fitzgerald (@ExaGridDba) November 16, 2016
Indeed this is a very good point ! And here is how we can do that using GDB :