Database Reference
In-Depth Information
SYSDBA privilege from a SYS user. For instance, there are methods by which a namespace may be overriden using
CREATE PUBLIC SYNONYM to trick a SYSDBA user into running a low-privilege user's code or into creating users
with object names by namespace overriding.
■
You can read details on the attack i've just described in my paper at
http://www.oracleforensics.com/
Note
We will talk more in depth about phishing attacks in the next chapter. For now, just know that the basic phishing
design flaw is still present by default in 12c. If a user wishes to remove the risk, it means revoking INHERIT object
privileges from the object owner. INHERIT object privileges are a new addition in 12c and are the source of many new
PUBLIC privileges, as a new INHERIT PUBLIC privilege is created every time an object is created. What is of concern
is that the INHERIT privilege will cause the number of PUBLIC privileges in the database to fluctuate from day to day,
which makes state checking more difficult. Controlling that complexity will be addressed in Chapter 11.
Database Link Issues
Database link (DBLink) permissions represent a similar design issue to the public permissions problem just
described. Essentially, we can simplify DBLink permissions conceptually as being either PUBLIC, i.e., any DB user can
use them, or private, i.e., only the DBLink owner can use them. This distinction is a bit binary and does lead to issues,
especially as DBLinks are quite complex to understand from the documentation alone.
Following are the three main issues, which still apply to database links in 12c:
•
Database links are public or private. There is no finer grain of control than that.
•
Incoming DBLink connections cannot be prevented from entering the target database.
•
Database link-stored passwords still suffer from decryption in 12c, as I will show in Chapter 10.
Database links should still be considered as a design issue. However, it is possible to secure them. Linking
databases together is critical to an organization, so we have to achieve that type of integration safely. Chapters 10 and 11
will therefore look at securing DBLinks in more detail.
Passwords
The main unsolved design issues concerning passwords in Oracle database are:
1.
No enforced uniqueness -
i.e., every password in the database could be identical. There is
no control for uniqueness. Therefore a decrypted DBLink could give the SYS password.
2.
Non-interactive encrypted passwords can be decrypted -
i.e., any password not entered
by a human has to be stored somewhere, as does its encryption key, e.g., dataguard
logon from DB, cloud control, and DBSNMP/SYSMAN passwords for grid automation.
These passwords need to be decrypted by the system and therefore a privileged user can
probably decrypt them too. With an increase in automation comes an increased risk of
stored passwords being decrypted. There are some risk reduction strategies to this, as we
shall see in Part IV.
