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

Visual Studio 2022: Im Oktober-Update erinnert sich Copilot an frühere Wünsche


Microsoft hat seine Entwicklungsumgebung Visual Studio 2022 mit dem Oktober-Update versehen. Es bietet nun eine größere Auswahl an Large Language Models (LLMs) im Chat und bringt GitHub Copilot Memories – ein Erinnerungsvermögen für den KI-Assistenten. Darüber hinaus hat Microsoft für C++-Entwicklerinnen und -Entwickler eine Anleitung veröffentlicht, wie sie ihre Projekte auf das nächste Release Visual Studio 2026 aktualisieren können.

Weiterlesen nach der Anzeige

KI-Updates für Visual Studio 2022

Unter der Bezeichnung Copilot Memories kann sich der KI-Assistent GitHub Copilot nun an Dinge „erinnern“: Wenn Entwickler beispielsweise das Verhalten des Copiloten korrigieren, einen Standard explizit ausdrücken oder ihn darum bitten, sich etwas zu merken, erhalten sie die Aufforderung, die entsprechende Präferenz zu speichern. Diese wird in einer von drei möglichen Dateien abgespeichert: .editorconfig für Coding-Standards, CONTRIBUTING.md für Best Practices, Richtlinien und Architekturstandards oder README.md für High-Level-Informationen über das Projekt. Diese gespeicherten Informationen gelten auch für den Rest des Teams, der am Projekt arbeitet.


betterCode() .NET 10.0

betterCode() .NET 10.0

(Bild: coffeemill/123rf.com)

Verbesserte Klassen in .NET 10.0, Native AOT mit Entity Framework Core 10.0 und mehr: Darüber informieren .NET-Profis auf der Online-Konferenz betterCode() .NET 10.0 am 18. November 2025. Nachgelagert gibt es sechs ganztägige Workshops zu Themen wie C# 14.0, künstliche Intelligenz und Web-APIs.

Darüber hinaus können Developer im Oktober-2025-Update nun auch die Anthropic-Sprachmodelle Claude Sonnet 4.5 und Claude Haiku 4.5 verwenden. Claude Sonnet 4.5 hat soll insbesondere in der Softwareentwicklung vergleichsweise stabil und vielseitig sein, während Claude Haiku 4.5 sich durch eine erhöhte Leistung bei geringeren Kosten auszeichnet.

Neben diesen sind auch weitere neue KI-Features mit an Bord, die Microsoft auf seinem Entwicklerblog vorstellt.

C++-Projekte auf Visual Studio 2026 aktualisieren

Speziell für C++-Projekte hat Microsoft eine Anleitung verfasst, wie sie sich auf Visual Studio 2026 migrieren lassen. Derzeit ist das nächste Major Release nur innerhalb des Insider-Programms verwendbar, nähert sich jedoch der allgemeinen Verfügbarkeit.

Weiterlesen nach der Anzeige

Microsoft empfiehlt C++-Developern daher das Ausprobieren der neuen Version in Visual Studio 2026 Insiders, die sich parallel zu einer stabilen Visual-Studio-Version installieren lässt. Dann können C++-Developer zunächst bei ihrer bestehenden MSVC-Toolset-Version verbleiben und den neuen Setup-Assistenten verwenden, um fehlende Tools je nach Projekt zu installieren. Wenn sie dafür bereit sind, können sie schließlich ihre MSCV-Build-Tools auf Version 14.50 aktualisieren, die den MSVC-Compiler in Version 19.50 mitbringen.


(mai)



Source link

Weiterlesen

Entwicklung & Code

Keep Android Open – Abwehr gegen Verbot anonymer Apps von Google


Teile der Android-Developer-Community wehren sich in einem öffentlichen Aufruf unter dem Namen „Keep Android Open“ gegen die von Google schrittweise eingeführten Sideloading-Regeln, die eine Authentifizierung von App-Herausgebern erfordern – auch von denen, die jenseits des offiziellen Android Play Stores veröffentlichen.

Weiterlesen nach der Anzeige

Der Aufruf unbekannter Herkunft kritisiert insbesondere, dass Google den Smartphone-Kundinnen und -Kunden das Recht nimmt, die Software zu installieren, die sie möchten. Entwickler hingegen können Apps nicht mehr direkt weitergeben.

Ferner nimmt die Maßnahme der Gesellschaft ein Stück digitale Souveränität. Der Aufruf weist darauf hin, Google sei „ein Unternehmen, das nachweislich den außergerichtlichen Forderungen autoritärer Regierungen nachkommt, vollkommen legale Apps zu entfernen, die ihnen zufällig nicht gefallen.“

Gegen Monopolisierung und Übermacht

Die Initiative ruft nun Entwicklerinnen und Entwickler dazu auf, der Forderung nach Registrierung nicht nachzukommen: „Reagiert (höflich) auf jede Einladung mit einer Liste eurer Bedenken und Einwände.“ Außerdem sollen sie ihre jeweilige Regulierungsbehörde kontaktieren und auf die Gefahren von “ Monopolen und die Zentralisierung der Macht im Technologiesektor“ aufmerksam machen.

Es folgt eine lange Liste mit Kontaktadressen der jeweiligen Behörden in der Welt. Ferner weist Keep Android Open auf eine Petition von Change.org hin.

In Foren wird ein gewisser Zusammenhang des Aufrufs mit dem alternativen Android-App-Store F-Droid gesehen. Der Text empfiehlt unter Sonstiges an erster Stelle „Install F-Droid“ und umgekehrt gibt es von F-Droid einen Blogeintrag, der die Initiative bewirbt: „Um mehr darüber zu erfahren, was du als Verbraucher tun kannst, besuche keepandroidopen.org.“

Weiterlesen nach der Anzeige

Sideloading nur nach Registrierung und Authentifizierung

Google hatte im Sommer angekündigt, dass sich Herausgeber aller Apps, die auf Android-Geräten installiert werden sollen, registrieren müssen. Dabei müssen sie einen Identitätsnachweis erbringen: Personen mit Ausweis, Firmen mit DUNS-Nummer. Diese Maßnahme zur Stärkung der Sicherheit will Google schrittweise in den Jahren 2026 und 2027 erzwingen. Die Firma stellte jedoch klar, das Sideloading an sich nicht verbieten zu wollen. Für kleine Projekte und Hobby-Entwickler gibt es zudem kostenlose Konten.


(who)



Source link

Weiterlesen

Entwicklung & Code

Neue Features im App Store: Mehr Freiheiten für Entwickler


App-Entwickler, die in Apples App Stores Software verkaufen, können ab sofort mehrere Einreichungen gleichzeitig vom App Review prüfen lassen. Dies teilte der iPhone-Hersteller mit. Mit zusätzlichen Custom Product Pages und der Umstellung auf einheitliche Offer Codes kündigte Apple noch weitere Verbesserungen für Entwickler an.

Weiterlesen nach der Anzeige

Bislang war es bei Einreichungen so, dass jeweils pro App immer nur eine gleichzeitig vorgenommen werden konnte. Mit der Änderung ist es möglich, zusätzliche Inhalte unabhängig von bestehenden Einreichungen in die Prüfung zu geben. Damit können Entwickler zum Beispiel In-App-Events einreichen, während noch eine neue App-Version im Review ist. Früher mussten sie immer erst einmal die bestehende Prüfung abwarten. Die Verbesserung soll zum Beispiel auch helfen, kritische Bugfixes getrennt von Custom Product Pages einzureichen.

Zahl der Custom Product Pages verdoppelt

Die maßgeschneiderten Landing Pages, von Apple Custom Product Page genannt, werden in ihrer Zahl von 35 auf 70 verdoppelt. Diese Seiten können zum Beispiel für die Bewerbung von Apps genutzt werden. Wer über den jeweiligen Link geht, bekommt dann zum Beispiel eine App-Store-Seite angezeigt, die andere Schwerpunkte setzt, als die allgemeine Info-Seite zur App im App Store. Wer möchte, kann die speziellen Landing Pages auch anzeigen lassen, wenn Nutzer des App Stores nach bestimmten Keywords suchen. Neu ist auch, dass jetzt Schlüsselwörter (Keywords) jeder einzelnen Custom Product Page zugeordnet werden können.

Offer Codes, die den kostenlosen oder vergünstigten Abruf einer App oder ihrer Inhalte ermöglichen, unterstützen jetzt alle Arten von In-App-Kauf. Sie sind damit für Verbrauchsgüter, Nicht-Verbrauchsgüter und Abonnements verwendbar, die sich nicht erneuern. Eine erweiterte Unterstützung wird für automatisch erneuernde Abonnements angeboten. Diese können so konfiguriert werden, dass sie nach einer Werbephase nicht automatisch verlängert werden. Apple teilte zugleich mit, dass die bisherigen Promo Codes für In-App-Käufe abgeschafft werden. Ab dem 26. März 2026 können keine neuen mehr erstellt werden. Bestehende behalten bis zum Ablauf ihre Gültigkeit. Für kostenlose App-Downloads bleiben Promo Codes bestehen.

Apple hat in der Vergangenheit immer wieder an Verbesserungen des App Review gefeilt. In den Anfangstagen waren vor allem lange Wartezeiten bei Prüfungen ein Ärgernis. Vor 2015 mussten Entwickler oft über eine Woche, manchmal sogar über zwei Wochen lang warten. Mit der Übernahme der App-Store-Leitung durch den früheren Marketingchef und heutigen Fellow Phil Schiller nahm das App Review Tempo auf. Im Mai 2016 betrug die durchschnittliche Wartezeit nur noch 1,95 Tage, zwischen den Jahren 2020 und 2024 lag sie statistisch bei durchschnittlich 11 Stunden.


(mki)



Source link

Weiterlesen

Beliebt