Zum Inhalt springen
BlogSicherheitLinode Security Digest Oktober 30 - November 6, 2022

Linode Security Digest Oktober 30 - November 6, 2022

Linode Security Digest

In der Zusammenfassung dieser Woche werden wir diskutieren:

  • ein Sicherheitshinweis zu OpenSSL Version 3.0.0;
  • eine Sqlite-Array-Überlaufschwachstelle; und
  • einen GitHub-Repojacking-Angriff.

Openssl-Sicherheitshinweis

OpenSSL 3.0.0 hat kürzlich zwei Sicherheitslücken geschlossen: CVE-2022-3602 und CVE-2022-3786. 

CVE-2022-3602, eingestuft als kritisch (9.8/10), beinhaltet einen 4-Byte-Stapelpufferüberlauf, der zu DoS oder Code-Ausführung führen kann. Für eine erfolgreiche Ausnutzung muss das Ziel eine X509-Zertifikatsvalidierung eines bösartigen Zertifikats durchführen, insbesondere die Überprüfung von Namensbeschränkungen. Ein Angreifer kann eine bösartige E-Mail-Adresse erstellen, um vier vom Angreifer kontrollierte Bytes auf dem Stack zum Überlauf zu bringen. Der Angriff könnte jedoch durch Stack Overflow-Schutzmechanismen vereitelt werden, die normalerweise in modernen Betriebssystemen aktiviert sind. Die Schwachstelle wurde von OpenSSL zunächst als kritisch eingestuft, nach weiteren Analysen wurde der Schweregrad jedoch auf hoch herabgestuft. Zum Zeitpunkt der Erstellung dieses Artikels liegt der Base Score bei 9.8 (kritisch).  

CVE-2022-3786, hoch bewertet (7,5/10), ist ein weiterer Pufferüberlauf, der durch ein bösartiges tls-Zertifikat ausgelöst wird. Ähnlich wie bei der vorgenannten Sicherheitslücke muss ein Angreifer ein Zertifikat mit einer bösartigen E-Mail-Adresse erstellen. Der Unterschied liegt in den Zeichen, die zum Auslösen eines Überlaufs verwendet werden können, der auf das Zeichen `.' (Dezimalzahl 46) beschränkt ist, was zu einem Dienstabsturz oder Denial of Service führt. 

Benutzer, die OpenSSL 3.0 verwenden, sollten so bald wie möglich auf die neueste Version aktualisieren. Dieser Blog-Beitrag könnte Benutzern dabei helfen, festzustellen, ob sie die anfällige Version der Bibliothek in ihrer Umgebung verwenden.  

Sqlite Array-bounds Überlaufschwachstelle

TrailofBits hat eine hochgefährliche Sicherheitslücke in der beliebten DBMS-Bibliothek Sqlite aufgedeckt, die kürzlich gepatcht wurde. Die dieser Sicherheitslücke zugeordnete CVE lautet CVE-2022-35737 und wird mit 7,5/10 bewertet.  

Die Schwachstelle ist ein Array-Überlauf in SQLite 1.0.12 bis 3.39.x vor 3.39.2 und betrifft Anwendungen, die die API der SQLite-Bibliothek verwenden. Die Ausnutzbarkeit hängt davon ab, wie SQLite kompiliert wird; wenn das Programm ohne aktivierte Stack Canaries kompiliert wird, ist eine Codeausführung möglich. Die Sicherheitslücke wurde in v1.0.12, veröffentlicht am 17. Oktober 2000, eingeführt. 

In der Quelle heißt es: "Auf anfälligen Systemen kann CVE-2022-35737 ausgenutzt werden, wenn große String-Eingaben an die SQLite-Implementierungen der printf-Funktionen übergeben werden und wenn der Format-String die Formatsubstitutionstypen %Q, %q oder %w enthält." Dies verringert die Angriffsfläche und die Wahrscheinlichkeit, dass eine Anwendung tatsächlich durch diese Schwachstelle ausgenutzt werden kann, obwohl es den Benutzern immer noch dringend empfohlen wird, das Risiko im Kontext ihrer Verwendung der Komponente zu bewerten.   

Die gepatchte SQLite-Version v3.39.2 steht den Anwendern für ein Upgrade ihrer Anwendungen zur Verfügung. Benutzer, die auf Tools angewiesen sind, die die anfällige SQLite-Bibliothek verwenden, müssen auf die Freigabe des Patches durch die Verantwortlichen für den Code warten. Trailofbits hat auch das Exploit-POC veröffentlicht, das auf GitHub zu finden ist.  

Github Repojacking

Checkmarx hat eine weitere Methode zum Angriff auf die Lieferkette aufgedeckt, die auf Code-Repositories auf github.com abzielt. Der Angriff wird als "Repojacking" bezeichnet und beinhaltet die Übernahme eines Repositorys durch die Umgehung einer bereits bestehenden Sicherheitskontrolle, die von Microsoft für diese Art von Angriff eingerichtet wurde. Diese Kontrolle wird als "popular-repository-namespace-retirement" bezeichnet und verbietet es GitHub-Nutzern, Repositories mit einem Namen zu erstellen, der mit dem Namen übereinstimmt, der zuvor von einem deaktivierten Nutzer mit demselben Benutzernamen verwendet wurde, wenn das Repository innerhalb einer Woche vor der Änderung des Benutzernamens mehr als 100 Klone hatte. Sie wurde von GitHub als Entschärfung implementiert, nachdem checkmarx im Jahr 2021 eine ähnliche Sicherheitslücke aufgedeckt hatte. 

Der neue Angriff umgeht die Abschwächung, indem er eine Github-Funktion namens Repository Transfer ausnutzt. Hier sehen Sie, wie der Angriff durchgeführt wird:

  1. "victim/repo" ist ein beliebtes GitHub-Repository, das unter dem Schutz des Namensraums für beliebte Repositorys in den Ruhestand versetzt wurde.
  2. "helper_account" erstellt das "repo"-Repository
  3. "helper_account" überträgt das Eigentum am "repo"-Repository an "attacker_account"
  4. "Angreifer_Konto" benennt seinen Benutzernamen in "Opfer" um
  5. Das neue "Opfer"-Konto (zuvor "Angreifer_Konto") akzeptiert die Eigentumsübertragung und übernimmt im Wesentlichen das Ziel-Repository

Der Fix für diese Schwachstelle wurde bereits eingespielt. Checkmarx hat auch ein Tool veröffentlicht, um zu prüfen, welche direkten Golang-Abhängigkeiten für diese Art von Angriff anfällig sein könnten. 


Kommentare

Kommentar abgeben

Ihre E-Mail Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit *gekennzeichnet