• CWE-609: Double-Checked Locking

Das Produkt verwendet double-checked locking, um auf eine Ressource zuzugreifen, ohne den Overhead einer expliziten Synchronisation. Allerdings ist die Sperrmechanismus unzureichend.

CWE-Referenz › CWE-609: Double-Checked Locking

CWE-609: Double-Checked Locking

CWE ID: 609
Name: Double-Checked Locking

Beschreibung

Das Produkt verwendet double-checked locking, um auf eine Ressource zuzugreifen, ohne den Overhead einer expliziten Synchronisation. Allerdings ist die Sperrmechanismus unzureichend.

Erweiterte Beschreibung

Double-checked locking beschreibt eine Situation, in der ein Programmierer prüft, ob eine Ressource initialisiert wurde, eine Sperre erlangt, erneut prüft, ob die Ressource initialisiert wurde, und dann die Initialisierung durchführt, falls diese noch nicht stattgefunden hat. Dies sollte vermieden werden, da es in allen Programmiersprachen und auf allen Architekturen nicht garantiert funktioniert. Zusammenfassend lässt sich sagen, dass andere Threads möglicherweise nicht innerhalb des synchronisierten Blocks operieren und nicht garantiert sehen, dass die Operationen in der gleichen Reihenfolge ausgeführt werden, wie sie innerhalb des synchronisierten Blocks erscheinen würden.

Risikominderungsmaßnahmen

Maßnahme (Implementation)

Effektivität: Unknown
Beschreibung: Obwohl double-checked locking in einigen Programmiersprachen realisiert werden kann, ist es in Java vor Version 1.5 inhärent fehlerhaft und kann ohne Kompromisse bei der Plattformunabhängigkeit nicht erreicht werden. Vor Java 1.5 ist lediglich die Verwendung des Schlüsselworts synchronized als funktionierende Lösung bekannt. Ab Java 1.5 ermöglicht die Verwendung des Schlüsselworts volatile, dass double-checked locking erfolgreich funktioniert, wenngleich es eine Debatte darüber gibt, ob dadurch ausreichende Performance-Gewinne erzielt werden. Weitere Informationen finden Sie in den Referenzen.

Ist Ihre IT-Infrastruktur betroffen?

Schwachstellen wie CWE-609: Double-Checked Locking werden von Angreifern gezielt gesucht — meist automatisiert und ohne Rücksicht darauf, wie groß das betroffene Unternehmen ist. Ob eine solche Lücke bei Ihnen tatsächlich offen steht, lässt sich nur durch Prüfung feststellen:

  • Schwachstellen-Scan — wiederkehrende Prüfung Ihrer Infrastruktur auf bekannte Lücken wie diese
  • Penetrationstest — manuelle Prüfung eigener Software auf Schwachstellen, die kein Werkzeug findet
  • Threat Modeling — Schwachstellenklassen im Entwurf vermeiden, statt sie später zu suchen
Kostenloses Erstgespräch Für mittelständische Unternehmen