Skip to content
KitploitKITPLOIT
ToolsBlog
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
Tools/GitHubGitHub/rarar0/kde_vuln
SchwachstellenanalyseExploitationPapers & ForschungLernen & BildungBinary-Exploitation
GitHubrarar0/kde_vuln

KDE_Vuln

# CVE-2018-6791 Fehlerbehebung

Repository anzeigen
1vor 8 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

Gedanken zur KDE-vFAT-Sicherheitslücke.

#1: Der Umfang ist nicht so groß, wie ich zunächst angenommen habe.

Die meisten Systeme sind vermutlich auf neuere Versionen von KDE aktualisiert oder verwenden eine andere GUI. Ich müsste mir jedoch einige tatsächliche Statistiken ansehen, um eine genaue Zahl zu erhalten. Physischen Zugriff auf einen Rechner zu bekommen, ist bereits eine Aufgabe für sich. Wenn der Exploit dann einfach nicht funktioniert, weil das Zielsystem eine andere GUI ausführt als erwartet, scheint das lästig zu sein.

#2: Das 11-Zeichen-Limit bei der vFAT-Bezeichnung ist frustrierend.

Nach einem kurzen Blick durch Twitter, Reddit und andere Foren konnte ich keinen Weg finden, dies zu umgehen. Meine aktuelle Hypothese zur Umgehung wäre, mit fdisk die Bezeichnung als einen anderen Typ zu bearbeiten, während das Dateisystem vFAT bleibt. Eine andere Option wäre, stattdessen NTFS zu verwenden. Ich habe eine Quelle gefunden, die besagte, dass NTFS möglicherweise die ursprüngliche Ursache dieser Sicherheitslücke war. (In diesem Fall ist die Bezeichnungsgröße viel größer.)

Tool herunterladen