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 …

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 …

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 …

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 …

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 …

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 …

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 …

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 …

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 …