Tag Archives: CVE-2009-0935

CWE-667 – Improper Locking

Read Time:2 Minute, 23 Second

Description

The software does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-662
CWE-662
CWE-662
CWE-662

 

Consequences

Availability: DoS: Resource Consumption (CPU)

Inconsistent locking discipline can lead to deadlock.

 

Potential Mitigations

Phase: Implementation

Description: 

Use industry standard APIs to implement locking mechanism.

CVE References

  • CVE-2009-0935
    • Attacker provides invalid address to a memory-reading function, causing a mutex to be unlocked twice
  • CVE-2010-4210
    • function in OS kernel unlocks a mutex that was not previously locked, causing a panic or overwrite of arbitrary memory.
  • CVE-2008-4302
    • Chain: OS kernel does not properly handle a failure of a function call (CWE-755), leading to an unlock of a resource that was not locked (CWE-832), with resultant crash.
  • CVE-2009-1243
    • OS kernel performs an unlock in some incorrect circumstances, leading to panic.
  • CVE-2009-4272
    • deadlock triggered by packets that force collisions in a routing table
  • CVE-2002-1850
    • read/write deadlock between web server and script
  • CVE-2004-0174
    • web server deadlock involving multiple listening connections
  • CVE-2009-1388
    • multiple simultaneous calls to the same function trigger deadlock.
  • CVE-2006-5158
    • chain: other weakness leads to NULL pointer dereference (CWE-476) or deadlock (CWE-833).
  • CVE-2006-4342
    • deadlock when an operation is performed on a resource while it is being removed.
  • CVE-2006-2374
    • Deadlock in device driver triggered by using file handle of a related device.
  • CVE-2006-2275
    • Deadlock when large number of small messages cannot be processed quickly enough.
  • CVE-2005-3847
    • OS kernel has deadlock triggered by a signal during a core dump.
  • CVE-2005-2456
    • Chain: array index error (CWE-129) leads to deadlock (CWE-833)
  • CVE-2001-0682
    • Program can not execute when attacker obtains a mutex.
  • CVE-2002-1914
    • Program can not execute when attacker obtains a lock on a critical output file.
  • CVE-2002-1915
    • Program can not execute when attacker obtains a lock on a critical output file.
  • CVE-2002-0051
    • Critical file can be opened with exclusive read access by user, preventing application of security policy. Possibly related to improper permissions, large-window race condition.
  • CVE-2000-0338
    • Chain: predictable file names used for locking, allowing attacker to create the lock beforehand. Resultant from permissions and randomness.
  • CVE-2000-1198
    • Chain: Lock files with predictable names. Resultant from randomness.
  • CVE-2002-1869
    • Product does not check if it can write to a log file, allowing attackers to avoid logging by accessing the file using an exclusive lock. Overlaps unchecked error condition. This is not quite CWE-412, but close.

CWE-765 – Multiple Unlocks of a Critical Resource

Read Time:1 Minute, 5 Second

Description

The software unlocks a critical resource more times than intended, leading to an unexpected state in the system.

When software is operating in a concurrent environment and repeatedly unlocks a critical resource, the consequences will vary based on the type of lock, the lock’s implementation, and the resource being protected. In some situations such as with semaphores, the resources are pooled and extra calls to unlock will increase the count for the number of available resources, likely resulting in a crash or unpredictable behavior when the system nears capacity.

Modes of Introduction:

– Implementation

Likelihood of Exploit:

 

Related Weaknesses

CWE-667
CWE-675

 

Consequences

Availability, Integrity: DoS: Crash, Exit, or Restart, Modify Memory, Unexpected State

 

Potential Mitigations

Phase: Implementation

Effectiveness:

Description: 

When locking and unlocking a resource, try to be sure that all control paths through the code in which the resource is locked one or more times correspond to exactly as many unlocks. If the software acquires a lock and then determines it is not able to perform its intended behavior, be sure to release the lock(s) before waiting for conditions to improve. Reacquire the lock(s) before trying again.

CVE References

 

  • CVE-2009-0935
    • Attacker provides invalid address to a memory-reading function, causing a mutex to be unlocked twice