Das Jahr 2024 geht zu Ende und ich möchte die Gelegenheit nutzen, mich herzlich bei allen Lesern zu bedanken, die in diesem Jahr meinen Blog verfolgt, meine Artikel gelesen oder ihn durch Kommentare und Zuschriften bereichert haben.

Zu Beginn des Jahres bin ich zum Institut für sichere mobile Kommunikation (ISMK) gewechselt und habe den Podcast Risikozone mitgenommen, sodass ich die Episoden nun im Rahmen meiner Tätigkeit dort produziere. Viele IT-Sicherheitsthemen, die ich im Blog veröffentlicht hätte, fließen nun zwei Mal im Monat in die Episoden dort ein. Über das vergangene Jahr des Podcasts haben wir in Episode 63 gesprochen.

Mein Blog begleitet mich nun schon seit 2016. Im neunten Jahr seines Bestehens habe ich mit 14 Artikeln den Schnitt der vergangenen Jahre gehalten. Wie gewohnt möchte ich zum Jahresende auf einige Highlights und bedeutende Themen des vergangenen Jahres im Blog zurückblicken.

Rückblick auf 2024

Eines der herausragendsten Ereignisse in der IT-Sicherheits- und Open-Source-Welt war zweifellos die xz-Lücke. Über diese Backdoor habe ich sowohl hier im Blog als auch in den Risikozone-Episoden 45 und 46 berichtet.

Ein weiteres bemerkenswertes Sicherheitsproblem war die OpenSSH-Sicherheitslücke RegreSSHion. Zudem wurden in der glibc zwei Lücken entdeckt, deren besondere Bedeutung in ihrem Alter lag: Die verwundbaren Versionen wurden seit 1992 ausgeliefert.

Beim Durchsehen des Blogarchivs fiel mir zudem auf, dass die Veröffentlichung von KDE Plasma 6 ebenfalls in dieses Jahr fiel. Die neue Version der Desktopumgebung, die erstmals nun auf Qt 6 aufbaut, fühlt sich schon so vertraut an, dass es schwer zu glauben ist, dass sie erst 2024 erschienen ist.

Pläne für 2025

Das Thema Künstliche Intelligenz, insbesondere im Bereich der Large Language Models (LLMs), hat sich 2024 stabilisiert. Nach dem anfänglichen Hype zeichnet sich nun eine Phase der Konsolidierung ab. Für das kommende Jahr plane ich, die LLM Timeline wieder zu aktualisieren, um die Entwicklungen der letzten Monate zu dokumentieren.

Auch technisch wird sich auf dem Blog einiges tun. Ich arbeite an einer Erweiterung der Blogsoftware, um die Unterstützung für mehrere Sprachen zu verbessern und das Design speziell für Infografiken zu optimieren.

Guten Rutsch

Ich wünsche euch allen einen guten Rutsch in das Jahr 2025 und freue mich darauf, euch auch im neuen Jahr mit spannenden Artikeln, Podcast-Episoden und technischen Updates begleiten zu dürfen! Danke für eure Unterstützung und euer Interesse!

Der Fakespot Deep Fake Detector ist eine neue Firefox-Erweiterung von Mozilla, welche es dem Nutzer ermöglichen soll, mutmaßliche KI-Inhalte von Inhalten zu unterscheiden, die von echten Menschen geschaffen wurden.

Download Fakespot Deep Fake Detector

Künstliche Intelligenz (KI) erlebt in den letzten Jahren einen extremen Aufschwung – sowohl qualitativ als auch, was die Nutzung betrifft – und das längst auch im Mainstream-Bereich. Heute fällt es teilweise schwer, überhaupt noch zu erkennen, welche Inhalte von einer KI erzeugt worden sind und was das Werk echter Menschen ist.

Mozilla möchte dieses Problem angehen – und zwar mit Hilfe Künstlicher Intelligenz. Der Fakespot Deep Fake Detector ist eine neue Browser-Erweiterung für Firefox, welche es erlaubt, markierten Text dahingehend zu analysieren. Alternativ kann Text auch ohne Browser-Erweiterung auf der dazugehörigen Website eingegeben werden.

Zu diesem Zeitpunkt werden ausschließlich englischsprachige Texte unterstützt. Bei Text soll es dabei nicht bleiben: In Zukunft soll der Fakespot Deep Fake Detector auch Videos und Bilder analysieren können.

Für eine bessere Zuverlässigkeit verlässt sich Mozilla nicht auf ein einzelnes Modell. Mit ApolloDFT, Binocular, UAR sowie ZipPy kommen derzeit gleich vier Modelle mit unterschiedlichen Stärken und Schwächen zum Einsatz, die auch beschrieben werden. Wenn es Unstimmigkeiten in der Bewertung gibt, erfährt der Nutzer, welches Modell zu welchem Ergebnis kam. Bei allen diesen Modellen handelt es sich um Open Source-Modelle, wobei ApolloDFT ein eigenes Modell von Fakespot ist.

Fakespot war ursprünglich ein eigenständiges KI-Unternehmen, welches sich auf die Erkennung sogenannter „Fake-Inhalte“ spezialisiert hat und im Mai 2023 von Mozilla übernommen worden ist. Am besten bekannt ist Fakespot für die Erkennung falscher Produktbewertungen beim Online-Shopping. Mittlerweile ist diese Funktionalität für Amazon, BestBuy und Walmart nativ in Firefox integriert.

Der Beitrag Fakespot Deep Fake Detector: Neue Erweiterung von Mozilla erkennt Inhalte von KI vs. echten Menschen erschien zuerst auf soeren-hentzschel.at.

In der letzten Episode des Risikozone-Podcasts habe ich ganz kurz das Thema der verkürzten Hashwerte und auftretenden Kollisionen angesprochen. Jetzt gibt es ein Proof of Concept zu der Thematik.

Worum es geht

Ein kurzer Refresher, worum es in der Thematik überhaupt geht: Als Git entwickelt wurde, musste ein Weg gefunden werden, wie man die Referenzen auf Commits, die Dateien und die Dateibäume realisiert. In vielen Systemen wie z. B. Issue-Trackern werden aufsteigende Indizes verwendet. In einem verteilten System wie Git ist das aus verschiedenen Gründen der Synchronisation nicht so einfach möglich, da sonst Kollisionen, also gleiche IDs für unterschiedliche Objekte entstehen könnten. Eine Alternative wäre UUIDs, da die IDs einen randomisierten Anteil haben und die Wahrscheinlichkeit für Kollisionen gesenkt wird.

Noch besser als UUIDs ist allerdings Content-adressable Storage, bei dem Inhalte einzig durch ihren Inhalt adressiert werden. Das ist so, als würde man den gesamten Inhalt der Datei nochmal in den Dateinamen schreiben. Der Clou dabei ist jedoch, dass der gesamten Dateiinhalt gar nicht in den Dateinamen geschrieben werden muss, um die Datei durch ihren Inhalt identifizierbar zu machen.

Mit kryptographischen Hashfunktionen wie SHA-1 oder SHA-256 existiert ein Mittel, um einen beliebig langen Dateiinhalt zu einem immer gleich langen Wert, dem Hash, umzuwandeln. Dabei sind kryptographische Hashfunktionen so konstruiert, dass die Wahrscheinlichkeit für Kollisionen durch verschiedene Mechanismen stark minimiert wird. Ein SHA-1-Hash für den Dateiinhalt "Hallo Welt" wäre z. B. 28cbbc72d6a52617a7abbfff6756d04bbad0106a. Ein netter Nebeneffekt ist, dass Dateien mit gleichem Inhalt im Content-adressable Storage auch nur einmal abgespeichert werden, wodurch sogar Deduplikation ermöglicht wird.

Git nutzt dieses Verfahren, um die eingechekten Dateien abzuspeichern. Diese Dateien werden dann in Trees zusammengebunden und in Commits mit den jeweiligen Vorgänger-Commits (parents) in einem sog. Merkle-Tree verheiratet.

Commits werden somit auch durch einen SHA-1-Hash identifiziert, der im hexadezimalen Format 40 Zeichen lang ist.

Das Problem

Das Problem bei dem Verfahren liegt jetzt darin, dass dieser Hash üblicherweise noch weiter abgekürzt wird, um ihn benutzerfreundlicher in Oberflächen oder E-Mails darzustellen. Damit wird natürlich die Wahrscheinlichkeit für Kollisionen erhöht.

Habe ich einen Hash 28cbbc72d6a52617a7abbfff6756d04bbad0106a und nutze nur 28cbbc zur Referenz, reicht das in den meisten kleinen Repositories aus, um einen Commit eindeutig zu referenzieren. In großen Repositories mit vielen Dateien und Commits kann es auf einmal passieren, dass ein weiterer Commit 28cbbcc00aa8ef4e80596c16ecfdb4bc92656cd3 auftaucht, sodass 28cbbc nicht mehr eindeutig einen Commit beschreibt.

Um das Risiko zu verringern, sollte die Mindestanzahl der Zeichen für einen abgekürzten Commit erhöht werden.

Das Kernel-Repository

Genau darum geht es in der aktuellen Diskussion. Aktuell nutzen die Linux-Entwickler zur Referenz von Commits in ihren E-Mails 12 Zeichen lange Hashes. Die Diskussion dreht sich um die Frage, ob die Zahl weiter erhöht werden sollte. Linus Torvalds ist bisher dagegen, weil er das Risiko für Kollisionen gering sieht und er die Position vertritt, dass ein Commit immer mit dem Commit Message Title angegeben werden sollte, was ungewollte Kollisionen ausreichend verhindere.

Gestern veröffentlichte Kees Cook einen Blogpost, indem er eine Commit-Kollision mit dem Werkzeug lucky-commit bewusst herbeiführte, um darauf aufmerksam zu machen, dass die Git- und Kernel-Entwicklungstools mit solchen Situationen klarkommen sollten. Es ist unwahrscheinlich, dass solche Kollisionen bei 12 Zeichen versehentlich entstehen, aber ein Angreifer könnte dies ausnutzen.

Dies sollte ein Apell an alle Entwickler sein, deren Tooling auf abgekürzte Commit-Hashes setzt. Schauen wir mal, wie sich das weiterentwickelt.

Ein Kommentar zu SHA-1

Abschließend ein Kommentar noch zu SHA-1. Wie viele von euch wissen, ist SHA-1 selbst nicht mehr vertretbar kollisionssicher. Das bedeutet, es kann passieren, dass auf einmal zwei Dateiinhalte sich doch den gleichen Hash teilen könnten, wenn ein Angreifer es drauf anlegt.

Da dies natürlich Git massiv stören könnte, gibt es schon Bestrebungen, das Verfahren auf SHA-2 zu aktualisieren, wodurch sich die Hashlänge auch vergrößert. Das ist aber gar nicht so einfach, da SHA-1 an vielen Stellen in die Struktur eines Git-Repos hartkodiert wurde.

Hier geht es aber nicht um das unsichere SHA-1. Durch die Abkürzung des Hashes von 40 auf 12 Zeichen wird die Kollisionssicherheit bewusst und massiv zugunsten der Benutzerfreundlichkeit geschwächt. Und das erfordert immer eine regelmäßige Evaluation, welches Niveau noch vertretbar ist.

Schnappszahl bei den veröffentlichten Kommentaren. Bei der Anzahl der blockierten Kommentare freue ich mich, dass die Antispam Bee so gut funktioniert.