Skip to content
KitploitKITPLOIT
ToolsBlog
Log in
Einreichen
ToolsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

··Feeds·Kontakt·Datenschutz·© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
CVE-2022-1015-1016 — Spanische Übersetzung der CVE-2022-1015 und 1016, entdeckt und dokumentiert von David. | Kitploit
Tools/GitHubGitHub/zanezhub/cve-2022-1015-1016
Privilege EscalationSchwachstellenanalyseExploitationLernen & BildungBinary-Exploitation
GitHubzanezhub/cve-2022-1015-1016

CVE-2022-1015-1016

Spanische Übersetzung der CVE-2022-1015 und 1016, entdeckt und dokumentiert von David.

Repository anzeigen
16vor 4 JahrenNoch nicht geprüft

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Teilen
Webseite

CVE-2022-1015 & CVE-2022-1026

Diese README.md ist eine Übersetzung von Davids Blog. David fand die CVE-1015 und CVE-1016 im Linux-Kernel. Du kannst seine Webseite besuchen, um das Originaldokument zu lesen.

Hier sind seine Social-Media-Profile:

  • Twitter
  • Github

Eine Analyse der zwei neuen Linux-Sicherheitslücken in nf_tables

Veröffentlicht am 2. April 2022.

  • CVE-2022-1015 ermöglicht einen Out-of-Bounds-Zugriff (außerhalb der Grenzen), verursacht durch unzureichende Überprüfung der Eingabeargumente, was zu Remote-Code-Ausführung und lokaler Privilegienausweitung führen kann.
  • CVE-2022-1016 steht im Zusammenhang mit einer schlechten Initialisierung der auf dem Stack abgelegten Variablen, was dazu verwendet werden kann, eine große Vielfalt an Kernel-Daten in den Benutzerbereich (Userspace) zu leaken.

Diese Probleme sollten in den Standardkonfigurationen der neuesten Version von Ubuntu und von RHEL ausnutzbar sein. Ich schrieb meinen Proof-of-Concept (PoC) für CVE-2022-1015 mit Zielkernelversion 5.16-rc3 von Arch Linux.

Dieses Dokument richtet sich an Personen mit grundlegenden Kenntnissen des Linux-Kernels in Bezug auf Funktionalität und Sicherheit. Ich habe versucht, dieses Dokument für Personen ohne Kenntnisse des Netzwerk-Stacks zugänglich zu machen, um es für ein breites Publikum verständlich zu halten.

Hier ist eine Leseanleitung:

  • Wenn du einfach nur über die Schwachstelle lesen möchtest, beginne mit Abschnitt 4
  • Wenn du auch etwas Kontext zum Kernel-Subsystem möchtest, beginne mit Abschnitt 2
  • Wenn du an etwas zusätzlichem Kontext interessiert bist, lies das gesamte Dokument

1. Kontext

Mitte Februar kündigte das Google-Sicherheitsprogramm an, dass sie ihr kCTF-Belohnungsprogramm fortsetzen würden, mit Belohnungen von $31,337 bis $91,337 für einen Exploit im Linux-Kernel, der Privilegien auf den Root-Benutzer von nicht privilegierten Prozessen in einer nsjail-Sandbox eskaliert.

Als armer Student hat das natürlich meine Aufmerksamkeit erregt. Es war mein erstes Mal, dass ich nach einer „echten" Schwachstelle suchte, aber durch meine Abenteuer beim Spielen von CTF mit meinem Team bin ich mit dem Linux-Kernel in Bezug auf Sicherheit vertraut geworden.

Nach Stunden und Stunden mit kaum Fortschritt (aber mit mehr Wissen über Linux) gelang es mir, einige Schwachstellen im Modul nf_tables zu finden.

Leider stellte ich am Ende fest, dass dieses Modul in den Regeln des Google kCTF nicht vorhanden war (daher erhielt ich keine Belohnung für diese beiden Schwachstellen). Aber natürlich meldete ich sie trotzdem und schrieb einen LPE-Exploit (Local Privilege Escalation) für CVE-2022-1015.

1.1 Zielidentifikation und Audit-Strategie

Nun gut, du hast also beschlossen, einige Schwachstellen in Linux zu finden. Was nun? Linux ist ein riesiges Projekt, und es ist leicht, den Wald vor lauter Bäumen nicht zu sehen (du konzentrierst dich so sehr auf die Details, dass du den Überblick über das verlierst, was wirklich wichtig ist, du hast keinen Gesamtüberblick). Um die Sache noch schlimmer zu machen, sind viele Teile nicht dokumentiert und du musst eine Menge Code lesen, um zu verstehen, was vor sich geht.

Ich begann damit, eine detaillierte Perspektive auf das Linux-Sicherheitsmodell zu bekommen. Einen Bug zu finden ist eine Sache; aber einen guten Bug zu finden ist eine ganz andere. Schließlich sind nicht alle Bugs gleich geschaffen:

  • Wenn ein Bug root-Privilegien erfordert, gibt es keine signifikante Sicherheitsgrenze (es sei denn, das Kernel-Modul-Signing ist aktiviert)
    • Einige Dinge, die mir in den Sinn kommen, sind viele der (virtuellen) Dateisystemmodule. Nur der anfängliche root-Benutzer kann diese Dateisysteme mounten. Die Ausnahme liegt bei vfe, das FS_USERNS_MOUNT spezifiziert, in diesem Fall kannst du sie im user namespace mounten.
  • Wenn auf einen Bug nicht über Systemaufrufe zugegriffen werden kann, ist er wahrscheinlich nicht ausnutzbar.
    • Dies gilt für viele Hardware-Treiber, da du keinen physischen Zugriff auf die Maschine hast. Netzwerktreiber auf niedriger Ebene könnten dennoch ein gutes Ziel sein, wenn du z. B. Daten über Bluetooth oder 802.11.ac senden kannst.
    • Offensichtlich hängt dies vom Szenario ab, in dem du dich befindest.
  • Viele Bugs erfordern CAP_SYS_ADMIN oder CAP_NET_ADMIN.
    • Die user namespaces sind standardmäßig aktiviert, also ist das kein Problem.
    • Andernfalls musst du zuerst eine Privilegienausweitung zum namespace des root-Benutzers innerhalb eines Containers durchführen.
  • Nicht alle Module werden in deinem Ziel vorhanden sein.
    • Linux ist ein außergewöhnlich hoch konfigurierbares Stück Software, daher können alle Konfigurationen auf vielfältige Weise variieren.
    • Die Kernelkonfiguration kann normalerweise über /proc/config.gz abgerufen werden. Module können als (=m) geladen oder separat kompiliert und zur Laufzeit geladen werden (=y).
    • Du kannst /proc/modules und /proc/kallsyms verwenden, aber sie sind nicht immer zuverlässig, da Module dynamisch in den Kernel geladen werden können (z. B. request_module).
    • Wenn du dir nicht sicher bist, schreibe ein kleines Programm, das versucht, mit dem Modul zu interagieren.

Diese Einschränkungen helfen uns, die Grenzen der Dateisysteme zu verstehen, in denen wir nach Schwachstellen suchen können. Ich denke, es ist eine gute Idee, sich Zeit zu nehmen, um deinen Angriff auf das gewünschte Ziel zu planen.

Ich habe meine Lektion aus dem obigen Punkt gelernt. Wie erwähnt, war das Modul nf_tables in der von kCTF präsentierten Instanz nicht geladen. Ich hätte das von Anfang an bemerken und mir die Enttäuschung ersparen können :p. Andererseits würdest du diesen Blog jetzt wahrscheinlich nicht lesen, wenn ich es bemerkt hätte, ich schätze, die Dinge sind am Ende doch gut gelaufen.

Eine Erklärung, warum COS, Googles container-optimierter Linux-Fork, kein nf_tables hatte, findet sich hier und hier.

1.2 nf_tables: warum?

Nachdem ich die oben genannten Punkte bewertet hatte, entschied ich, dass mein bester Weg zum Start wahrscheinlich wäre, mir den Quellcode des Netzwerks anzusehen. Viele der interessanten Funktionen dort erfordern CAP_NET_ADMIN, aber wie erwähnt, ist das eigentlich kein Problem. Im Gegenteil, ich vermute, dass Komponenten, die spezielle Fähigkeiten erfordern, im Allgemeinen weniger sicher sind, da die Kernel-Entwickler möglicherweise ein falsches Sicherheitsgefühl haben.

Ich habe mich auch bemüht, das Dateisystem auszuwählen, über das ich mehr erfahren wollte; auf diese Weise, selbst wenn du keinen Fehler findest, wirst du trotzdem eine Menge interessanter Dinge lernen.

Tool herunterladen