Am heutigen 30. November jährt sich die Veröffentlichung von ChatGPT zum zweiten Mal. Die zwei Jahre fühlen sich wie vier an, wenn man bedenkt, was alles passiert ist. Blicken wir auf einige Entwicklungen zurück.

ChatGPT hat die Forschung im Bereich der künstlichen Intelligenz (KI) auf den Kopf gestellt. KI wurde in der Öffentlichkeit bis 2022 mit verschiedenen Teilbereichen wahrgenommen, z. B. Spamfilterung, Bilderkennung, Texterkennung, Klassifikation von Bildern und Texten oder Vorhersagen. Generative Modelle waren eine Nische und vielen eher durch Anwendung des Deepfakes bekannt, bei denen es darum geht, (bewegte) Bilder so gut wie möglich hochrealistisich zu approximieren und nach Belieben anzupassen.

Veränderte Forschungslandschaft

Mittlerweile könnte man annehmen, dass in der Öffentlichkeit KI, ML und LLM synonym betrachtet werden (was zum Glück nicht so gilt). Über diese Vereinfachung könnte man sich jetzt aufregen, sollte es aber differenziert betrachten. Einerseits lernen viel mehr Menschen KI kennen als vorher. Wenn diese Anwender auch nur eine der Technologien, sei es LLM, einsetzen, ist es gewissermaßen eine Bereicherung. Andererseits versuchen viele, bestehende Verfahren und Technologien auf LLMs anzuwenden. Zum Beispiel kann eine Klassifikation (z. B. Spam oder nicht Spam?) entweder mit einem spezialisierten Modell (z. B. Bayes) durchgeführt werden – oder ChatGPT kann einfach nach der Einordnung gefragt werden. Dieser Einsatz ist kritischer zu hinterfragen, weil Nebeneffekte wie Halluzinationen bisher zuverlässige Aufgaben verwässern: wenn ein Klassifikator mit der Softmax-Funktion zwischen 4 Kategorien entscheiden soll, kann er sich nur für eine Kategorie entscheiden. LLMs hingegeben können mit einer neuen Kategorie antworten.

An dieser Stelle sollte erwähnt werden, was ChatGPT eigentlich ist: Es war, ist und bleibt wohl vorerst eine aufgepumpte Textvervollständigungsmaschine. Dabei können die Modelle zum jetzigen Forschungsstand weder das Gesagte konzeptionalisieren, noch einen inneren Sinn anwenden. Die Modelle wurden darauf trainiert, kohärente Texte für Eingaben auszugeben. So kann eine Anfrage wie "Was ist 2+2?" sicherlich durch Training mit 4 beantwortet werden. Das Modell ist jedoch an sich nicht in der Lage, beliebige Rechenaufgaben mit der Präzision eines Taschenrechners zu beantworten.

Das Spannende ist aber der Zusatz "an sich", den ich der Vollständigkeit halber erwähnen muss. Denn die Forscher und Entwickler haben begonnen, diese Schwäche mit Tricks zu kompensieren. Beim Toolformer-Ansatz wird das LLM darauf optimiert, anstatt einer direkten Antwort einen Funktionsaufruf an der passenden Stelle möglichst syntaktisch korrekt auszugeben, z. B. Das Ergebnis von 2+2 ist [Calculator(2+2)]. Die LLM-Ausgabe kann dann anschließend einem Interpreter übergeben werden, der für vorgegebene Funktionen deterministisch korrekt die Berechnung durchführt und das Ergebnis an der Stelle einfügt.

Es lässt sich erahnen, dass LLMs mittlerweile mehr als das reine Modell sind. Die Ausgaben werden technisch durch gezielte Fragestellung, das Prompt Engineering, in eine bestimmte Richtung gelenkt und anschließend angereichert. Diese Schritte können beliebig oft wiederholt werden. Baut man dieses Verfahren so aus, dass in der Antwort bestimmte Aktionen benannt werden, auf die dann wieder Eingaben folgen, kann man Agenten bauen. Das ist ein jahrzenhntealter Ansatz, der jetzt wieder in Mode kommt.

Dieses Ökosystem ist umfangreich und wächst immer weiter. Nur, weil ich ein Large Language Model habe, habe ich noch kein funktionierenden ChatGPT-Klon. Vielmehr gilt es, operative und technische Herausforderungen im Backend zu lösen (Stichwort GPUs und Clustering) und das Modell in eine Pipeline einzubetten. Das Training allein reicht somit nicht mehr aus – bildet aber auch keine Voraussetzung mehr, wie wir später sehen.

Grundsätzlich ist es gut, wenn mehr Aufmerksamkeit der Erforschung künstlicher Intelligenz und maschinellem Lernen gewidmet wird. Die durch die hohen Trainingskosten notwendig gewordene Kommerzialisierung zur Finanzierung hat allerdings auch umfangreiche Auswirkungen gehabt. Die Start-up-Welt verschob sich nicht nur von Blockchain, Metaversum und Fintech hin zu AI, sondern wurde getrieben vom Ziel, das beste Modell zu trainieren. Rückblickend ein Himmelfahrtskommando, wenn man sieht, wie schnell neue Modelle veröffentlicht wurden und wie gering der Return-on-Invest ausfallen kann.

Das Jahr 2023 fühlte sich an, als würde jedes KI-Labor eines jeden größeren Konzerns die Zwischenergebnisse seiner LLM-Leute veröffentlichen. Jede Woche gab es neue Papers, die nicht mehr in jährlichen begutachteten Konferenzen, sondern als Preprint auf arXiv veröffentlicht wurden. LLMs gibt es schon seit über 5 Jahren, aber die Zuverlässigkeit und verbundene Aufmerksamkeit wurde erst mit dem Durchbruch von InstructGPT ermöglicht, was die Basis von ChatGPT in der ersten Version bildete. In 2023 habe ich aktiv eine LLM-Timeline gepflegt und es wurde deutlich, dass "jeder" es einmal versuchen wollte, Beispiel BloombergGPT. Jeder einzelne Beitrag war dabei wertvoll, es war jedoch schwer, den Überblick zu behalten.

Der Gewinner: Open Source

Der Gewinner der letzten zwei Jahre war jedoch nicht nur OpenAI, das letztes Jahr um diese Zeit mit Machtkämpfen (wired.com) beschäftigt war. Vielmehr hat mit Meta (Facebook) ein Unternehmen das Ruder an sich gerissen, von dem man es am wenigsten erwartet hätte, und einen Beitrag geleistet, den man sich noch weniger hätte vorstellen können. Der zeitlich passende Shift von Metaverse zu AI war die Überraschung der letzten Jahre, wie man auch im Aktienkurs sehen konnte.

Die Problematik war, dass die bereits erwähnte Kommerzialisierung zu proprietären Modellen geführt hat, bei denen weder die Gewichte als Basisdaten veröffentlicht noch die Mitbenutzung erlaubt wurde. Durch das aufwändige Training und die hohe Anpassungsfähigkeit an neue Aufgaben hatte auf einmal das Modell an sich einen Wert. Davor war es entweder die Methodik, wie man ein solches Modell trainiert und einsetzt (das - und nur das - ist im Übrigen in der Regel auch nur wissenschaftlich publikationfähig) oder der Datensatz selber, auf dem trainiert wurde. Das Modell konnte man sich früher einfach selber erzeugen und so die Experimente reproduzieren.

Meta AI war nun einer der ersten großen Anbieter, die mit LLaMA im Februar 2023 ein Modell aufwändig trainiert und dann zum Download freigegeben haben. Das geschah allerdings noch unter einer recht restriktiven Lizenz und mit persönlicher Voranmeldung, war aber eines der ersten Modelle, das an die Leistung von OpenAI im entferntesten herankam. Interessanterweise war es auch die ausbleibende Klagewelle, die zur Verbreitung und Weiterentwicklung der Modelle führte, die rechtlich mindestens in einem Graubereich geschah und fast schon an die Einführung der Kartoffel in Deutschland erinnerte.

Spätere Versionen wie Llama 3 wurden unter freizuzügigeren Lizenzen veröffentlicht. Bei diesen lässt sich streiten, ob man sie als Open Source bezeichnen kann. Fest steht, dass für den Einsatz somit Modelle bereitstehen, an denen man lokal testen und sie ggfs. auf eigene Trainingsdaten anpassen kann. Bei der Bilderkennung wurde hierbei üblicherweise der Begriff Transfer Learning verwendet, bei LLMs wurde das Verfahren als Finetuning bekannt. Somit war auch die Bezeichnung von Foundation Models geboren, die die Basis für Finetuning bilden.

Aus Europa stammt ein zwischenzeitlich ähnlich leistungsstarkes Modell mit dem Namen Mistral, das mit der Apache-2.0-Lizenz auch eine echte, anerkannte Open-Source-Lizenz trägt. Der Trend geht somit Richtung Open Source. Zieht man die Parallele zu den Betriebssystemen mit Windows und Linux, ist es schon sehr überraschend, dass in einer solchen Massentechnologie mit technsichen und finanziellen Hürden tatsächlich so schnell der Gedanke der Open-Source-Kultur keimt.

Gesellschaft und Regulierung

Eine weitere Parallele ist die gesellschaftliche Akzeptanz. Diese ist verglichen mit dem Jahr 2000 überraschend hoch. Während Wikipedia als Konkurrenz zur gedruckten Enzyklopädie zu meiner Schulzeit mindestens verachtet wurde, ist ChatGPT als Alternative zur eigenen Arbeitsleistung überraschend salonfähig. Es gilt vielmehr ein "Es geht nicht weg, wir müssen damit klarkommen!" als ein "Wir müssen es unbedingt bekämpfen!".

Bleibt zum Schluss noch der Blick auf die Regulierung. Die Veröffentlichung von ChatGPT kam in dieser Hinsicht zu einem ungünstigen Zeitpunkt. Die Europäische Kommission hat sich in den vergangenen Jahren vorgenommen, den Einsatz in bestimmten Bereichen der künstlichen Intelligenz im Hinblick auf z. B. Scoring-Systemen für Kredite oder Gesichtserkennung zu regulieren. Also typische Einsatzbereiche, die man sich zu der Zeit vorstellte. Ein erster Gesetzesentwurf wurde Anfang 2021, also ein halbes Jahr vor ChatGPT, vorgelegt. Mit ChatGPT kam dann in dem Gesetzgebungsverfahren so richtig Fahrt auf, sodass einerseits die Gegner von KI-Systemen mit einem großen Verbotshebel in der Verhandlung antraten, die Befürworter die Verordnung nicht aus den Augen verloren und die Investitionsträger von KI-Start-ups ihre wirtschaftliche Position bewahren wollten. Das Ergebnis war, dass Foundation Modelle in die Verordnung aufgenommen wurden, aber ab einer Grenze, die scheinbar ihren geistigen Ursprung interessanterweise in der einer zeitgleich entwickelten Executive Order 14110 des US-Präsidenten Joe Biden hat. Zwischenzeitlich ging es darüber hinaus um die strikte Regulierung jeglicher statistischer Methoden. Dies wurde glücklicherweise aber noch abgeschwächt.

Mittlerweile ist der AI Act von der EU in Kraft. So unnötig ich die Regulierung zu einem solch frühen Zeitpunkt halte, so halte ich die Ausnahme großer Teile der Forschung von der Regulierung als wichtige Errungenschaft. Dass man heute aber für Dinge kämpfen muss, die gestern noch selbstverständlich wären (Forschungsfreiheit), ist auch ein Zeichen gesellschaftlicher Umwälzungen.

Interessanterweise gibt es aber mit der TDM-Schranke auch EU-Voragben, die im in dieser Thematik nicht zu unterschätzenden Urheberrecht dem Training von LLMs zuträglich sein können. Ob und inwiefern diese Schranke für Wissenschaft und Wirtschaft anwendbar ist, wird aktuell durch Gerichtsverfahren und Gutachten geklärt.

Fazit

Ich nutze ChatGPT regelmäßig und sehr gerne und finde daher die Veröffentlichung vor zwei Jahren einen wichtigen Meilenstein, zumal es sehr gut bei Übersetzung oder Grammatikoptimierung hilft (dieser Text ist aber menschengeschrieben). Tatsächlich habe ich knapp ein Jahr vorher schon begonnen, mit GPT-3 zu arbeiten, weil es zu der Zeit schon recht populär war, aber noch viel manuelle Arbeit für gute Ergebnisse erforderte. Mit ChatGPT hat sich die Zugänglichkeit und Qualität von LLMs deutlich vereinfacht, weswegen ich den kometenhaften Aufstieg des Produktes gerechtfertigt sehe.

2023 befand sich allerdings die gesamte Techindustrie regelrecht in einem Wahnzustand. Die anfangs hohen Erwartungen, die in die Werkzeuge gesteckt wurden, konnten teilweise erfüllt werden. Wie hoch die Erwartungen allerdings tatsächlich waren, zeigt sich erst, wenn die Investments realisiert werden.

LLMs sind der Hammer, mit dem jedes Problem wie ein Nagel aussieht. Für die Zukunft wünsche ich mir mehr Differenzierung, da es mehr als LLMs in der KI-Welt gibt. Dabei blicke ich gespannt auf die Robotik, weil sich hier ein weiterer großer Anwendungszweck der KI befindet, der auf seinen Durchbruch wartet. Schauen wir, was uns die nächsten Jahre bringen.

Kurz notiert: In den letzten Tagen kursierte ein Artikel von Geoff Huston von der APNIC durchs Netz, in dem er das Ziel in Frage stellt, IPv4 langfristig durch IPv6 zu ersetzen. Warum es obsolet ist? Weil es DNS, NAT und SNI gäbe. Heißes Thema, ich weiß.

Drei Gedanken hierzu:

(1) Transition. Ja, hier hat IPv6 ziemlich versagt und das war schon ziemlich früh absehbar, siehe The IPv6 mess von djb. Ich muss eine Station komplett für IPv6 und IPv4 konfigurieren, damit in der Übergangsphase die Erreichbarkeit sichergestellt ist. Das ist das Gegenteil, wie viele Protokolle agiert haben, die sich gut migrieren lassen. Bei abwärtskompatiblen Protokollen sieht das Protokoll für nicht migrierte Teilnehmer wie das alte Protokoll aus und neue Teilnehmer können anderweitig die neue Version erkennen und besondere Features nutzen. Hätte man besser machen können, aber ich vermute, dass die IPv6-Autoren auch mit einer unkomplizierten Migration gerechnet haben. Und eines ist auch klar: Wenn man ein Protokoll neu und ordentlich entwirft, kann man auch endlich alte Zöpfe abschneiden.

(2) Internet gleichberechtiger Teilnehmer. Einer der großen Durchbrüche beim TCP/ICP-basierten Internet, so wie wir es heute kennen, ist, dass technologisch nicht zwischen Konsument und Produzent unterschieden wird. Jeder Teilnehmer kann einen eigenen Server aufspannen und möglichst weltweit seine Dienste anbieten. NAT (vor allem, wenn man es selber nicht verwalten kann) verhindert das Prinzip und schafft ein klares Gefälle, weil hinter dem NAT liegende Stationen nicht mehr frei agieren können.

(3) IPv4-Adresshandel. Die Knappheit der IPv4-Adressen hat einen Markt geschaffen, wo /24er-Blöcke für zehntausende an Euros gehandelt werden. Wir reden hier – um bei einer Analogie zu bleiben – von reinen Nummerschildern. Diese künstliche Verknappung schafft eine weitere Einstiegshürde für neue, ggfs. Teilnehmer und friert in Folge nur den heutigen Status Quo ein.

Fazit: Eigentlich ist die IPv6-Migration auf einem guten Weg. IPv6-only sollte auch das Ziel in meinen Augen sein. Jetzt auf dem (vermutlich erst halben) Weg abzubrechen, würde ich aber sehr kritisch sehen, weil es nur denen in die Hände spielen würde, die sowieso nach alter TK-Manier eine Unterteilung in Konsumenten und Produzenten sehen wollen. Aber jeder der großen Big-Tech-Konzerne auch mal als kleiner Teilnehmer an den Start gegangen. Die Schaffung höherer Einstiegshürden ist zwar in so einem Markt natürlich, aber nichts, was man gutheißen sollte. Freier Zugang für das Internet ist für die Innovationsfähigkeit umso wichtiger, weil aufstrebende Nutzer im Netz der KI-generierten Inhalte noch einen Unterschied machen können – außerhalb der moderierten Plattformen. Und für einen freien Zugang braucht man auch eine freie Adressvergabe und das geht nur, wenn – wie bei IPv6 – viele Adressen noch günstig verfügbar sind, ohne, dass man erst "digitales Land" für substanzielle Beträge abkaufen muss.

Die letzten wichtigen verbleibenden Bausteine für den Realtime-Support für Linux wurden in den Mainline-Zweig aufgenommen. Das bedeutet, dass Linux 6.12 voraussichtlich in einem echtzeitfähigen Modus betrieben werden kann, wenn der Kernel entsprechend kompiliert wird.

Echtzeitfähigkeit wird insbesondere in Embedded-Szenarien benötigt, wenn auf eine Eingabe innerhalb einer vorhersagbaren Zeit eine Antwort erwartet wird. Speziell in der Robotik, aber auch in der Multimediaproduktion gibt es solche Anforderungen. Dabei kommt es nicht darauf an, dass eine Aufgabe schnell abgearbeitet wird, sondern, dass sie in einer deterministischen Zeit begonnen wird.

Ein Beispiel für Echtzeit

An dieser Stelle mag sich die Frage stellen, was diese Echtzeitfähigkeit, von der hier geredet wird, überhaupt ist. Das lässt sich gut am Beispiel eines Line-following Robot klären. Was ein solcher Roboter tut, kann man sich z. B. in diesem YouTube-Video ansehen. Technisch besteht so ein Roboter aus zwei (oder mehr) Kameras als Sensoren, zwei Motoren für jeweils ein Rad als Aktoren und einem Controller zur Steuerung. Die Kameras sollen den Kontrast ermitteln, damit festgestellt werden kann, ob sie noch auf die schwarze Linie zeigen. Bemerkt eine der Kameras beim Fahren, dass sie den Sichtkontakt zur Linie aufgrund z. B. einer Kurve verliert, müssen die Motoren durch eine leichte Drehung nachsteuern, um auf der Linie zu bleiben.

Diese Kameras lösen üblicherweise entsprechend ihrer Abtastfrequenz auf dem Controller für die Steuerung einen Interrupt aus. Das führt zur Abarbeitung der Steuerungsroutine, die für beide Motoren die Geschwindigkeit berechnet, mit der sie sich drehen sollen.

Entscheidend ist, dass nicht beide Kameras den Sichtkontakt verlieren, damit der Roboter weiterhin weiß, in welche Richtung er nachsteuern muss. Üblicherweise wird das beim Testen funktionieren, aber es kann in bestimmten Randbedingungen bei normalen Betriebssystemen, wenn der Controller z. B. mit vielen anderen Aufgaben zufälligerweise beschäftigt ist, passieren, dass auf einmal nicht schnell genug die Routine aufgerufen wird. Der Roboter verliert dann den Sichtkontakt.

Der Entwickler eines solchen Roboters kann nun eine Echtzeitanforderung formulieren, dass z. B. auf ein Interrupt von den Kameras innerhalb von 1 Millisekunde reagiert werden muss. Er kann mit dieser Anforderung jetzt die maximale Geschwindigkeit des Roboters so wählen, dass der Roboter langsam genug fährt, um nicht die Linie – trotz der Latenz von im worst-case 1 Millisekunde – nicht zu verlieren.

Diese 1 Millisekunde muss aber auch vom Controller, seinem Betriebssystem und schließlich seinem Kernel garantiert werden. Der Kernel muss also in jeder Situation in der Lage sein, auf eine Anforderung innerhalb einer vorbestimmten Zeit zu reagieren. Unabhängig von der zwingenden Fähigkeit, präemptiv zu arbeiten, also jederzeit anderer Prozesse unterbrechen zu können, darf der Kernel auch nicht mit sich selber unvorhersehbar lange beschäftigt sein, wenn z. B. eine Synchronisation hängt.

20 Jahre Arbeit

Und genau hierum geht es beim grob gesagt beim PREEMPT_RT-Patch. Der Kernel muss so nachgebessert werden, dass keine Komponente sich unnötig lange aufhängt und somit die Abarbeitung von Aufgaben behindert, für die eine garantierte Ausführungszeit festgelegt wurde.

Die ursprüngliche Arbeit begann bereits im Jahr 2004 auf einem getrennten Zweig und hatte viele Verbesserungen in den Kernel gebracht, zuletzt an der printk()-Infrastruktur. Jetzt sollten die Arbeiten so weit sein, dass Realtime nicht mehr auf einem getrennten Zweig, sondern im Hauptzweig entwickelt werden kann.

Die Echtzeitfähigkeit gab es somit in speziell präparierten Kernels schon lange. Neu ist, dass der Code im Hauptzweig gepflegt wird und somit besser mit Änderungen anderer Maintainer abgestimmt werden kann. Denn eine Änderung an einer anderen Komponente reicht schon aus, um die Echtzeitfähigkeit zu unterminieren.

Linux echtzeitfähig zu machen, ist somit ein großer Aufwand gewesen, weil man solche Fähigkeiten oft nur in spezialisierten Betriebssystemen (sogenannten Real-time operating systems, RTOS) vorfindet. Insbesondere Thomas Gleixner und John Ogness haben hier große Anstrengungen unternommen. Jetzt, nach knapp 20 Jahren Arbeit, dürfte das Vorhaben einen wichtigen Meilenstein erreichen.

Wer sich für einen tieferen Einblick in die Linux-RT-Welt interessiert, kann einerseits den Artikel von Thomas Leemhuis auf Heise Online von letzter Woche lesen oder sich auf LWN durch das Artikelarchiv zu der Thematik arbeiten.

Interessanter Gegentrend: Während ich vor ziemlich genau einem Jahr über das zu der Zeit aktuellste Beispiel HashiCorp schrieb, wo eine Umstellung auf BSL-artige Lizenzen erfolgte, scheint es wohl auch einige Kandidaten zu geben, die wieder auf OSI-genehmigte Lizenzen umstellen. So verkündete Elastic am vergangenen Donnerstag, das sie wieder mit ihrer Suchmaschinensoftware Elasticsearch "Open Source" werden möchten, indem sie die AGPL als Lizenzoption aufnehmen.

Hintergrund

Hier einmal der Hintergrund bis jetzt, so wie es auf mich als externen Beobachter wirkte: Open Source hat es im Zeitalter der Cloud recht schwer, wenn man damit Geld verdienen möchte (um z. B. die Entwicklung zu finanzieren!). Das verbreitete Standardmodell zur Monetarisierung war bisher, eine Software Open Source anzubieten und den Support oder das Hosting kostenpflichtig anzubieten. Aus Kundensicht bestellt man dann direkt bei dem Hersteller, der seine Software auch am besten verstehen sollte.

Cloud Provider haben dem Modell das Wasser abgegraben, da sie einfach die Open Source Software nehmen und auf ihrer Plattform deployen konnten – ohne einen Cent dem Projekt zahlen zu müssen. Teilweise wurde die Software erweitert, ohne, die Änderungen wieder veröffentlichen zu müssen (deswegen sind auch die MIT- und BSD-Lizenzen so beliebt). Aus Kundensicht kauft man zwar nicht mehr bei dem Hersteller ein, hat aber

• einerseits alles zentralisiert auf einer Cloudplattform und
• andererseits gar keinen Bedarf für Herstellersupport, weil die Software sowieso über das SaaS-Modell supported wird und nicht mehr on-premise läuft.

Die Antwort vieler Projekte war es nun, die Lizenz so zu ändern, dass dieses Verhalten nicht mehr möglich ist, z. B. durch die Beschränkung von Konkurrenz-Hostingprodukten. Das verstößt allerdings gegen das Diskriminierungsverbot der OSI, nach dem die Verwendung von Produkten nicht durch die Lizenz beschränkt werden sollte (siehe auch das Good-Evil-Thema bei der JSON-Lizenz).

In der Konsequenz spalteten sich wie mit Open Search Elasticsearch-Forks ab, die weiterhin die offenen Lizenzen nutzen und durch Cloud Provider wie AWS direkt gepflegt wurden und werden. Wie Elasticsearch betont, sollen diese Projekte aber gleichzeitig auch einen eigenen Weg mit eigener Spezialisierung entwickelt haben. Die Community war natürlich aber auch verärgert, da die Software Elasticsearch nun nicht mehr als Free Open Source Software (FOSS) galt.

Wieder Open Source

Elasticsearch plant nun die Wogen zu glätten, indem die AGPL als weitere Lizenz zur ELv2 und SSPL zusätzlich aufgenommen wird. Die Nutzer können also frei entscheiden, welche Lizenz sie nutzen wollen, da insbesondere im Geschäftskontext die AGPL juristisch gesehen als heikel eingeschätzt wird, wenn man das Produkt aus verschiedenen Komponenten zusammengebaut und nicht den gesamten Quelltext veröffentlichen möchte. FOSS-Nutzer und Distributionen haben allerdings wieder die Möglichkeit, die Software wiederaufzunehmen. So entspricht z. B. die AGPL den Debian Free Software Guidelines.

Ende gut, alles gut? Wenn es nach der Ankündigung von Elastic geht, ist das Team zufrieden mit der Entscheidung, wieder Open Source zu sein. Ob der Fork OpenSearch aufrecht erhalten wird oder schlussendlich in das Urprodukt einfließt, ist allerdings noch nicht gewiss und muss sich in der Zukunft zeigen. Vielleicht sind die Communities auch schon zu sehr divergiert, sodass es nun unterschiedliche Lösungen für unterschiedliche Anwendungsfälle gibt.

Wer sagte noch gleich, dass klassische Release-Distributionen den Rolling Releases überlegen sind, weil sie so stabil seien? Dass es Ausnahmen von der Regel gibt, durfte ich heute erleben. Ich liebe diese Tage, wo auf einmal die normalsten Dinge nicht mehr gehen...

Es galt etwas in einem Softwareprojekt zu testen, das ich hierfür erstmal wieder in Gang bringen musste. Dabei setzt das Projekt auf Vagrant in Kombination mit VirtualBox. Ich habe dazu erstmal das Hostsystem aktualisiert und versucht, mit Vagrant die Maschine aufzusetzen – um dann feststellen zu dürfen, dass Vagrant einen Fehler wirft.

Was ging schief?

Konkret war VirtualBox in die Guru Meditation gefallen. Das tritt dann auf, wenn ein besonders schwerer Fehler auftritt, sodass das Programm nicht ordentlich weiterlaufen kann. Dabei war doch gar nicht viel am Entwicklungssystem verändert worden? Ich halte für solche Entwicklungsprojekte dedizierte Entwicklungsmaschinen vor, auf denen sich das Betriebssystem über die Jahre nicht verändert und die für die tägliche Arbeit auch entsprechend nicht eingesetzt werden. Was ich aber tue: die Zwischenupdates einspielen.

Stellt sich heraus, dass unter Ubuntu 22.04 LTS die Kernelversionen ab 5.15.0-112 den Fehler VERR_VMM_SET_JMP_ABORTED_RESUME wohl verursachen. Der Bug wird schon auf Launchpad, bei ubuntuusers.de und auch im VirtualBox-Forum diskutiert.

Wie kann man das fixen?

Man könnte einereits den Kernel downgraden bzw. einen alten Kernel nutzen, was aber nur kurzfristig Abhilfe schafft. Alternativ gibt es die Flucht nach vorne: entweder Ubuntu auf 24.04 LTS upgraden (habe ich nicht probiert, scheinbar ist der automatische Update-Pfad auch noch gar nicht freigeschaltet) oder VirtualBox auf Version 7.0 updaten. Ich habe mich für letzteren Schritt entschieden und dabei auf die offiziellen VirtualBox-Pakete von Oracle zurückgegriffen, da in den offiziellen Ubuntu-Repos für die Version nur Version 6.1 enthalten ist (was ja bei LTS-Versionen eigentlich auch sinnvoll ist). Das ist natürlich keine schöne Lösung, da man sich fremde Pakete in das System holt – aber sie funktioniert. Man muss allerdings auch bedenken, dass die aktuelle Vagrant-Version, die in den Ubuntu-Repos für 22.04 (jammy) enthalten ist, VirtualBox 7.0 noch gar nicht unterstützt. Folglich muss man dann auch auf die offiziellen Repositories von Hashicorp zurückgreifen – was allerdings angesichts der lizenzrechtlichen Änderungen sowieso bald nötig wird.

Was lernen wir daraus?

Software muss laufend auf Regressionsfehler getestet werden, die durch Updates an anderen Stellen passieren können. Ja, diese Fehler können immer passieren und sind teilweise schwer zu verhindern. Gleichzeitig muss man aber selber auch seine Setups regelmäßig testen, um schnell zu erkennen, dass ggfs. das Kernelupdate schuld war. Mittlerweile vermutet man das aufgrund der Stabilität der Systeme schon fast gar nicht mehr. Ansonsten geht viel Zeit aufgrund der Fehlersuche ins Land. Da ist es auch wenig zuträglich, dass die VirtualBox-Logs scheinbar keine Log Level beinhalten...

Ein Fix seitens Ubuntu steht für diesen Bug im Übrigen noch aus. Theoretisch sollte sich dann das Thema von selbst erledigen, weil die betreffende Änderung im Kernel einfach reverted wird. Ich wollte zwischenzeitlich aber die Workarounds einmal auflisten, sollte jemand ähnliche Probleme haben.

Dem Forscherteam von Qualys ist es gelungen, eine ältere Sicherheitslücke in OpenSSH, die schon eigentlich längst geschlossen war, erneut auszunutzen. Die neue Lücke wird als CVE-2024-6387 geführt und ist deswegen brisant, weil Sie bei Erfolg dem Angreifer Root-Rechte ohne vorherige Authentifizierung ermöglicht. Die nötigen Bedingungen für ein Ausnutzen der Lücke sind allerdings nicht ganz trivial.

Die gesamte Erläuterung der Sicherheitslücke ist im Bericht von Qualys umfangreich erläutert wollen. Wenn wir es schaffen, werden wir diesen schon Mittwoch im Risikozone-Podcast detaillierter erläutern.

So viel sei gesagt: die Lücke existierte schon mal als CVE-2006-5051, wurde dann gefixt und konnte jetzt (erstmals) ausgenutzt werden, da der eigentlich kritische Teil 2020 wieder versehentlich eingebaut wurde. Der Fehler selber baut darauf, dass syslog() zur Protokollierung asynchron aufgerufen wird, obwohl die Funktion nicht "async-signal-safe" ist. Kann ein Angreifer Timingeigenschaften ausnutzen, wird er in die Lage versetzt, Code einzuschleusen, der in einem privilegierten Teil von OpenSSH ausgeführt wird. Der Zeitaufwand ist allerdings hierfür nicht zu unterschätzen, da das Codefragment nur bei einem Verbindungstimeout aufgerufen wird.

Es ist gemäß des Qualys-Berichtes hervorzuheben:

• Die OpenSSH-Versionen vor 4.4p1 (2006) sind angreifbar, sofern sie nicht explizit gepatcht wurden.
• Die OpenSSH-Versionen zwischen 4.4p1 und 8.5p1 (2021) hatten nicht den besagten Code drin.
• Die OpenSSH-Versionen ab 8.5p1 hatten den Code wieder drin.
• Mit OpenSSH 9.8p1 wurde die Lücke gepatcht.

Mit anderen Worten: abhängig von eurem System ist die Schwachstelle vorhanden, weswegen ihr in eure Distribution schauen solltet, ob es Updates gibt.

OpenSSH ist nichtsdestotrotz im Hinblick auf seine Rolle und Exposition eines der sichersten Programme der Welt. Die Software ist ein sehr stringent abgesicherter Dienst, der u. a. auf Sandboxing-Mechansimen setzt, um den Umfang der Codesegmente, die als root ausgeführt werden, gering zu halten. Diese Lücke ist eine der seltenen Situationen, in der trotzdem ein Security-Bug vorhanden ist. Dabei ist eine Ausnutzung vergleichsweise aufwändig.

Kurz notiert: Debian 10 mit dem Codenamen "buster" erreicht heute das End of Life. Die Unterstützung wurde bis 2022 vom Debian-Team bereitgestellt und dann bis zum heutigen Tage durch das LTS-Team sichergestellt. Damit wurde Debian 10 knapp fünf Jahre durchgängig unterstützt.

Debian 10 wurde am 6. Juli 2019 und somit vor knapp fünf Jahren veröffentlicht. Ausgeliefert wurde das Betriebssystem mit dem Linux-Kernel 4.19. Der letzte Point-Release erfolgte am 10. September 2022, damit endete auch der klassische Security-Support.

Anschließend hat das LTS-Team die Unterstützung am 1. August 2022 mit einer Teilmenge von Architekturen (amd64, i386, amd64, armhf) übernommen, damit Nutzer wichtige Sicherheitsupdates noch erhalten und die Gelegenheit haben, auf den Folge-Release umzustellen. Diese Unterstützung läuft am heutigen Tage aus.

Es ist somit an der Zeit, auf Debian 11 mit dem Codenamen "bullseye" umzustellen. Die Migrationsanleitung ist in den Release Notes für Debian 11 zu finden. Hier wird auch erläutert, mit welchen Breaking Changes zu rechnen ist. Wie üblich, lässt sich der Release über die APT-Konfiguration anheben, gefolgt von einem Upgrade über APT. Die wichtigste Änderung dabei ist, dass das Security-Archiv ein neues Layout hat. Ich habe einige Systeme schon aktualisiert, dabei gab es bei mir keine Probleme. Das sollte auch bei anderen Systemen keine Schwierigkeiten bereiten, wenn sich an den offiziellen Debian-Paketquellen orientiert wird. Die Backports sollte man aber kontrollieren, wenn z. B. ein Backports-Kernel genutzt wurde, um WireGuard schon mit Debian 10 nutzen zu können (erst Debian 11 hat eine Kernelversion, in der WireGuard integriert ist).

Aktuell werden vom Debian-Team die Versionen 11 (bullseye) und 12 (bookworm) als Hauptversionen gepflegt. Das LTS-Team ist eine Gruppe von Freiwilligen, die sich zum Ziel gesetzt hat, eine fünfjährige Unterstützung für Debian-Versionen sicherzustellen. Wer eine zehnjährige Unterstützung benötigt, kann auf entgeltliche ELTS-Angebote wie z. B. von Freexian zurückgreifen.

Ich hatte es geahnt, aber dann ging es doch schneller als gedacht. Mit der Entscheidung des Europäischen Gerichtshofes Ende April wurde in einem Fall in Frankreich die Speicherung von IP-Adressen seitens des ISPs auf Vorrat nicht nur für den Bereich schwerer Straftaten, sondern auch für Urheberrechtsverstöße für zulässig erachtet. Damit ist eine Diskussion wieder auf dem Tisch, die seit 20 Jahren regelmäßig aufflammt, aber bisher durch Urteile gegen die erlassenen Gesetze eingefangen wurde.

Mit diesem Thema haben wir uns vergangene Woche mit Professor Dr. Stephan G. Humer in der 48. Episode des Risikozone-Podcasts beschäftigt, den ich euch wärmstens empfehlen kann.

Die klassische VDS in Deutschland wird momentan nicht praktiziert, da sie nach einem älteren Urteil des EuGH, das konkret das deutsche Gesetz betraf, als rechtswidrig eingestuft wurde. Nichtsdestotrotz ist die Diskussion wieder eröffnet und alle Möglichkeiten für Vorhaben zur Wiedereinführung werden wieder eingebracht. Das Thema wird uns also weiterhin noch eine ganze Weile verfolgen.

Klar, im Urteil des EuGH wird als Bedingung gestellt, dass Maßnahmen getroffen werden müssen, damit die Privatsphäre der einzelnen Nutzer gewahrt bleibt, aber das ändert nichts daran, dass die Daten grundsätzlich erstmal erhoben werden. Die "Neuerung" in diesem Urteil zu der Thematik ist, dass IP-Adressen und Identitäten getrennt gespeichert werden müssen. Mir ist allerdings noch nicht einleuchtend, was im Urteil mit der "Verknüpfung nur unter Verwendung eines leistungsfähigen technischen Verfahrens [...], das die Wirksamkeit der strikten Trennung dieser Datenkategorien nicht in Frage stellt" gemeint ist. Sollen die Datenbanken mit einem anschließend zu verwerfenden Schlüssel verschlüsselt werden, der bei der Verknüpfung erst geknackt werden muss? Am Ende kann ein technisches Verfahren doch gar nicht feststellen, ob ein Gesuch den formellen juristischen Anforderungen genügt oder nicht.

Technisch reden wir hier im Übrigen von zwei Teilaspekten: einerseits die Speicherung, welche Stationen (mit welchen IP-Adressen) miteinander kommunizieren und andererseits, wer hinter welcher IP-Adresse steckt. Diese ganze letzte Thematik haben wir allerdings nur, weil die ISPs einerseits ungern Privatkunden feste IP-Adressen vergeben und andererseits mitunter gar nicht so viele IP(v4)-Adressen wie Kunden haben und dann zu Tricks wie CG-NAT greifen müssen. Hämisch könnte man jetzt fragen, warum in dem Zusammenhang die Politik noch nicht alle zu IPv6 verpflichtet hat. Auf der anderen Seite wird deutlich, wie sehr sich das Internet verändert hat, nachdem es ein Massenmedium wurde.

Früher wurden feste IP-Adressen genutzt und die Zuordnung größtenteils öffentlich hinterlegt. Die Teilnehmer des Internets kannten sich mehr oder weniger sowieso alle untereinander. Als das Internet mehr und mehr ein Massenmedium wurde, ging es allerdings nicht mehr um den wissenschaftlichen oder beruflichen Austausch, sondern auch vorrangiger um das private Leben, wodurch auf einmal Grundrechte tangiert wurden und das Thema der Anonymität im Netz aufkam.

Gespeichert werden die Zuordnungen wohl auch weiterhin noch, aber sichtbar sind sie nur noch für Behörden und ähnliche Organisationen. Spätestens mit dem breiten Ausrollen der DSGVO wurde z. B. der whois-Dienst der DENIC für die Öffentlichkeit geschlossen. Wer einen Webseitenbetreiber ermitteln möchte, der kein Impressum auf der Seite stehen hat, schaut seitdem in die Röhre.

Vorratsdatenspeicherung ist und bleibt somit ein netzpolitisches Thema und lässt sich somit nicht auf der rein technischen Ebene erklären. Von da aus kann man sich oft an den Kopf fassen, was da alles von der Technik erwartet wird. Solche Themen sind auch ein Abbild der Gesellschaftspolitik, was daran deutlich wird, dass im Wesentlichen Deutschland eines der wenigen kritischen Länder diesbezüglich ist.

Die Never-ending-Story geht jetzt also in die nächste Runde. Weitere Probleme, Risiken und Lösungsansätze könnt ihr gerne euch in unserem Podcast anhören und in den Kommentaren mitdiskutieren.

Heute erscheint die 46. Episode des Risikozone-Podcasts und die zweite Episode, in der es um die xz-Lücke geht. Während es in der vorangegangenen Folge um die technischen Details ging, haben wir uns diesmal der Frage gewidmet, wie so ein Eingriff gegen ein Open-Source-Projekt überhaupt möglich werden konnte. Antwort: Es war umfangreiche psychische Manipulation im Spiel.

Deswegen haben wir den Social-Engineering-Experten Stephan G. Humer eingeladen. Er hat eines der ersten regelmäßigen Social-Engineering-Seminare in Deutschland etabliert und erläutert, was Social Engineering eigentlich ist, welche Methoden angewendet werden und wie man sich davor schützen kann.

Mit der heutigen Episode versuchen wir unserem ganzheitlichen Slogan "Der Podcast über Sicherheit und Zuverlässigkeit moderner Technologien" gerecht(er) zu werden und reden nicht nur über technische Details, sondern auch über sozialwissenschaftliche Aspekte und Kultur. Open-Source-Projekte bestehen nämlich nicht nur aus Code, sondern auch aus vielen zwischenmenschlichen Interaktionen, die eine - wie wir mit der Lücke sehen - auch im Bezug auf Sicherheit nicht zu vernachlässigende Rolle einnehmen.

Um dem knapp zweistündigen Interview in einem Punkt vorwegzugreifen: es gibt keine Patentlösung. Social Engineering ist unvermeidbar und wer glaubt, er wäre dem gefeit, ist umso verwundbarer gegenüber Angriffen. Ein entscheidender Punkt ist aber Gelassenheit und damit verbunden Verantwortungsbewusstsein. Wer ein Projekt beginnt und damit wächst, sollte sich als Maintainer in der heutigen Welt umso mehr Gedanken machen, wie man die Last verteilt, wieder aussteigt und Entscheidungen nicht auf eine Person konzentriert. Die Situation, als Maintainer wenig Zeit für ein Projekt zu haben, ist zwar im Einzelfall natürlich menschlich verständlich, aber ein Warnsignal.

Wir werden auf Zeiten keine zufriedenstellende Lösung finden und mit vereinfachten Lösungsansätzen arbeiten. Trotzdem ist es wichtig, ob solcher Angriffe zu wissen und wenigstens eine gesunde Skepsis an den Tag zu legen.

Wie seht ihr das? Wir freuen uns auf euer Feedback!

Seit 1,5 Jahren produziere ich den Podcast Risikozone, in dem es um Themen der IT-Sicherheit und Open-Source-Software geht. Die xz-Backdoor ist natürlich ein heißes Thema, weswegen es in der heute veröffentlichten Episode 45 genau darum geht.

Die knapp einstündige Podcastepisode ist für alle interessant, die nochmals einen technisch orientierten Überblick über die Geschehnisse suchen. Da die Thematik recht komplex ist und aus verschiedenen Blickwinkeln beobachtet werden kann, können weitere Podcastepisoden hierüber noch folgen. Ich möchte aber darauf eingehen, dass man diese Backdoor nicht nur auf den Code beschränken sollte. Es gibt es viele verschiedene Ebenen, die allesamt jeweils Beachtung finden sollten:

• die technische "Exploit"-Ebene
• die zwischenmenschliche Ebene
• die Ökosystem-Ebene

Technisch ist der Exploit ausgeklügelt: Die Backdoor beschränkt sich nicht nur auf die bloße Möglichkeit einer Remote-Code-Execution, sondern verwendet darüber hinaus noch ein eigenes Protokoll, mit dem die Befehle signiert und verschlüsselt innerhalb des unscheinbaren N-Wertes im Zertifikat eines SSH-Handshakes übermittelt werden. Durch die Signatur können nur Befehle ausgeführt werden, die mit einem (wahrscheinlich nur dem Angreifer bekannten) ED448-Schlüssel signiert wurden. Die Verschlüsselung erfolgt zwar mit einem statischen Schlüssel, der aus dem ED448-PubKey abgeleitet wird, erfüllt jedoch trotzdem seinen Zweck: Obfuskierung. Mit anderen Worten: wäre die Lücke nie aufgefallen, hätte man sie in der freien Wildbahn nahezu unmöglich durch Traffic-Analysen finden können.

Das ist allerdings nur die erste von drei Ebenen: die Art und Weise, wie die Lücke hereingeschummelt wurde, weist Komponenten des Social Engineering auf. Die Mühe, über mehrere Jahre eine Identität in verschiedenen Projekten mit teils anfangs legitimen Beiträgen aufzubauen, zeugt auch von einem Plan und Ausdauer.

Schlussendlich sollte man auch nicht vergessen, dass hier eine besondere Konstellation im Ökosystem ausgenutzt wurde. Am einfachsten (und auffälligsten) wäre es, eine solche Lücke in OpenSSH unterzubringen. Es wurde aber auf eine deutlich unbeachtetere und einfacher zu infiltrierende Variante ausgewichen. Die xz-Bibliothek wurde zudem nicht zum Einfallstor, weil OpenSSH darauf zurückgreift (das tut es nämlich nicht), sondern weil einige Distros systemd-notify reinpatchen, was wiederum auf die xz-Lib zurückgreift. Außerdem rüttelt dieser Fall an einem Grundpfeiler der IT-Sicherheits-Praktiken: Updates. Diese Hintertür fand geradezu durch die (häufigen) Updates der Rolling-Release-Distros Einzug - die stabilen Versionen waren noch verschont geblieben. Ist also (zu) häufiges Updaten nun auch nicht mehr richtig? Bringen bald Updates mehr Lücken als sie schließen?

Das alles macht es vor allem noch schwieriger, solche Angriffe zuverlässig zu erkennen. Zudem ist davon auszugehen, dass die Angreifer sich die Verteidigungsstrategie jetzt ganz genau anschauen. Die zukünftige Diskussion sollte sich also darauf konzentrieren, wie man diese Art von Angriffen detektiert und frühzeitig eindämmt.

Die weitverbreiteten Datenkompressionswerkzeuge XZ Utils (früher LZMA Utils) enthalten in Version 5.6 eine Backdoor. Ziel der Backdoor ist nach aktuellem Kenntnisstand eine Kompromittierung von SSH-Servern. Dies wurde gestern auf der oss-security-Mailingliste von Andres Freund nebst einer umfangreichen Analyse des Sachverhalts bekannt gegeben. Durch den Einsatz der Werkzeuge in Linux-Distributionen haben wir hier einen Fall einer Supply-Chain-Attacke. Red Hat hat dem Vorfall die CVE-Nummer CVE-2024-3094 vergeben.

Vorab eine Liste mit weiteren Links:

• Stellungsnahmen von verschiedenen Distributoren
  • Arch Linux
  • Debian
  • Red Hat
  • SUSE
• FAQ
• Hacker-News-Diskussion
• Zeitleiste

Wirkungsweise

Dabei wird die Backdoor nur unter bestimmten Bedingungen ausgeführt, wie das FAQ beschreibt. Im Wesentlichen muss argv[0] auf /usr/sbin/sshd gesetzt sein und eine Reihe an Umgebungsvariablen entweder gesetzt oder nicht gesetzt sein. Normalerweise hängt OpenSSH nicht von liblzma ab. Einige Distributoren patchen OpenSSH allerdings so, dass systemd-Notifcations funktioniert, welches wiederum auf liblzma setzt und die Backdoor möglich macht. Technisch werden einige Checks durchgeführt und anschließend mittels IFUNC Bibliotheksaufrufe umgeleitet. Dies betrifft nach aktuellem Stand auch Aufrufe während der Kryptoroutinen bei der SSH-Authentifizierung.

Betroffenheit

Der Wirkungsweise der Payload ist noch nicht abschließend geklärt. Besonders auch aus diesem Grund wird ein unverzügliches Update angeraten. Im Folgenden einige unverbindliche Faktoren, die eine Verwundbarkeit wahrscheinlich machen. Auf diese Weise kann man priorisieren, welche Systeme zuerst aktualisiert werden sollten.

Versionierte Distros wie z. B. Debian oder RHEL sind nach aktuellem Kenntnisstand mit ihren stabilen Versionen nicht direkt betroffen, da die Versionen 5.6 noch keinen Einzug in das System gefunden haben. Die Testing-Versionen dieser Distros wie z. B. Debian Sid wurden allerdings aktualisiert und sind betroffen.

Rolling-Release-Distros sind naturgemäß auch betroffen, wenn sie schon Version 5.6 in ihre Pakete aufgenommen haben. Dies betrifft zum Beispiel Arch Linux oder Gentoo. Da allerdings einige Distributionen wie Arch Linux OpenSSH nicht gegen liblzma linken, wird die Bibliothek nicht direkt in die Ausführung der Komponenten eingebunden.

Nach aktuellem Stand wird eine Verwundbarkeit besonders kritisch, wenn auf dem betroffenen Host ein öffentlich erreichbarer SSH-Server läuft, da die oben beschriebenen Faktoren ein Laden der Payload auslösen können.

Wie kam es?

Aufgefallen ist die Backdoor nur durch Zufall durch das Debugging von Performanceproblemen, die durch die Backdoor verursacht wurden. Die Backdoor wurde obfuskiert im Rahmen von Buildskripten untergebracht, sodass aufgrund der Komplexität die Lücken noch nicht direkt aufgefallen sind.

Das Repository hinter xz kann als kompromittiert gesehen werden und ist auch auf GitHub schon gesperrt worden. Auffällig ist, dass die Backdoor in den Tarballs der Releases enthalten war, nicht jedoch im Repository-Dump selber. Auch personell gab es einige Auffälligkeiten, da es vor kurzem einen Maintainerwechsel beim Projekt gab und die Lücken vom neuen Maintainer, der seit 2 Jahren am Projekt mitarbeitet, zumindest begünstigt wurden. Die Art und Weise lässt auch auf ein koordiniertes, von langer Hand geplantes Vorgehen schließen.

Einfluss und Folgen

Das große Ganze ist ein Paradebeispiel von xkcd 2347 "Dependency". Wir sehen hier Live ein Beispiel einer Supply-Chain-Attacke. Ein kleines, scheinbar unbedeutendendes Projekt wird übernommen, nur um strategisch Commits zu platzieren, die automatisch "flussabwärts" ihren Weg in größere Distributionen finden, die allesamt auf das Projekt setzen. Alles passiert trotz Open Source. Besonders pikant: der Maintainer hat aktiv versucht, die Backdoor-begünstigenden Umgebungsfaktoren, konkret das Umbiegen von Bibliotheksaufrufen mittels ifunc, in Fuzzing-Projekten wie oss-fuzz, die aktiv nach sowas suchen, zu deaktivieren.

Software wird immer bedeutender und benötigt Vertrauen. Dabei ist jetzt schon klar, dass niemand selber solch komplexe Systeme von alleine bauen kann. Aber auch die Kontrolle der Quellen ist eine große Herausforderung. Neue Gesetzgebung wie der geplante Cyber Resilience Act in der EU versuchen in der Industrie Anreize zu schaffen, die Softwarequalität zu erhöhen.

Diese Attacke konnte einigermaßen abgewendet werden, sollte die umfassende Analyse der Payload keine belastenden Neuigkeiten hervorbringen. Eines ist aber auch klar: Die Angreifer studieren das Verhalten der Verteidiger und werden in Zukunft ihre Vorgehensweise dahingehend optimieren, nicht so einfach mehr gefunden zu werden. Es ist also möglich, Backdoors in so ein Ökosystem hineinzuschummeln. Umso besser müssen aber die Identifikations- und Abwehrmöglichkeiten werden, damit solche Angriffe wirksam verhindert werden können.

Kurz notiert: heute wurde die Desktopumgebung Plasma 6 aus dem KDE-Projekt freigegeben. Mit dem Umstieg auf Qt 6 und den einhergehenden Arbeiten ist es nach knapp 10 Jahren der erste große Major-Release (KDE Plasma 5 wurde 2014 veröffentlicht). Eine weitere wegweisende Änderung ist, dass der Fokus nun klar auf dem Display-Server Wayland liegt, der auch nun zur Standardeinstellung wurde. X11 wird jedoch weiterhin unterstützt.

Eine Auswahl der weiteren Änderungen:

• Es gibt einen neuen Overview-Effekt.
• Durch Wayland wird nun auch HDR unterstützt.
• Es gibt neue Filter zur Unterstützung bei Farbenblindheit.
• Das Einstellungsprogramm wurde überarbeitet.
• Der bekannte KDE Cube ist zurück.
• Neue Standardeinstellungen:
  • Dateien/Verzeichnisse werden nun mit einem Klick ausgewählt und mit einem Doppelklick geöffnet.
  • Das Panel ist nun standardmäßig schwebend.
  • Thumbnail-Grid ist nun der Standard-Task-Switcher.
  • Scrollen auf dem Desktop führt nun nicht mehr zum Wechsel der virtuellen Desktops.

Auch die KDE-Anwendungen erfahren umfangreiche Updates. All diese Informationen können im Release Announcement nachvollzogen werden.

KDE Plasma 6 sollte nun sukzessive auch in die Distributionen Einzug halten. Arch Linux ist als Beispiel für einen Rolling Release da schon schnell dabei. Ob und inwiefern komplexe Setups des traditionell sehr einstellbaren Desktop-Systems umgezogen werden können, wird sich dann zeigen. Ein großer Vorteil des KDE-Ansatzes zeigt sich allerdings schon im Release-Announcement: viele der Funktionen können genutzt werden, müssen es aber nicht. Dem Endanwender wird die Wahl überlassen, welche Optionen er nutzen möchte.

Es gibt wieder neue Sicherheitslücken in glibc. Dabei betrifft eine die syslog()-Funktion, die andere qsort(). Letztere Lücke existiert dabei seit glibc 1.04 und somit seit 1992. Entdeckt und beschrieben wurden die Lücken von der Threat Research Unit bei Qualys.

Die syslog-Lücke ist ab Version 2.37 seit 2022 enthalten und betrifft somit die eher die neuen Versionen von Linux-Distributionen wie Debian ab Version 12 oder Fedora ab Version 37. Hierbei handelt es sich um einen "heap-based buffer overflow" in Verbindung mit argv[0]. Somit ist zwar der Anwendungsvektor schwieriger auszunutzen, weil in wenigen Szenarien dieses Argument (der Programmname) dem Nutzer direkt überlassen wird, die Auswirkungen sind jedoch umso schwerwiegender. Mit der Lücke wird eine lokale Privilegienausweitung möglich. Die Lücke wird unter den CVE-Nummern 2023-6246, 2023-6779 und 2023-6780 geführt.

Bei der qsort-Lücke ist eine Memory Corruption möglich, da Speichergrenzen an einer Stelle nicht überprüft werden. Hierfür sind allerdings bestimmte Voraussetzungen nötig: die Anwendung muss qsort() mit einer nicht-transitiven Vergleichsfunktion nutzen (die allerdings auch nicht POSIX- und ISO-C-konform wären) und über eine große Menge an zu sortierenden Elementen verfügen, die vom Angreifer bestimmt werden. Dabei kann ein malloc-Aufruf gestört werden, der dann zu weiteren Angriffen führen kann. Das Besondere an dieser Lücke ist ihr Alter, da sie bereits im September 1992 ihren Weg in eine der ersten glibc-Versionen fand.

Bei der GNU C-Bibliothek (glibc) handelt es sich um eine freie Implementierung der C-Standard-Bibliothek. Sie wird seit 1987 entwickelt und ist aktuell in Version 2.38 verfügbar. Morgen, am 1. Februar, erscheint Version 2.39.

Es ist der 31.12.2023 und somit wird es wieder Zeit für den traditionellen Jahresrückblick. Dieses Jahr dominierten zwei Buchstaben: KI. Die Veröffentlichung von ChatGPT erfolgte zwar kurz vor 2023, in diesem Jahr wurden allerdings die Auswirkungen sichtbar. Ich muss sagen, dass es lange kein Werkzeug gab, an dem ich so viel Experimentierfreude erleben konnte.

Dabei ist die Mensch-Maschine-Schnittstelle besonders spannend. Die natürlichsprachliche Interaktion verbessert nicht nur die Zugänglichkeit, sondern erhöht auch die Interoperabilität: Das Werkzeug kann nicht nur die Aufgabe verstehen, sondern die Ergebnisse in der gewünschten Form darstellen. Schreibe ich eine Software, erfüllt sie nur einen Zweck. ChatGPT kann besonders einfach an neue Aufgabenbereiche angepasst werden. Man muss nicht einmal im klassischen Sinne "programmieren". Somit wird die Arbeit mit dem Computer auf eine ganz neue Stufe gehoben.

Auf die technische Ebene möchte ich heute gar nicht direkt eingehen, das haben wir das Jahr schon im Detail in diesem Blog ergründet. Diskussionen über Technik und Innovationen stellen nur eine Augenblickaufnahme dar. Im Rückblick auf eine größere Zeitepisode wie ein mindestens Jahr werden allerdings gesellschaftliche Entwicklungen deutlich. Und hier gab es einiges zu beobachten.

KI für die Massen

ChatGPT hat eine große Nutzerbasis erreicht, die zumindest ein Mal das Werkzeug ausprobiert hat. Im deutschsprachigen Raum, der sonst sich so "datenschutzorientiert" und innovationskritisch gibt, ist das schon bemerkenswert. Diskussionen über Datenschutz waren zweitrangig, die Menschen waren von der Innovation durch das Werkzeug fasziniert. Natürlich kam über das Jahr die Erkenntnis, dass in der aktuellen Form die Technologie je nach Branche noch nicht weit genug ausgereift ist, trotzdem wollte jeder einmal schauen, was es damit auf sich hat und ob es den Alltag erleichtern kann.

Und doch hat OpenAIs Werkzeug in meinen Augen ein wenig den Blick verengt: Durch das schnelle Wachstum wurde ChatGPT zum Sinnbild von "KI" und hat Ängste geschürt. Denn einerseits will jeder, dass KI ihm das Leben einfacher macht, jedoch nicht, dass andere mit KI ihm seine Lebenssituation verschlechtern bzw. ihn zu einem Umdenken zwingen. Ein Zeitungsredakteur möchte gerne KI für die Verbesserung seiner Texte einsetzen, fürchtet jedoch um seine Jobzukunft, wenn andere ihn durch automatische Generierung ganzer Zeitungsbeiträge drohen, überflüssig zu machen.

Dieser Umstand hat die Diskussion rund um den europäischen AI Act noch einmal deutlich angeheizt. An Large Language Models wurden auf einmal hohe Anforderungen gestellt, um subjektiven Ängsten entgegenzutreten. Dann war man sich aufgrund der Innovationsgeschwindigkeit auf einmal nicht sicher, ob es jetzt schon Zeit für eine starre Regulierung ist. Und schlussendlich zeichnet sich eine politische Entwicklung ab, jetzt lieber irgendeinen Kompromiss als später eine gut ausgearbeitete Fassung präsentieren zu können. Wie der AI Act kommt, werden wir dann im nächsten Jahr sehen.

Das alles war aber nicht das, was dieses Jahr in meinen Augen besonders gemacht hat. Es ist etwas anderes: die neue Rolle von Open Source.

Neue Hürden für Technologie?

Anfang des Jahres sah es so aus, als setzt eine besondere Kommerzialisierung in der Technikwelt ein: die Kommerzialisierung von Basistechnologie. Über die verschiedenen Jahre haben wir gesehen, dass es für verschiedene Produkte in der IT proprietäre und freie Lösungen gibt. Zwar sind erstere gerne technologisch mitunter überlegen, da die Profitorientierung Anreize setzt, für bestimmte Anwendungszwecke besonders passende Lösungen zu entwickeln. Kostet eine Software Geld, kann der Hersteller Programmierer anstellen, die auch die Features entwickeln, die man ungern freiwillig programmiert. Auf diese Weise entstehen runde Produkte für einen Anwendungszweck.

Freie bzw. zumindest quelloffene Software ermöglicht zumindest aber der Öffentlichkeit, einen Blick in die Funktionsweise zu werfen, um zu sehen, wie etwas funktioniert. Das ist die Grundlage, um Technologie zu verbessern.

In der Welt des maschinellen Lernens entstand allerdings durch die benötigte Compute Power eine hohe Eintrittshürde. Es sah so aus, als wären die Large Language Models nur noch großen Konzernen bzw. gut finanzierten Start-ups vorbehalten, die sich die Trainingspower leisten können. Während die Vorgängersysteme wie GPT-2 noch öffentlich zugänglich waren, wurden gerade Systeme wie GPT-3 und GPT-4, bei denen das Produkt endlich richtig nutzbar wurde, zurückgehalten.

Im Laufe des Frühlings habe ich allerdings vermutet, dass freie Modelle die proprietären outperformen können, weil die öffentliche Zugänglichkeit die Chance eröffnet, dass Experten weltweit mit ihren eigenen Erfahrungen, Eindrücken und ihrem Domänenwissen eine Technologie entwickeln können, die verschlossenen Produkten überlegen ist.

Überraschend war, dass es gerade das AI-Team von Facebook war, das den Stein mit LLaMA ins Rollen gebracht hat. Es folgten zahlreiche weitere Abkömmlinge, Weiterentwicklungen oder gänzliche Alternativansätze, die eines gemein hatten: ihr Kern mit den Gewichten war zugänglich.

Wie es aussieht, könnte die Dominanz proprietärer Systeme gebrochen werden, sodass auch die Möglichkeit gewahrt bleibt, einen wissenschaftlichen Diskurs zu führen. Technische Berichte proprietärer Modelle sind zwar nett, aber die Forschungsarbeiten, in denen reproduzierbare Fortschritte aufgezeigt werden, bringen uns tatsächlich eher voran.

Um die rasante Entwicklung im Frühling, als scheinbar jedes KI-Team großer Konzerne und Forschungseinrichtungen alle in der Schublade angesammelten LLM-Projekte zu veröffentlichen versuchte, im Auge zu behalten, habe ich die LLM-Timeline entwickelt. Sie wurde vor einigen Tagen wieder aktualisiert und zeigt besonders, wie sehr LLaMA als eines der ersten praktisch verwertbaren Modelle mit offenen Gewichten die Entwicklung beeinflusst hat.

Ein weiteres Projekt, das ich in der Zusammenarbeit mit der Fachhochschule Kiel realisiert habe, war der Podcast KI & Kultur, der generative Modelle aus der Perspektive Kulturschaffender beleuchtet hat.

Was bleibt

Das Jahr hat den 70 Jahre alten Begriff der KI wieder mal in die Massen gebracht. Dabei wird ChatGPT dem Begriff eigentlich gar nicht gerecht, weil es streng genommen relativ dumm ist. Insbesondere beschränkt es die Zustandsfähigkeit nur auf eine Prompt und lernt nicht, während es denkt. Training und Inferenz sind entkoppelt.

Und trotzdem ist es diese natürlichsprachliche Schnittstelle, die es so faszinierend macht. Allerdings ist auch diese Erkenntnis nicht neu und wurde schon vor 55 Jahren mit ELIZA diskutiert.

Erfreulich ist es, dass "Open Source" nicht mehr nur bei Software, sondern in neuen Technologien Anwendung findet. Der Gedanke, dass Technologie zugänglich sein muss, kann so erhalten werden. Und dass es hilft, wenn Wissenschaftler auf der ganzen Welt mit ihrem Wissen beitragen können, sehen wir weiterhin auch in dieser Thematik.

LLMs ermöglichen es, dass wir uns endlich wieder der Mensch-Maschine-Schnittstelle widmen können, die Technologie nutzbar macht. Menschen wollen, dass Technik das Leben einfacher macht. Die bisher begrenzte Rechenleistung hat uns zu Hilfsmitteln wie Displays, Touchscreens oder Tastaturen gezwungen. In den nächsten Jahren können wir schauen, wie wir das überwinden können, um endlich nutzbare Computer zu erhalten, die wirklich was bringen.

Und so ist es schon fast ironisch, dass die naheliegendste Technologie, die in den 2010er-Jahre euphorisch gefeiert wurde, von den LLMs noch wenig profitiert hat: Sprachassistenten. Sie sind überwiegend noch genau so begrenzt und unflexibel wie früher. Hier gibt es einiges zu tun.

Frohes Neues

Abschließend möchte ich meinen Lesern des Blogs und Zuhörern des Podcasts Risikozone sowie KI & Kultur danken, dass ihr den Blog lest, den Podcast hört und regelmäßig Feedback gebt. Ich wünsche euch einen guten Rutsch in das neue Jahr 2024.

Im nächsten Jahr werden wir wieder gemeinsam neue Technologien ergründen und die aktuellen Nachrichten diskutieren. Es wird auch mehr um Grundlagen und Visualisierungen gehen, hierauf freue ich mich schon besonders!

Viel Glück, Gesundheit und Erfolg!

Das Interessante an den Open-Source-Modellen ist ja, dass sie das umsetzen, was bei den proprietären Modellen gemunkelt wird, aber nicht nachgewiesen werden kann. Mein aktuelles Highlight: Mixture of Experts (MoE).

Im Sommer kamen Behauptungen auf, dass OpenAIs GPT-4 eigentlich aus acht kleineren Modellen besteht, die zusammengeschaltet werden. Dieses Verfahren nennt man auch Ensemble Learning.

Das klassische Beispiel dafür ist Random Forest, wo mehrere Decision Trees parallel zu so einem Ensemble zusammengeschaltet werden. Soll das Ensemble dann eine Klassifikation vornehmen, nimmt jeder Decision Tree mit seinen eigenen Gewichten die Klassifikation vor. Anschließend entscheidet die Mehrheit der Decision Trees im Ensemble, wie das Gesamtmodell nun klassifizieren soll. Analog würde auch eine Regression umgesetzt werden können, als Aggregierungsfunktion kommt dann statt Mehrheitswahl eben sowas wie Mittelwert o. ä. zum Einsatz. Das besondere ist, dass mit Random Forest üblicherweise bessere Vorhersagen erzielt werden können, als mit einem einfachen Decision Tree.

MoE funktioniert in den groben Zügen ähnlich. Es gibt "Experten" (ähnlich wie die Decision Trees bei Random Forest), die dann gewichtet aggregiert werden (Gating). Die Technik ist eigentlich recht alt und viele waren überrascht, dass OpenAI genau so etwas einsetzen soll.

Umso besser, dass Mistral als das europäische LLM-Startup sich der Sache angenommen hat. Anfang des Wochenendes schwirrte schon ein Torrent durchs Netz, heute gibt es dann auch eine offizielle Pressemitteilung zu Mixtral 8x7B. Hierbei handelt es sich um ein "Sparse Mixture of Experts"-Modell (SMoE). Die Gewichte sind wieder offen und unter der Apache 2.0 lizenziert.

Kurz zu den Eckdaten: 32k Token Kontextlänge können verarbeitet werden. Dabei spricht das Modell Englisch, Französisch, Italienisch, Deutsch und Spanisch und wurde auch auf Codegenerierung optimiert. Fine-tuning ist ebenfalls möglich - so wurde bereits eine instruction-following-Variante trainiert.

Im Vergleich zu Llama 2 70B soll es in einer Vielzahl von Benchmarks bessere Ergebnisse abliefern und dabei schneller arbeiten. Die einzelnen Ergebnisse können der Pressemitteilung entnommen werden.

Einen klassischen Downloadlink konnte ich auf die schnelle nicht finden, das Twitter-Profil verweist nur auf die Torrents. Parallel kündigt das Start-up an, einen eigenen Dienst für API-Endpoints anzubieten, sodass ein Deployment auf eigener Infrastruktur nicht mehr zwangsläufig notwendig ist.

Aktuell sollte beim Updaten des Linux-Kernels Vorsicht walten gelassen werden. Bestimmte Kernel-Releases weisen ein Problem mit ext4 auf, das theoretisch im schlimmsten Fall zu einer Datenbeschädigung führen kann.

Es gibt eine Konstellation, in der in einem Release nur der erste ohne den zweiten Commit enthalten ist und somit der Code nicht wie gewünscht arbeitet. Konkret geht es um

• 91562895f803: "ext4: properly sync file size update after O_SYNC direct IO" (ab v6.7-rc1)
• 936e114a245b6: "iomap: update ki_pos a little later in iomap_dio_complete" (ab v6.5-rc1)

Jan Karas E-Mail auf der LKML zufolge geht es darum, dass der erste Commit nur dann im Code vorhanden sein darf, wenn der zweite Commit bereits enthalten ist. Eigentlich ist das logisch, weil das ja mit der Reihenfolge dann auch so passt.

Jetzt kommen allerdings noch die Backports und Distributionen ins Spiel. Für den Kontext: da nicht jeder immer auf die neuste Linux-Version aktualisieren kann, gibt es ein Team, was alte Versionen nachpflegt und kleine, unkritische Fixes neuerer Versionen auf die älteren Versionen "rückportiert", also backported. Allerdings kann es nun passieren, dass etwas ganz neues rückportiert wird, ohne, dass eine ältere Voraussetzung rückportiert wurde. Die Fehler, die dann auftreten, nennt man klassicherweise eine Regression. Die einzelnen Codeänderungen sind da nicht an sich das Problem, sondern eher die Konstellation, in der sie zusammengesetzt wurden.

Linux 6.1.64 und 6.1.65 sind betroffen, 6.1.66 enthält den Fix. Debian 12, das auf die Kernels setzt, ist dabei besonders in Aufruhe, da eine problematische Kernel-Version verteilt wird. Aus diesem Grund wurde auch die Veröffentlichung von Debian 12.3 verzögert.

Weitere Informationen

• Ext4 data corruption in stable Kernels
• Debian-Bugreport 1057843

Kurz notiert: Nextcloud (Dateispeicher) und Roundcube (Webmail) gehen eine Partnerschaft ein. Wie heute das Nextcloud-Team in einer Blogmitteilung bekannt gab, wird Roundcube in die "Nextcloud family" aufgenommen. Dabei lässt sich die Kooperation in erster Linie strategisch verstehen, wird aber bereits kurzfristige Auswirkungen haben, da das Entwicklerteam des bekannten Webmail-Clients vergrößert werden kann.

Die wichtigste Information bei der Nachricht ist, dass Roundcube nach aktuellem Stand weiterhin als eigenes Produkt erhalten bleibt. Es handelt sich somit nicht um eine "Verschmelzung" bzw. "Übernahme" des Produkts.

Die Nachricht sendet allerdings ein positives Signal für produktiv eingesetzte Open-Source-Systeme aus: Nextcloud als ein in Unternehmensumgebungen weit verbreiter Cloud-Dienst (Dateispeicher, Kalender, etc.) ermöglicht anderen Büroprogrammen, sich weiterzuentwickeln und auf dem technisch aktuellen Stand zu bleiben. Dies meine ich dabei besonders im Sicherheitskontext. Zero-Days können immer auftreten, aber mit viel Entwicklungsressourcen kann die Wahrscheinlichkeit proaktiv gesenkt werden.

Nextcloud möchte somit auch einen attraktiven Gegenpol für klassische proprietäre Anwendungen aufbauen. Wir können also gespannt sein, was sich aus der Partnerschaft entwickelt.

Die gestrige Veröffentlichung von Linux 6.6 bedeutet, dass das Merge-Window wieder geöffnet ist. Ein erster Kandidat wurde bereits gemerged mit einem Vorhaben, das in den vergangenen Wochen zu vielen Diskussionen geführt hat: bcachefs.

Um bcachefs zu erklären, muss ich kurz ein wenig weiter ausholen. bcachefs geht - wie der Name schon vermuten lässt - auf bcache zurück. Hierbei handelt es sich um ein Kernelmodul, das Einzug in Linux 3.10 in 2013 fand und einen Caching-Layer für Block-Devices einführte.

Daten können somit hybrid zwischen ganz schnellem Speicher (RAM), schnellem Speicher (SSDs) und langsamem Speicher (HDD) aufgeteilt werden. Werden bestimmte Blöcke häufiger abgerufen, werden sie in den schnelleren Speicher verschoben und anders herum ebenso. Dabei handelte es sich aber immer um eine Zwischenschicht, auf der ein echtes Dateisystem aufbauen musste. Während der Entwicklung fiel dem Hauptentwickler Kent Overstreet jedoch schnell auf, dass zu einem "full-fledged" Filesystem nicht mehr viel fehlte.

Ein erster Prototyp entstand bereits im Jahre 2015 und hat somit die Ära der Dateisysteme der neusten Generation eingeläutet. Auch btrfs gehört zu diesen moderneren Dateisystemen und setzt auch auf das Copy-on-Write-Prinzip. Da die Blöcke einer Datei nicht bei einer Kopie dupliziert werden, spart dies Speicherplatz und ermöglicht verzögerungsfreie Snapshots.

bcachefs mit seinen über 90.000 Zeilen Code konnte zwar - wie für ein neues Dateisystem üblich und nötig - ausgiebig getestet werden, war allerdings bisher nicht im Mainline Linux vorhanden. Mitte des Jahres ging es dann an die Einarbeitung des Codes.

Eigentlich sollte bcachefs schon in Linux 6.5 Einzug halten. Aber aufgrund andauernder Spannungen wurde auch bei Linux 6.6 aus dem Vorhaben nichts. Eines der Probleme sind die teils umfangreichen Änderungen in fremden Modulen, die den Unmut der Maintainer auf sich gezogen haben. Wer sich dafür interessiert, kann sich den großen E-Mail-Thread ansehen. Linus Torvalds stand grundsätzlich einer Übernahme positiv gegenüber, wollte aber noch einen Test in linux-next abwarten. Dies ist zwischenzeitlich geschehen.

Nun also der Merge in den Kernel. Sollten sich die Änderungen bis zum Release halten, steht somit dem Einsatz des neuen Dateisystems ab der Veröffentlichung von Linux 6.7 nicht mehr viel im Wege. Die Aufnahme in Mainline vereinfacht aber auch die Entwicklung, da diese nun nicht mehr Out-of-Tree stattfindet, was aufgrund der hohen Änderungsgeschwindigkeit im Linux-Source-Tree schnell zu aufwändigen Anpassungsarbeiten führen kann.

Weitere Informationen zu bcachefs sind auf der eigenen Homepage abrufbar. Hier ist auch eine Schnellstartanleitung für den eigenen Einsatz zu finden.

Weitere Quellen

• Larabel: Bcachefs Merged Into The Linux 6.7 Kernel (31.10.2023)
• Larabel: Bcachefs Looks Like It Won't Make It For Linux 6.6 (08.09.2023)
• Larabel: Linus Torvalds Comments On Bcachefs Prospects For Linux 6.6 (06.09.2023)
• Thommes: Dateisystem Bcachefs für Linux 6.7 vorgesehen (31.10.2023)

Wer Exim4 als Mailserver einsetzt, wie es zum Beispiel in Debian-basierten Linux-Distributionen der Standard ist, sollte sich zeitnah um Updates bemühen oder - wenn der Dienst nicht zwangsläufig benötigt ist (bei manchen läuft Exim unbewusst) - spätestens jetzt gänzlich abschalten. Es gibt zumindest eine schwere Remote-Code-Execution-Sicherheitslücke.

Bleeping Computer berichtete über die Lücke(n), denn es geht um bis zu 6 Schwachstellen unterschiedlicher Stärke. Die genauen Details sind zum aktuellen Zeitpunkt noch nicht verfügbar, um Exploits nicht zu befördern. Es reicht allerdings unauthentifizierter Zugriff auf Port 25.

Der Fund geht auf die Zero Day Initiative von Trend Micro zurück. Sie hatte bereits im Juni letzten Jahres, also 2022, auf die Lücken aufmerksam gemacht. Besonders pikant: bis vor kurzem waren noch keine Patches verfügbar, zumal die schwerwiegende Lücke ZDI-23-1469 bereits Mitte der Woche veröffentlicht wurde.

Laut einer E-Mail der Entwickler ist ein bedeutenden Teil der Lücken bereits geschlossen und die Updates an die Distributoren verteilt. Dass die Lücke nicht schneller gefixt wurde, lag an Schwierigkeiten bei der Kommunikation. Bei Ubuntu wird die Lücke als CVE-2023-42115 geführt, hier sind noch keine Updates verfügbar.

Exim4-Admins sollten dies im Auge behalten und sofort reagieren. Mit ersten Exploits ist demnächst zu rechnen, wenn mehr über die Lücke bekannt wird. Der Mailserver ist weit verbreitet, es gibt laut Bleeping Computer mehrere Millionen Instanzen im Internet.

Das Wettrennen um die Technologieführerschaft der Large Language Models lief größtenteils bisher auf dem amerikanischen Kontinent ab. OpenAI hat das Produkt populär gemacht und Meta AI veröffentlicht den Konkurrenten mit den freien Gewichten. Mit Falcon 40B und 180B gab es allerdings schon Konkurrenz aus Abu Dhabi, zumal mit der gewählten Apache-2.0-Lizenz ein deutlich offenerer Ansatz gewählt wurde.

Als kurz vor dem Sommer das Start-up Mistral aus Paris 105 Millionen Euro eingesammelt hat, waren die Medienberichte zumindest leicht kritisch, da nicht nur das Start-up mit einer gigantischen Finanzierungssumme aus der Taufe gehoben wurde, sondern das Produkt auch noch gar nicht fertig war. Aus der LLM-Sicht ist dies allerdings verständlich, da solche großen Summen schlicht die Voraussetzung sind, um an den Start zu gehen. Schließlich benötigt Training leistungsfähige GPUs und die sind teuer.

Mit dem veröffentlichten Modell Mistral 7B zeigt das Start-up, was es kann. Dabei handelt es sich um ein LLM, das über 7 Mrd. Parameter verfügt und Llama 2 13B in allen und LLaMa 34B in vielen üblichen Benchmarks überbietet: Commonsense Reasoning, World Knowledge, Reading Comprehension, Math, Code, Popular aggregated results. In Codingaufgaben kann die Leistung von CodeLlama 7B erreicht werden.

Das Beste am LLM ist, dass es unter der Apache-2.0-Lizenz steht. Als klassische Open-Source-Lizenz gibt es nicht nur den Forschern und Entwicklern viele Freiheiten, sondern auch eine gewisse Lizenzsicherheit, dass das Modell in freier Software verwendet werden kann.

Ich hatte bereits vor Wochen geschrieben, dass freie Modelle eine gute Möglichkeit sind, um sich als neuer Player auf dem Markt zu profilieren. Diesen Plan verfolgt nicht nur Falcon, sondern nun auch offenbar Mistral. Es ist trotzdem davon auszugehen, dass die 105 Millionen Euro keine "Forschungsspende" waren und kommerzielle Produkte zeitnah folgen werden.

Für die Forscher und Entwickler von LLMs hat die aktuelle Veröffentlichung nichtsdestotrotz Vorteile. Meta AI hat mit der Lizenzgebung von Llama 2 auf die Open-Source-Bewegung in der LLM-Welt reagiert und sein aktuelles Modell unter eine permissive, aber trotzdem proprietäre Lizenz gestellt. Mistral geht allerdings noch einen Schritt weiter und setzt eine "klassische" Open-Source-Lizenz ein. Das hat nicht nur Signalwirkung, sondern ermöglicht, dass Unternehmen ihre LLM-Lösungen zunehmend privat hosten können, da die Parameteranzahl mit 7 Mrd. so dimensioniert ist, dass auch kleinere Datacenter-GPUs für die Ausführung bzw. Inferenz ausreichen. Es bleibt also weiterhin spannend im Umfeld der LLMs.

Die Mistral-7B-Modelle sind in Version 0.1 auf HuggingFace als normales Modell und als auf Chats spezialisiertes Modell (Instruct) verfügbar.

30 Jahre Debian - 30 Jahre felsenfeste Entwicklung und noch kein Ende in Sicht.

An diesem Tag vor 30 Jahren, am 16.08.1993, erschien in der Newsgroup comp.os.linux.development eine Ankündigung, die den Anfang eines der größten und langlebigsten Projekte im Linux-Ökosystem markieren sollte. Lasst uns für einen kurzen Moment zurückblicken.

Es ist nicht nur ein gepimptes SLS, es ist das "Debian Linux Release". Ian Murdock, der selbst mit der vermutlich ersten Linux-Distribution unzufrieden war und beschlossen hat, die Sache selbst in die Hand zu nehmen, hätte sich womöglich nie erträumen können, dass sein "brand-new Linux release", wie er es damals nannte, irgendwann seinen 30. Geburtstag feiern würde.

Begründer eines Distributionszweiges

Im Laufe der Jahre hat Debian bewiesen, dass es mehr als nur ein übereifriger Rebell unter den Betriebssystemen ist. Es hat die Grundlage für viele andere Distributionen wie z. B. Ubuntu gelegt. Es hat die Freiheit und Offenheit verkörpert, die das Herzstück der Open-Source-Bewegung bilden. Es hat glaubhafte Alternativen zu proprietären Betriebssystemen aufgezeigt und Zweifler zum Schweigen gebracht. Auch, wenn der letzte Punkt in der öffentlichen Diskussion nicht ganz offensichtlich ist, sprechen die Zahlen für sich: Debian ist ein fester Bestandteil vieler produktiver Serversetups.

Mit der tief verwurzelten Philosophie, die sich im Debian-Gesellschaftsvertrag widerspiegelt, unterstreicht das Projekt seine kompromisslose Haltung zugunsten freier Software, auch wenn über die Jahre insgesamt eine gewisse Toleranz gegenüber nachinstallierbarer unfreier Software Einzug gehalten hat.

Debian ist heute wichtiger denn je, da die Distribution den Test of Time bestand und sich zu einer Alternative zu Enterprise-Distributionen gemausert hat. Stabilität und Kontinuität sind entscheidende Faktoren, denn Debian baut auf klassischen Releases auf, von denen - je nach Zählweise - bereits 20 erschienen sind. Die Release werden seit Version 1.1 nach Toy-Story-Charakteren bezeichnet. Debian ist ein Leuchtturm, ein einsamer Fels in der Brandung einer Welt, die zunehmend von Anbietern dominiert wird, welche Daten und Freiheiten der Nutzer nicht beachten und sie an ihre Plattformen binden.

In diesem Sinne, lasst uns auf 30 Jahre technologischer Alternativen anstoßen. Herzlichen Glückwunsch, Debian! Auf 30 weitere Jahre der Innovation und Unabhängigkeit.

Open-Source-Software nachhaltig zu entwickeln, wird immer schwieriger. Willkommen im Zeitalter von "Nur schauen, nicht anfassen" für kommerzielle Rivalen.

Das in San Francisco ansässige Softwareunternehmen HashiCorp, bekannt für seine Cloud-Tools wie Terraform, Vagrant oder Vault, ändert seine Lizenzbedingungen. In einer Ankündigung wird der Wechsel von der Mozilla Public License 2.0 zur Business Source License mit der Gewährleistung kontinuerlicher Investitionen des Unternehmens in seine Community begründet.

HashiCorp hält weiterhin daran fest, seinen Quellcode frei verfügbar zu machen. Allerdings gibt die BSL dem Unternehmen mehr Kontrolle darüber, wer den Code kommerziell nutzen darf. Mit anderen Worten, wer Software von HashiCorp produktiv nutzt und sie für ein Konkurrenzprodukt einsetzen möchte, ist von nun an nicht nur bösen Blicken, sondern auch rechtlichen Hürden ausgesetzt.

In guter Gesellschaft

Einige Unternehmen haben diesen Schritt bereits vollzogen und sind auf unfreie Lizenzmodelle umgestiegen. Couchbase, Sentry und MariaDB MaxScale sind einige Beispiele dafür. Dies wirft natürlich die Frage auf, ob wir uns von der Idee freier Open-Source-Software verabschieden müssen. Die Omnipräsenz der Cloud-Industrie, die seit den 2010er-Jahren sich großer Beliebtheit erfreut, droht ernsthaft, die FOSS-Welt zu destabilisieren.

Stellt dir vor, du hast einen reichen Obstgarten erschaffen, in dem jeder sich frei der Früchte bedienen kann. Größzügig lädst du alle ein, sich nach Belieben zu bedienen und empfiehlst ihnen, selber Bäume zu pflanzen oder die Saaten weiterzuverbreiten. Eines Tages bemerkt ihr jedoch, dass einige Gäste die Früchte einsacken, sie auf eigenen Märkten verkaufen und die Profite einsacken, ohne selbst an die Ursprungscommunity etwas zurückzugegeben. Klingt unfair? Genau das passiert momentan in der Open-Source-Welt.

Damit wird Open Source zwar nicht von Tisch gewischt, sondern in eine Richtung gelenkt, die den freien ungehinderten Austausch unabhängig von gewerblichen Interessen einschränkt. Konkret wackelt dabei das 6. Kriterium der Open-Source-Definition (OSD), das eine Unterscheidung nach Einsatzfeldern ausschließt.

HashiCorp betont, dass es sich weiterhin seiner Community, seinen Partnern und Kunden verpflichtet sieht. Nur die Zeit wird zeigen, ob diese Lizenzänderungen die richtigen Schritte auf dem Weg dorthin sind. Einerseits werden Möglichkeiten von Forks eingeschränkt, andererseits ist niemandem geholfen, wenn die Weiterentwicklung durch HashiCorp auf dem Spiel steht, nur, weil externe Akteure bezogen auf die Einnahmen sinnbildlich das Wasser abgraben. Die Leute, die Software entwickeln, müssen auch von etwas bezahlt werden.

Edit (20:25 Uhr): MariaDB setzt die BSL für MaxScale ein, nicht jedoch für die Datenbank MariaDB Server. Danke für den Hinweis, Jens.

Update (20:30 Uhr): Ggfs. werde ich mich mit der BSL noch einmal in einem gesonderten Artikel beschäftigen, aber ein kleines Detail ist hierbei vllt. noch erwähnenswert, um den Blick auf die Sache zu ändern. Die von HashiCorp verwendete Form der BSL setzt auf eine Art Embargozeit. Nach 4 Jahren der Veröffentlichung eines nach BSL lizenzierten Werkes in einer spezifischen Version, greift folgender Passus:

Effective on the Change Date, or the fourth anniversary of the first publicly available distribution of a specific version of the Licensed Work under this License, whichever comes first, the Licensor hereby grants you rights under the terms of the Change License, and the rights granted in the paragraph above terminate.

Als Change License wurde die MPL 2.0 festgelegt.

Auch in der Sommerpause gibt es vereinzelte Neuigkeiten aus der Welt der künstlichen Intelligenz. Heute möchte ich mich dabei wieder einmal den Agenten widmen.

MetaGPT

Beim Einsatz von ChatGPT und ähnlichen LLMs stellt sich schnell die Frage, ob da nicht auch mehr geht. Ob das System nicht zur Abbildung alltäglicher Arbeit herangezogen werden kann. Insbesondere mit Anfang des Jahres aus dem Winterschlaf erwachten Konzept der Agenten wurde die Zusammenarbeit unterschiedlicher KI-Instanzen wieder relevant und spannend. Umso interessanter ist es, diese Konzepte zusammenzuführen.

AutoGPT und Co. sind diesem Ziel gefolgt und konnten schon lustige Ergebnisse demonstrieren, wenn man die LLMs sinnbildlich an den eigenen Computer anschließt und z. B. die Ausgaben des LLMs als Eingabe für die eigene Shell verwendet (nicht nachmachen, ist eine dumme Idee). Doch auch hier gab es einige Schwächen, ganz rund lief alles bei weitem noch nicht.

Die Autoren hinter MetaGPT (hier im Bezug auf griechisch meta = über) haben systematisch verschiedene Rollen inkl. ihrer Interaktionen ausgearbeitet und stellen ihre Ergebnisse als Preprint und ihr Framework auf GitHub bereit. Dabei wird eine einzeilige Aufgabe, z. B. die Entwicklung eines Spiels, vom System eingelesen und dann auf ein hierarchisches Team aus Agenten verteilt. Diese Agenten haben verschiedene Rollen, die sich auf die System-Prompts abbilden, d. h. beispielhaft "Du bist ein Entwickler für Python..." oder "Du bist ein Requirements-Engineer...". Am Ende des Tages fällt ein Ergebnis raus, das dann ausprobiert werden kann.

Das Konzept sieht in meinen Augen sehr spannend aus und entwickelt sich stets weiter. Dabei wird deutlich, dass eine simple Prompt für hochwertiges Prompt-Engineering nicht reicht, vielmehr können Effekte ähnlich wie beim Ensemble-Learning genutzt werden, durch die mehrere Instanzen von LLMs, die gemeinsam ein Problem bearbeiten, deutlich effektiver arbeiten.

Was LLMs von Cyc lernen können

Irgendwie habe ich die ganzen letzten Monate schon darauf gewartet, dass sich die Autoren klassischer Expertensysteme beim LLM-Thema zu Wort melden. Immerhin prallen hier zwei komplett unterschiedliche Welten aufeinander, die beide versuchen, die Welt zu erklären.

Klassische Expertensysteme versuchen mit Logik die Welt in Regeln zu fassen. Das typische Beispiel ist "Wenn es regnet, dann wird die Straße nass". Eine klare Implikation, die in eine Richtung geht: ist das Kriterium auf der "wenn"-Seite erfüllt, gilt die Aussage auf der "dann"-Seite. Wird das System gefragt, was mit der Straße passiert, wenn es regnet, antwortet es immer, dass sie nass wird. Immer. Dass es nicht zwangsläufig der Regen sein muss, wenn die Straße nass ist, wird ebenfalls durch Logik ermöglicht, da die obige Regel eine Implikation ist und keine Äquivalenz, denn da würde es heißen "Immer wenn es regnet, dann wird die Straße nass".

Problematischer wird es zu modellieren, dass die Straße selbst bei Regen da nicht nass wird, wo gerade ein Auto parkt. Hieran erkennt man, dass es sich um ein schwieriges Unterfangen handelt, wenn Expertensysteme die echte Welt modellieren sollen. Das Cyc-Projekt hat die Mühe aber auf sich genommen und über die letzten knapp 40 Jahre über eine Million solcher Regeln zusammengetragen. Viele einfache Expertensysteme gelten grundsätzlich aber als veraltet und konnten die Erwartungen für "generelle Intelligenz" schon vor 30 Jahren nicht erfüllen.

Anders funktionieren LLMs, die nicht mit klassischer Logik, sondern Wahrscheinlichkeiten arbeiten, um das "am ehesten passende" nächste Wort für die Antwort zu finden. Zusammengefasst sind Expertensysteme für ihre Präzision zulasten der Vielseitigkeit bekannt und LLMs einfach anders herum.

Doug Lenat von Cyc und Gary Marcus von der NYU haben in ihrem Preprint nun 16 Anforderungen zusammengetragen, die eine "vertrauenswürdige KI" haben sollte, darunter Erklärung, Herleitung oder Kontext. Anschließend gehen die Autoren noch ein, wie ihr (kommerzielles) Cyc das umsetzen kann.

Ich bin tatsächlich überzeugt, dass man untersuchen sollte, wie sich diese beiden Ansätze verheiraten lassen. Dabei sprechen auch die Ergebnisse von AutoGPT, MetaGPT & Co. dafür, dass das Vorhaben auf neuronaler Ebene angegangen werden muss, da einfache Varianten wie System-Prompts á la "Du bist LogikGPT. Gib mir die Entscheidungsregeln in Prädikatenlogik aus." immer noch auf Token-/Wortvorhersagen basieren und zu viel Halluzination zulassen.

Dennoch bin ich sicher, dass es auch hier Fortschritte geben wird, die wir dann früher oder später in einem Wochenrückblick diskutieren können. Bis dahin!

In der heutigen Ausgabe des Wochenrückblicks blicken wir auf ein neues Modell von IBM und einen Ausblick auf neue Features in der ChatGPT-Oberfläche von OpenAI.

IBM und NASA veröffentlichen Foundation-Model für Geodaten

Wie ich an der einen und anderen Stelle im Wochenrückblick schon einmal erwähnt habe, beschränkt sich die Transformer-Architektur mittlerweile nicht mehr nur auf Textaufgaben. Mit Vision Transformers lässt sich dies auch auf die grafische Ebene erweitern.

In einer Kooperation zwischen IBM und der NASA wurden nun die Prithvi-Modelle auf Hugging Face veröffentlicht. Sie ermöglichen es, ein Satellitenbild einzugeben und z. B. vorhersagen zu lassen, welche Gebiete am ehesten Fluten ausgesetzt sein könnten.

Um diese Vorhersagen zu ermöglichen, hat IBM Daten aus dem Harmonized Landsat Sentinel-2-Projekt (HLS) herangezogen, um ein Foundation Modell zu trainieren. Im HLS-Datensatz befinden Satellitendaten, die mit je 30 Metern pro Pixel aufgelöst sind. Auf der technischen Seite wird ein Vision Transformer mit Masked Autoencoder eingesetzt. Das Foundation Modell kann nun von weiteren Forschern feingetuned werden, um die jeweiligen Vorhersagen weiter zu verbessern. Durch IBMs Arbeit sollen nun mehr als 250.000 TB an Missionsdaten von der NASA besser zugänglich gemacht werden. Weitere Details zum Projekt können im Blogartikel und in der Pressemitteilung von IBM abgerufen werden.

Neue ChatGPT-Features

Wie SimilarWeb schon vor wenigen Wochen beobachten konnte, ebbt der Hype um ChatGPT langsam ab. Auffällig beim Release von ChatGPT war auch, wie puristisch die ganze Oberfläche war. Dabei ist es vermutlich das Backend, was OpenAI gemeistert hat, denn sie haben es geschafft, das System in den ersten Wochen unter ziemlich hoher Last aufrecht zu erhalten.

Im Frontend wurden aber zwischenzeitlich auch Änderungen und Verbesserungen umgesetzt, insbesondere die Einführung des kostenpflichtigen Dienstes ChatGPT Plus hat einige Anpassungen erfordert. Logan Kilpatrick, zuständig für "Developer Relations" bei OpenAI, gab nun einen Ausblick, was demnächst zu erwarten ist.

So wird es unter anderem vorgeschlagene Einstiegs- und Folgefragen und die Möglichkeit des Uploads mehrerer Dateien im Code Interpreter geben. Zudem soll die Zwangsabmeldung nach 14 Tagen abgeschafft werden.

Während ein Teil der Änderungen hilfreiche Detailverbesserungen beisteuert, werden die "vorgeschlagenen Folgefragen" am lustigsten sein. Nun schreibt also ChatGPT nicht nur die Antworten, sondern auch die Fragen. Es bleibt spannend.

In diesem Wochenrückblick kann ich euch wieder drei spannende Nachrichten präsentieren, die abbilden, was in den letzten Tagen besondere Aufmerksamkeit in der AI-Community erhalten hat.

SDXL 1.0 erschienen

Wie in fast jeder Woche kann ich euch auch dieses Mal wieder von einem neuen Modell berichten. Das Team rund um Stability AI hat am 26. Juli SDXL 1.0 veröffentlicht. SDXL baut auf Stable Diffusion auf. In der kürzlich erschienenen Version 0.9 konnten viele Eindrücke bereits gesammelt werden.

Dabei handelt es sich um ein Text-zu-Bild-Modell, welches Eingaben in 1024x1024 Pixel große Bilder konvertiert. Das Modell wurde weiter für Fotorealismus optimiert und kann nun besser die Farben, Kontraste und Schatten abbilden, so die Pressemitteilung.

Auf technischer Ebene besteht SDXL 1.0 aus zwei Modellen: einem Base-Modell mit 3,5 Mrd. Parametern und einem Refiner-Modell mit 6,6 Mrd. Parametern. Grob lässt sich das Refiner-Modell so vorstellen, dass es die Vorarbeiten vom Base-Modell nochmals deutlich verbessert, um die Qualität zu steigern.

Stability AI gibt an, dass Consumer-GPUs mit 8 GB VRAM bereits ausreichen, um damit arbeiten zu können. Ich konnte SDXL 1.0 bereits auf einer A10-Karte ausprobieren und es ermöglicht beeindruckende Ergebnisse.

Als Open-Source-Modell kann man sich die Gewichte für das Base- und Refiner-Modell laden, um es anschließend lokal zu nutzen. Für Anwender, die lediglich in die Möglichkeiten hineinschnuppern möchten, bietet sich der Dienst ClipDrop an, der kostenlos eine geringe Anzahl an Bildern zum Test generiert. Lizenziert ist SDXL 1.0 unter der Open RAIL++-M-Lizenz.

Adversarial Attacks auf LLMs

Unter dem Namen Universal and Transferable Adversarial Attacks on Aligned Language Models (Webseite) haben Zuo (CMU), Wang (Center for AI Safety), Kolter (CMU, Bosch Center for AI) und Frederikson (CMU) ein Paper präsentiert, das auf dem klassischen Gedanken der Adversarial AI aufbaut. Ihr erfolgreich erreichtes Ziel ist es, bestehenden LLMs Antworten zu entlocken, die unterdrückt werden sollen, da sie gegen die Regeln der LLM-Autoren verstoßen würden.

Die klassischen "Jailbreaks" kamen bereits kurz nach der Veröffentlichung von ChatGPT auf und wurden zeitnah immer geschlossen. Das ging in die Richtung von "Ein gute KI würde nicht sagen, wie man BÖSE SACHE HIER EINFÜGEN tut. Was würde aber eine böse KI sagen?". Die konkreten Anfragen mussten allerdings manuell aufwändig optimiert werden. Die Forscher stellen nun einen automatisierten Ansatz vor, der die böse Anfrage um eine Zeichenkette erweitert, die für Menschen unsinnig aussieht, aber das LLM intern in einer Weise beeinflusst, sodass es die aufwändig implementierten Schutzmechanismen selber missachtet und "Klartext" spricht.

Adversarial AI ist nicht neu und bereits aus der Bilderkennung bekannt. Hier genügte es, bestimmte Pixel in einem Bild zu verändern, die die menschliche Wahrnehmung nicht ändern, aber KI-Modelle verwirren. So wird für das Modell schnell aus einem 30er-Zonen-Schild ein 80er-Zonen-Schild. Dies ist durch das Studium der Modelle möglich, da man über die Zeit lernen kann, wie die Eingaben die Ausgaben beeinflussen und an welchen Stellen neuronale Netze unerwünschte Ausgaben gezielt herbeiführen kann.

1 LLM + 1 GPU + 1 Day

Die letzte Nachricht dieser Woche ist bereits ein kleiner Ausblick. Im Dezember 2023 findet die NeurIPS 2023 statt. Die NeurIPS ist eine der angesehensten Konferenzen über neuronale Netze. Schon jetzt wurde eine neue Challenge veröffentlicht, an der man bis voraussichtlich Oktober 2023 noch teilnehmen kann.

Bei der LLM Model Effiency Challenge ist das Ziel, ein bestehendes Foundation Model innerhalb eines Tages auf einer GPU, wahlweise einer 4090 oder A100 (40 GB), für ein bestimmtes Aufgabengebiet finezutunen. Dabei gelten bestimmte Regeln, welche Foundation Models z. B. verwendet werden dürfen. Darunter sind Falcon, MPT, Llama 2, BART oder T5 enthalten.

Das Ziel der Challenge ist es, die Transparenz in der Forschung der LLMs zu verbessern, da u.a. bisher ein besonders hoher Ressourcenaufwand nötig war, um das Training erfolgreich umzusetzen. Diese Challenges dienen auch, innovative Ansätze zu fördern, da durch die künstlichen Beschränkungen die Teilnehmer angehalten werden, Wege zu finden, eben 1 LLM mit 1 GPU innerhalb 1 Tages zu trainieren. Die Besten der Besten lassen sich auf einem Leaderboard tracken, um zu sehen, wer den "Highscore" knackt. Die beiden besten Teams dürfen dann auf der NeurIPS jeweils einen 30-minütigen Talk halten.

Es bleibt also weiterhin spannend. Blicken wir auch in eine neue Woche mit spannenden Neuerungen und Entwicklungen!