...
A method declared as synchronized always uses the object's monitor (intrinsic lock) as does code that synchronizes on the this reference using a synchronized block. There are some basic issues with this approach such as Poorly synchronized code is prone to contention and deadlock which may occur in the code even without an attacker. However, an . An attacker can manipulate the system to trigger these conditions and cause a Denial of Service (DoS). An inappropriate synchronization policy can create a Denial of Service (DoS) vulnerability because If the vulnerable class is accessible from an untrusted class whose member locks on the same object, can fail to release the lock promptly. However, this requires the victim class to be accessible from the offending (untrustworthy) class, an attacker can lock and hold the same object as the vulnerable class, disrupting correct synchronization.
| Wiki Markup |
|---|
The _private lock object_ idiom prevents this vulnerability. The idiom consists of a {{java.lang.Object}} declared within the class as {{private}} and {{final}}. The object must be explicitly used for locking purposes in {{synchronized}} blocks, within the class's methods. This intrinsic lock is associated with the instance of the internal private object and not with the class itself. Consequently, there is no lock contention between this class's methods and methods of a hostile class \[[Bloch 01|AA. Java References#Bloch 01]\]. |
...