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

Kuratierte KI-Agenten-Sammlung von JetBrains und Zed


Der IDE-Anbieter JetBrains und das Unternehmen hinter dem Sourcecode-Editor Zed, Zed Industries, haben gemeinsam die ACP Registry veröffentlicht. Diese soll es Entwicklerinnen und Entwicklern vereinfachen, mit dem Agent Client Protocol (ACP) kompatible KI-Coding Agenten bereitzustellen, aufzufinden und in Entwicklungsumgebungen zu installieren.

Weiterlesen nach der Anzeige

Die ACP Registry: KI-Agenten per Klick installieren

In der ACP Registry finden sich derzeit ausschließlich kuratierte KI-Agenten und -Extensions, die Authentifizierung unterstützen. Sie folgen dem Agent Client Protocol (ACP), einem standardisierten, offenen Protokoll für das Zusammenspiel von KI-Agenten und Editoren. ACP wurde von JetBrains und Zed Industries erstmals im Oktober 2025 vorgestellt.

Laut den Herstellern war das Protokoll bereits ein großer Schritt nach vorn, doch die Distribution war bisher fragmentiert. Agenten mussten für jeden Client als Extension verfügbar gemacht oder manuell durch User installiert werden. Hier setzt die ACP Registry an: Entwicklerinnen und Entwickler können ihre geeignete Implementierung eines Agenten oder einer Extension einmal registrieren, und diese wird dann für jeden ACP-kompatiblen Client verfügbar.

Sowohl Zed als auch die Entwicklungsumgebungen von JetBrains besitzen integrierten ACP-Registry-Support, um die Agenten auf einfache Weise zu installieren und ihre jeweils aktuellste Version zu verwenden. In JetBrains-IDEs – ab Version 2025.3.2 und mit JetBrains AI (253.30387.147) – lassen sich Agenten beispielsweise im Agent-Picker-Menü unter „Install From ACP Registry…“ auswählen und installieren. In Zed sieht die ACP-Registry-Seite wie folgt aus:


Zed bietet eine integrierte Anbindung an die ACP Registry.

Zed bietet eine integrierte Anbindung an die ACP Registry.

Zed bietet eine integrierte Anbindung an die ACP Registry.

(Bild: Zed Industries)

Das aktuelle Portfolio

Weiterlesen nach der Anzeige

Die kuratierte ACP Registry enthält aktuell die folgenden neun Agenten und Extensions:

  • Auggie CLI
  • Claude Code
  • Codex CLI
  • Factory Droid
  • Gemini CLI
  • GitHub Copilot
  • Mistral Vibe
  • OpenCode
  • Qwen Code

Weitere Informationen zur ACP Registry finden sich auf der offiziellen Website und im GitHub-Repository sowie in den Ankündigungen von JetBrains und Zed Industries.

Lesen Sie auch


(mai)



Source link

Weiterlesen

Entwicklung & Code

Microsofts neues Kommandozeilen-Tool: Windows-Apps ohne Visual Studio entwickeln


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

.

Microsoft hat ein neues Kommandozeilen-Tool für die Windows-App-Entwicklung vorgestellt. winapp CLI soll den Entwicklungsprozess für Anwendungen vereinfachen, die mit Frameworks wie Electron oder Sprachen wie Rust, C++ und .NET erstellt werden. Es verbindet plattformübergreifende Entwicklung mit der nativen Windows-Umgebung. Das Open-Source-Tool befindet sich derzeit in der Public Preview und ist auf GitHub frei verfügbar.

Weiterlesen nach der Anzeige

Das zentrale Versprechen: Was früher zwölf manuelle Schritte erforderte, soll nun ein einziger Befehl erledigen. Der Befehl winapp init lädt die benötigten SDKs wie Windows SDK und Windows App SDK automatisch herunter, generiert Code-Projektionen wie C++/WinRT und konfiguriert Manifeste, Assets, Zertifikate sowie Abhängigkeiten. Das Tool ist bewusst so konzipiert, dass Entwickler ihre gewohnten Editoren – also VS Code genauso wie andere IDEs – weiterverwenden können. Mit winapp restore lässt sich die exakte Entwicklungsumgebung für gemeinsam genutzte Projekte oder in CI/CD-Pipelines wiederherstellen.

Package Identity ohne vollständiges Packaging

Besonders für Cross-Platform-Entwickler interessant ist die Funktion create-debug-identity. Sie fügt einer ausführbaren Datei temporär eine Package Identity hinzu, ohne dass die Anwendung vollständig als MSIX-Paket verpackt werden muss. Das beschleunigt den Entwicklungszyklus erheblich, da moderne Windows-APIs wie die Windows AI APIs, Benachrichtigungen, Shell-Integration oder Hintergrundaufgaben eine solche Identity verwenden.

Für Electron-Entwickler bietet Microsoft ein spezielles npm-Paket an: Mit npm install @microsoft/winappcli --save-dev lässt sich winapp in bestehende Projekte integrieren. Der Befehl winapp node add-electron-debug-identity injiziert die Package Identity direkt in den laufenden Prozess. Zusätzlich stellt das Paket @microsoft/winapp-windows-ai Node.js-Projektionen für Microsofts KI-APIs bereit, etwa für lokale Sprachmodelle oder Text- und Bildverarbeitung.

MSIX-Packaging und CI/CD-Integration

Das Tool übernimmt auch das Erstellen von MSIX-Paketen für die Distribution über den Microsoft Store oder Sideloading. Mit winapp pack ./my-app-files --cert ./devcert.pfx erzeugt es Store-fähige oder für manuelles Deployment vorbereitete Pakete. Entwicklerzertifikate lassen sich per winapp cert generate erstellen und optional lokal installieren. Auch das Aktualisieren von Manifest-Ressourcen funktioniert über die CLI, etwa mit winapp manifest update-assets C:\images\my-logo.png.

Weiterlesen nach der Anzeige

Für Continuous-Integration-Workflows bietet Microsoft Actions für GitHub Actions und Azure DevOps an. Die setup-WinAppCli-Action installiert winapp automatisch in der Pipeline. Entwickler können damit konsistente Build-Umgebungen schaffen, ohne manuell SDKs oder Tools konfigurieren zu müssen.

Alternativen zu Visual Studio und MSBuild

winapp CLI ist laut Ankündigung explizit als Ergänzung für Entwickler gedacht, die außerhalb des Visual-Studio-Ökosystems arbeiten. Neben Electron und Rust unterstützt winapp auch C++ mit CMake, .NET, Dart und weitere Sprachen und Frameworks. Guides für diese Technologien sowie Beispielprojekte finden sich im GitHub-Repository.

Die Installation erfolgt wahlweise über WinGet mit winget install Microsoft.winappcli --source winget, als npm-Paket oder manuell über GitHub Releases. Während der Public Preview sammelt Microsoft Feedback über das GitHub-Repository. Welche Features Priorität erhalten und wann eine finale Version erscheint, ist aktuell offen. Für Entwickler, die auf alternative Cross-Platform-Frameworks setzen, bleiben Optionen wie .NET MAUI, Avalonia, Uno Platform oder React Native for Desktop bestehen.


(fo)



Source link

Weiterlesen

Entwicklung & Code

Google-DeepMind-Chef: Der nächste Einstein könnte eine KI sein


Es ist das ewige Versprechen der Branche und das Feigenblatt, um bis dahin das Verbrennen von Milliarden Dollar und Unmengen an Energie zu rechtfertigen: die Suche nach der AGI. Die Artificial General Intelligence (Künstliche allgemeine Intelligenz) gilt als heiliger Gral der KI-Forscher. Wenn die Software lernt, ohne menschliche Hilfe zu lernen, sollen undenkbare Fortschritte möglich sein. Manch einer hat auch Angst, dass sich die KI dann gegen den Menschen wendet. Aber in zunehmendem Maße halten Menschen diese Zukunftsvision für eine Fata Morgana und den Weg dorthin noch für sehr weit.

Weiterlesen nach der Anzeige

Demis Hassabis, Chef von Googles KI-Sparte DeepMind, hält die AGI für erreichbar. Aber erst in fünf bis zehn Jahren. In einem Interview mit Alex Kantrowitz von Big Technology ließ er kein gutes Haar an seinem Mitbewerber OpenAI und dessen Chef Sam Altman. Man dürfe AGI nicht als Marketingbegriff verwenden, mahnt er. Die allgemeine künstliche Intelligenz sei ein System, das alle kognitiven Fähigkeiten zeigen kann, die Menschen haben, sagt er: „Und ich meine alle.“

Was die AGI können muss

Aber wo ist der Nutzen für die Menschheit? Den würde diese Form von KI erst haben, wenn sie der Menschheit zu neuen Durchbrüchen verhilft, erklärt Hassabis. Es sei nicht damit getan, eine mathematische Gleichung oder eine Vermutung zu lösen. Bahnbrechende Vermutungen sind gefragt, ein neuer Einstein. Oder im künstlerischen Bereich ein Picasso oder ein Mozart. Und zwar mit Fähigkeiten und einer Schlagzahl, wie sie bei Menschen kaum oder gar nicht möglich wäre.

Und obwohl er die Ansicht vertritt, dass die Fähigkeiten heutiger KI-Modelle noch gar nicht alle erkannt und ausgeschöpft sind, zeigt sich Hassabis überzeugt, dass diese noch weit von einer AGI entfernt sind. Heutige KI habe ein „Goldfischgehirn“. Sie kann das Internet durchsuchen, aber dieses Wissen ändere das Modell nicht und sei nach der Sitzung wieder vergessen. Eine Superintelligenz würde sogar noch weitergehen, sie könnte andere Systeme wie Wettersatelliten integrieren oder in 14 Dimensionen denken – Dinge, zu denen kein Mensch fähig wäre.

Mehrere Durchbrüche nötig

Weiterlesen nach der Anzeige

KI brauche auf dem Weg zur AGI noch mehrere Durchbrüche: Neben kontinuierlichem Lernen seien das effizientere Kontextfenster und langfristige Planung. Während das menschliche Gehirn mit selektiver Aufmerksamkeit nur das Wichtige verarbeitet, behandelt KI alle Informationen im Kontext gleich. Dies ist ineffizient und teuer.

In dem Bühnengespräch in Davos ging Hassabis auch auf die Frage ein, ob Google wie OpenAI plane, in seinem Chatbot Werbung zu integrieren. Viel Lob verteilte Hassabis für Start-up Anthropic, in das Google bereits Milliarden Dollar investiert hat. Deren Entwicklungs-Tool Claude Code sei sehr gelungen. Google selbst will die Fähigkeiten seines KI-Modells Gemini mit der neu veröffentlichten IDE Antigravity besser zur Geltung bringen.

Googles Smart-Glass-Pläne

Konkret äußerte sich Hassabis zu Smart Glasses: Google arbeitet mit Partnern wie Warby Parker, Gentle Monster und Samsung an einer neuen Generation KI-gestützter Brillen, die „vielleicht bis zum Sommer“ auf den Markt kommen sollen. Anders als beim gescheiterten Google Glass vor gut zehn Jahren seien nun sowohl die Form ausgereift als auch – entscheidend – die „Killer-App“ vorhanden: ein universeller digitaler Assistent, der freihändig im Alltag hilft. Hassabis selbst arbeitet persönlich an dem Projekt mit.


(mki)



Source link

Weiterlesen

Beliebt