Connect with us

Entwicklung & Code

Aus Softwarefehlern lernen – Teil 6: Eine Zeile Code mit fatalen Auswirkungen


In der Softwareentwicklung gibt es Bereiche, in denen schon ein einziger Fehler katastrophale Folgen haben kann. Besonders anfällig sind dabei Kryptografiebibliotheken und Parser – also genau jene Bausteine, die Daten validieren, entschlüsseln oder die Integrität von Kommunikation sicherstellen.

Weiterlesen nach der Anzeige


Golo Roden

Golo Roden

Golo Roden ist Gründer und CTO von the native web GmbH. Er beschäftigt sich mit der Konzeption und Entwicklung von Web- und Cloud-Anwendungen sowie -APIs, mit einem Schwerpunkt auf Event-getriebenen und Service-basierten verteilten Architekturen. Sein Leitsatz lautet, dass Softwareentwicklung kein Selbstzweck ist, sondern immer einer zugrundeliegenden Fachlichkeit folgen muss.

Die Teile der Serie „Aus Softwarefehlern lernen“:

In diesen Bereichen gilt: Ein vermeintlich kleiner Bug kann globale Auswirkungen haben. Zwei der bekanntesten Vorfälle der letzten Jahre illustrieren das eindrücklich, nämlich Heartbleed und Apples „goto fail“.

Muster 6: Kryptografie- und Parser-Fehler: Wenn eine einzige Codezeile die Sicherheit kippt

Heartbleed war ein Fehler in OpenSSL, einer der meistgenutzten Kryptografiebibliotheken der Welt. Der Bug betraf die Implementierung des TLS-Heartbeat-Mechanismus. Heartbeats sind kleine Nachrichten, mit denen Client und Server prüfen, ob die Verbindung noch lebt. Ein Client sendet (im Falle von TLS) dazu eine Nachricht, in der er unter anderem die Länge der eigenen Daten angibt. Der Server spiegelt diese Daten zurück.

Der fatale Fehler dabei war, dass die angegebene Länge nicht validiert wurde. Ein Angreifer konnte also behaupten, er sende zum Beispiel 64 KByte Daten, sendete tatsächlich aber nur 1 Byte. OpenSSL las daraufhin blind die fehlenden 63.999 Bytes aus seinem Speicher und schickte sie zurück. Diese Out-of-Bounds-Reads erlaubten es, mit ein bisschen Glück sensible Informationen wie Passwörter, Session Keys oder private Schlüssel auszulesen.

Die Tragweite war enorm. Millionen von Webservern waren betroffen, und weil TLS-Private-Keys kompromittiert waren, mussten die Betreiber zahllose Zertifikate austauschen. Der Bug bestand dabei über zwei Jahre in der OpenSSL-Codebasis, obwohl er nur wenige Zeilen lang war.

Fast zeitgleich machte Apple mit einem ebenfalls winzigen, aber folgenschweren Fehler namens goto fail Schlagzeilen. In der Implementierung der SSL-Zertifikatsprüfung in iOS und macOS fand sich eine verdoppelte Codezeile:

Weiterlesen nach der Anzeige


if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
    goto fail;
    goto fail;


Die zweite goto fail-Zeile war dabei falsch eingerückt, sodass Reviewer den Fehler schlecht erkennen konnten. Das System führte die zweite Zeile nämlich immer aus, unabhängig vom Ergebnis der if-Anweisung. Das wiederum hatte zur Folge, dass das System einen Teil der sicherheitskritischen Zertifikatsprüfung übersprang. Dadurch konnte ein Angreifer einen Man-in-the-Middle-Angriff durchführen, weil macOS, iOS und andere Apple-Betriebssysteme gefälschte Zertifikate akzeptierten. Wie bei Heartbleed war der betroffene Code winzig, die Folgen jedoch massiv.

Was haben beide Fehler gemein? Sicherheitskritischer Code ist oft alt und wenig verändert: Entwicklerinnen und Entwickler fassen Parser, Krypto-Routinen oder Protokollimplementierungen selten an – und wenn, dann oft unter Zeitdruck.

  1. Einzelne Zeilen können sicherheitsentscheidend sein: Die Logik ist komplex, Tests decken selten alle Pfade ab, und Compiler warnen nicht vor falscher Einrückung oder fehlender Längenvalidierung.
  2. Fehler bleiben lange unentdeckt: Heartbleed war über zwei Jahre im Code. goto fail fiel erst auf, als unabhängige Forscher den Code analysierten.

Wer sicherheitskritische Software entwickelt oder integriert, sollte daher einige Prinzipien beherzigen:

  1. Vier-Augen-Prinzip und Code-Reviews: Kein sicherheitsrelevanter Commit sollte von nur einer Person geschrieben und gemerged werden.
  2. Fuzzing und Differential-Tests: Automatisierte Tests, die zufällige und manipulierte Eingaben erzeugen, decken viele Parser- und Memory-Bugs auf.
  3. Reproduzierbare Builds und Dependency-Audits: Developer müssen sicherheitskritische Software in derselben Version reproduzierbar bauen und signieren. Änderungen in Libraries müssen sie aktiv verfolgen und bewerten.
  4. Minimaler und isolierter Code: Krypto- und Parser-Funktionen sollten möglichst klein und möglichst isoliert sein, um die Angriffsfläche zu minimieren.
  5. Proaktive Schlüssel- und Zertifikatsrotation: Selbst wenn ein Fehler wie Heartbleed auftritt, kann ein schneller Schlüsselaustausch die Folgen begrenzen.

Die beiden Fälle zeigen: Security-Bugs entstehen oft in den unscheinbarsten Codezeilen. Wer sie ignoriert, riskiert nicht nur Ausfälle, sondern auch Vertrauensverlust und juristische Folgen. Für Unternehmen ist daher klar: Sicherheitskritische Bereiche benötigen besondere Prozesse, zusätzliche Tests und regelmäßige Audits.


(who)



Source link

Verwandte Themen:
Weiterlesen

Entwicklung & Code

Docker Inc. macht gehärtete Abbilder kostenlos verfügbar


Docker Inc. hat angekündigt, ein bisher kostenpflichtiges Produkt fortan kostenlos anzubieten: Docker Hardened Images (DHI). Der Erfinder der Software Docker und Betreiber des Docker Hubs erklärt, damit auf Lieferkettenangriffe zu reagieren, die auch im Containerumfeld vorkommen. Die gehärteten Abbilder enthalten ein aufs absolut Nötige reduziertes Userland einer Distribution und unterscheiden sich dadurch von den sogenannten „Official Images“, die man ohne Login im Docker Hub (hub.docker.com) für viele Anwendungen findet.

Weiterlesen nach der Anzeige

Weniger Spuren der Distribution

Als Beispiel reicht ein Blick auf den Webserver Nginx und dessen Abbild: Im öffentlichen Hub gibt es Abbilder mit dem Namen nginx, die auf den Distributionen Alpine oder Debian aufbauen. Neben dem Webserver selbst stecken Teile der Distribution darin. Die meisten Komponenten sind für den Betrieb des Webservers gar nicht nötig und allenfalls hilfreich, wenn man mit Werkzeugen wie docker exec in einen Container springt und darin Fehler sucht. Über den eingebauten Paketmanager (apt oder apk) kann man beispielsweise einen Texteditor nachinstallieren und auf Fehlersuche im Container gehen. Solche Werkzeuge können aber auch zum Einfallstor für Angreifer werden.

Die gehärteten Abbilder enthalten weniger Spuren der Distribution und damit weniger Einfallstore – im Gegenzug aber auch keine Werkzeuge für die spontane Fehlersuche. Zum Vergleich: Das offizielle Nginx-Abbild auf Alpine-Basis (nginx:alpine) ist 21 MByte groß und kommt mit einer bekannten mittelschweren Sicherheitslücke, für die es einen CVE-Eintrag gibt. Die Debian-Variante (nginx:stable-bookworm) ist sogar 67 MByte groß, hat drei Lücken mit hoher Dringlichkeit, drei mittelschwere und ganze 61 mit der Einstufung „low“. Die gehärtete Version auf Alpine-Basis (dhi.io/nginx:1-alpine3.21) ist nur 4 MByte groß und Docker listet keine einzige bekannte Sicherheitslücke. Ein Blick in den Container zeigt: Der Paketmanager apk, der zu Alpine gehört, fehlt im Abbild.



Kompakt und ohne bekannte Lücken: Das gehärtete Nginx-Abbild auf Alpine-Basis ist nur 4 MByte groß.

Die gehärteten Abbilder gibt es für viele Anwendungen, für die es auch offizielle Abbilder gibt – darunter MySQL, PHP, Node.js, Traefik und MongoDB. Kein gehärtetes Abbild fanden wir für die MySQL-Alternative MariaDB. Um die Abbilder zu finden, müssen Sie sich im Docker Hub mit einem kostenlosen Account anmelden, über den öffentlichen Bereich des Hubs sind sie aktuell nicht zu finden. Sie landen nach dem Login in einer Übersicht namens „My Hub“ und finden links im Menü den Punkt „Hardened Images“. Um die Abbilder auf einem Server, einer Entwicklermaschine oder in einer CI/CD-Umgebung zu nutzen, müssen Sie dort zuerst den Befehl docker login dhi.io ausführen und sich mit Benutzernamen und einem persönlichen Zugangstoken anmelden. Ein solches Token erzeugen Sie, indem Sie oben rechts auf Ihre Initialen klicken, die „Account Settings“ öffnen und links unter „Personal access tokens“ ein Token erzeugen, das Leserechte hat.

Mehr Service gegen Geld

Neben den Abbildern hat Docker Inc. auch Helm-Charts für Kubernetes-Nutzer veröffentlicht, in denen die gehärteten Abbilder zum Einsatz kommen.

Weiterlesen nach der Anzeige

Auch in Zukunft möchte Docker Inc. mit den gehärteten Abbildern Geld verdienen, wie der Blogpost zur Ankündigung erklärt. Wer regulatorische Anforderungen hat und beispielsweise FIPS-konforme Abbilder braucht oder sich eine Reaktion auf kritische CVEs innerhalb von sieben Tagen vertraglich zusichern lassen muss, greift zu den kostenpflichtigen „Docker Hardened Images Enterprise“. Außerdem verspricht Docker erweiterten Support für Anwendungen in Versionen, die von den Entwicklern der Anwendungen nicht mehr unterstützt werden („DHI Extended Lifecycle Support“).


(jam)



Source link

Weiterlesen

Entwicklung & Code

Chainguard startet EmeritOSS-Programm für verwaiste Open-Source-Projekte


Eine Reihe von Open-Source-Projekten, die weit verbreitet und tief in Produktionssystemen eingebettet sind, befinden sich in einer Grauzone zwischen aktiver Entwicklung und nachlassendem Engagement – bis hin zur vollständigen Aufgabe. Die Anwendungen arbeiten stabil, benötigen aber für den weiterhin zuverlässigen Betrieb in Produktion zumindest eine minimale Wartung für Sicherheitspatches und Dependency-Updates. Ziehen sich jedoch die Maintainer aus diesen Projekten zurück, können sie zu einem Sicherheitsrisiko werden. An dieser Stelle setzt das neue Programm „EmeritOSS“ von Chainguard an.

Weiterlesen nach der Anzeige

Das Unternehmen Chainguard, das unter anderem gehärtete Container Images bereitstellt, will laut Ankündigung mit EmeritOSS betroffenen Open-Source-Projekten eine „stabile und verlässliche Heimat“ bieten. Vordringliches Ziel sei nicht die Weiterentwicklung dieser Projekte, sondern die Stärkung der Nachhaltigkeit von Open-Source-Software insgesamt.

Die xz-utils-Backdoor als warnendes Beispiel

Als eine Motivation für das Programm führt Chainguard beispielhaft den Social-Engineering-Angriff auf das Free/Libre-Open-Source-Software-Projekt (FLOSS) xz-utils an. Bei diesem 2024 bekannt gewordenen Vorfall hatte sich der ursprüngliche Maintainer nach langjährigem Engagement aus dem Projekt zurückziehen wollen. Ein neuer Contributor konnte schrittweise dessen Vertrauen gewinnen – und versuchte dann, eine Backdoor einzuschleusen, die unzählige Systeme hätte kompromittieren können.

Unternehmen, die solche ausgereiften Projekte nutzen und von deren Sicherheit und Zuverlässigkeit abhängen, soll EmeritOSS nun ein strukturiertes Übergangsmodell bereitstellen. Der Support-Umfang ist jedoch bewusst begrenzt. Das Programm sieht verschiedene Unterstützungsstufen je nach Community-Erwartungen und Projektlebenszyklus vor – darunter öffentliche Forks zum Erhalten des Codezugangs, Dependency-Updates zum Beheben von Schwachstellen, neue Releases mit den genannten Updates, klare Dokumentation zum Support-Umfang sowie bei Bedarf Container-Images und APK-Pakete.

Stabilität statt neuer Features

Auf das Entwickeln neuer Features oder proaktives Engagement mit Community-Issues und Pull-Requests verzichtet das Programm laut Chainguard ausdrücklich. Die geforkten, auf Stabilität fokussierten Quellcode-Versionen sollen frei auf GitHub verfügbar bleiben. Organisationen, die ein sicheres, kontinuierlich gewartetes Container-Image oder APK bevorzugen, sollten auf kommerzielle Distribution ausweichen. Chainguard wolle mit den Forks lediglich die Kontinuität der Projekte sichern, nicht in Wettbewerb zu kommerziellen Anbietern treten.

Weiterlesen nach der Anzeige

Kaniko, Kubeapps und ingress-nginx als erste Projekte

Den Start des EmeritOSS-Programms markierte die Aufnahme des Kaniko-Projekts, dessen Archivierung Google im Juni 2025 angekündigt hatte. Kaniko ermöglicht das Erstellen von Docker-Images innerhalb von Kubernetes-Clustern ohne privilegierte Container und ist vor allem in regulierten Branchen wie dem Finanzwesen verbreitet. Chainguard hat nach eigenen Angaben die Wartung eines Forks übernommen und bereits CVE-Fixes, Dependency-Updates und gepflegte Images bereitgestellt.

Neu hinzugekommen sind zuletzt die Projekte Kubeapps und ingress-nginx. Nachdem die Kubernetes Community angekündigt hat, ingress-nginx im März 2026 auslaufen zu lassen und künftig standardmäßig auf die Gateway API für das Networking in Kubernetes zu bauen, stehen Nutzer vor der Herausforderung, auf andere Ingress-Controller auszuweichen oder eine Migration auf die Gateway API einzuleiten. Der Fork im Rahmen des EmeritOSS-Programms verschafft Betroffenen nun mehr Zeit beim Evaluieren.

Wer darüber hinaus Vorschläge für weitere Open-Source-Projekte hat, die in das Programm aufgenommen werden sollten, kann diese dem EmeritOSS-Team bei Chainguard gezielt unterbreiten.


(map)



Source link

Weiterlesen

Entwicklung & Code

GitHub stoppt Subventionierung von Actions in privaten Repos


Ab Januar 2026 führt GitHub neue Preise für die automatisierten Aufgaben der Actions in privaten Repositories ein. Für Runner, auf denen die Actions laufen, gibt es eine Preisreduktion um circa vierzig Prozent, wenn GitHub sie hostet. Selbstgehostete Runner kosten ab jetzt hingegen erstmalig eine Gebühr von 0,2 US-Cent pro Minute.

Weiterlesen nach der Anzeige

Actions in öffentlichen Repositories bleiben kostenlos und auch für Enterprise Server ändert sich nichts. GitHub begründet die Änderung mit einer faireren Verteilung der Infrastrukturkosten, weil bislang Hostingkunden die Selbsthoster mitfinanzierten. GitHub hat ausgerechnet, dass sich für 96 Prozent der Kunden nichts ändern wird, vom Rest werden 85 Prozent eine Preisreduktion auf der Rechnung finden. Alle anderen müssen mit einer Erhöhung um 13 Dollar im Median pro Monat rechnen. Über einen Preiskalkulator online lassen sich die Kosten planen.

Im August hatte GitHub eine neue Infrastruktur für die Actions eingeführt, auf der 71 Millionen Jobs am Tag laufen. Die Actions automatisieren Jobs für die Softwareproduktion wie Tests und Builds. Diese laufen auf Runnern, also virtuellen OS-Umgebungen.


(who)



Source link

Weiterlesen

Beliebt