Database Reference
In-Depth Information
Product (Component)
Oracle Server (Rdbms)
Range of versions believed to be affected
Versions >= 11.1
Versions confirmed as being affected
11.1.0.7
Platforms affected
Generic (all / most platforms affected)
Fixed:
This issue is fixed in
11.2.0.1 (Base Release)
Symptoms:
Performance Affected (General)
Waits for “row cache lock”
Related To:
Security (Authentication / Privileges / Auditing)
Description
In 11g there is an intentional delay between allowing failed logon attempts to retry. For some
specific application types this can cause a problem as the row cache entry is locked for the
duration of the delay. This can lead to excessive row cache lock waits for DC_USERS for specific
users / schemas . This "fix" allows the logon delay to be disabled in 11.2.0.1 onwards by setting
event 28401 in the init.ora. eg:event="28401 trace name context forever, level 1" # disable logon
delay. This "event" will disable the logon sleep delay system-wide, i.e., it will affect all user
accounts, system wide, and so should be used with extreme caution.
Example scenario: A mix of correct and incorrect logon attempts occur for user X. On each successive
failed login attempt the failed logon count is incremented for user X.
Without this fix (without the event set):
After 3 successive failures a sleep delay is introduced
starting at 3 seconds and extending to 10 seconds max. During each delay the user X row cache lock
is held in exclusive mode preventing any concurrent logon attempt as user X (and preventing any
other operation which would need the row cache lock for user X).
With the fix (with the event set):
There is no sleep delay. In either scenario the configured logon
profile rules are still applied (e.g., The profile option FAILED_LOGIN_ATTEMPTS is still honored and
so if the account becomes locked due to exceeeding this FAILED_LOGIN_ATTEMPTS then further attempts
to log in will then correctly fail immediately with no delay).
Note:
One-off fixes for this issue for 11.1.0.7 do not need an event set—interim patches for 11.1
disable the delay unconditionally.
Work Around:
Ensure the correct password is used—especially for connection-intensive logons.
Thus the above issue is fixed in 11.2, but if your repository is still on 11.1 how do you protect from brute-forcing of
SYS? What is needed is a delay that is only introduced when a brute-force is actually happening. We only want to use it
if it is needed, similar to the native IPS idea with DBLinks.
Adaptive Delay Triggered by Failed Logins
Let's see how to implement failed login delay in 11.1 that only triggers when a SYS brute-force is actually happening.
We can do this within EM12c using “corrective actions.” This will enable an adaptive response. In addition, we can
use multi-part jobs to push that adaptive response out to the whole estate so that an attack on one DB could raise the
security posture of the whole estate by increasing the failed login delay on SYS as follows.
