zlib ist eines der wenigen Stücke fremden C-Codes innerhalb von sgcWebSockets. Es treibt die WebSocket-Erweiterung permessage-deflate an, sodass jeder komprimierte Frame, den Ihr Server sendet oder empfängt, durch zlib läuft, und es kümmert sich um die HTTP-Inhaltskodierung. sgcOpenAPI teilt sich denselben Quellcode und verwendet daher dieselbe Kopie. Ab 2026.8.0 wechselt diese Kopie von zlib 1.2.12 auf zlib 1.3.1.
Die Änderung ist in der API unsichtbar. An Ihrem Code muss nichts angefasst werden, und das Kompressionsverhalten bleibt unverändert. Erklärenswert ist, warum ein Versionssprung einer kleinen C-Bibliothek mehr ist als ein Dateiaustausch, und was wir getan haben, um sicherzugehen, dass er auf jedem von uns unterstützten Compiler sicher ist.
Was 1.3.1 behebt, und warum Sie nicht betroffen waren
Die wichtigste Korrektur zwischen 1.2.12 und 1.3.1 ist CVE-2022-37434, ein Heap-Over-Read in inflate(). Er ist nur dann erreichbar, wenn die aufrufende Anwendung zlib einen gz_header übergibt, dessen Feld extra auf einen Puffer zeigt. zlib kopiert dann das gzip-Extra-Feld dorthin, und in 1.2.12 fehlte bei dieser Kopie eine Bereichsprüfung.
sgcWebSockets hat diese Bedingung nie erfüllt. Es ruft inflateGetHeader nur mit einem mit Null initialisierten gz_header auf und weist head.extra nie zu, sodass der betroffene Zweig gar nicht betreten werden konnte. Wir haben das im Quellcode geprüft, bevor wir über das weitere Vorgehen entschieden haben, und wir sagen es deutlich: Anwendungen, die mit früheren Versionen erstellt wurden, waren über diesen Pfad nicht verwundbar.
Wir haben trotzdem aktualisiert. Automatisierte Scanner und Lieferantenfragebögen lesen Versionsangaben, keine Aufrufgraphen, und ein Kunde, der einen Abhängigkeits-Scan durchführt, sollte unsere Argumentation nicht rekonstruieren müssen, um einen Befund auszuräumen. Ein Upgrade beendet die Diskussion, statt sie immer wieder führen zu müssen.
Warum die Aktualisierung von zlib kein Dateiaustausch ist
zlib wird in Ihre ausführbare Datei einkompiliert, statt als DLL ausgeliefert zu werden. Deshalb liegt neben einer sgcWebSockets-Anwendung keine zlib1.dll. Dieses Linken erfolgt über vorkompilierte Objektdateien, und Delphi ist bei deren Format wählerisch. Die Aktualisierung von zlib bedeutet daher, diese Objektdateien neu zu erstellen, und davon gibt es nicht einen Satz, sondern drei.
| Verwendet von | Format | Erstellt mit |
|---|---|---|
| Delphi 7 bis XE | OMF | bcc32, ZEXPORT=__fastcall |
| XE2 und später, Win32 | OMF | bcc32, ZEXPORT=__cdecl |
| XE2 und später, Win64 | COFF | MSVC cl |
Die beiden 32-Bit-Sätze unterscheiden sich in der Aufrufkonvention, denn die älteren Compiler linken zlib mit der Delphi-Register-Konvention, während XE2 und später cdecl verwenden. Der 64-Bit-Satz hat wiederum ein anderes Objektformat. Bemerkenswert ist, dass bcc64 es nicht erzeugen kann, weil dieser Compiler ELF-Objekte ausgibt und der Delphi-Win64-Linker COFF verlangt. Dieser Satz wird deshalb mit dem Microsoft-Compiler erstellt.
Nichts davon ist für Sie sichtbar. Es ist schlicht der Grund, warum ein zlib-Versionssprung eine Build-Übung ist und kein Download.
Auf jedem Compiler verifiziert, nicht nur auf dem neuesten
Neu erstellte Objektdateien können sauber kompilieren und trotzdem falsch sein, ein Link-Test allein genügt also nicht. Mit jedem unterstützten Compiler wurde ein Programm erstellt und dann auch ausgeführt, das einen Puffer komprimiert, ihn wieder dekomprimiert, ihn Byte für Byte vergleicht und sicherstellt, dass die gelinkten Objektdateien die erwartete Version melden.
uses
sgcIdCTypes, sgcIdGlobal, sgcIdZLibHeaders;
var
vPackedLen: TIdC_ULONG;
begin
vPackedLen := SizeOf(vPacked);
if compress(PIdAnsiChar(@vPacked[0]), vPackedLen,
PIdAnsiChar(@vSrc[0]), SizeOf(vSrc)) <> 0 then
raise Exception.Create('compress failed');
WriteLn('zlib ', String(AnsiString(zlibVersion))); // zlib 1.3.1
end;Das lief auf Delphi 7, Delphi 2007, Delphi 2009 und RAD Studio XE6 bis 13, unter Win32 und unter Win64, sofern die Plattform vorhanden ist. Alle 25 Kombinationen bestehen den Test und melden 1.3.1.
Ein latenter 64-Bit-Fehler, nebenbei behoben
Die Matrix hat etwas aufgedeckt, das mit der neuen Version nichts zu tun hatte. Unter Delphi 10 Seattle wählten 64-Bit-Builds die 32-Bit-Objektdateien aus, die sich nicht in eine 64-Bit-Anwendung linken lassen und einen Fehler Bad object file format erzeugten. Die Ursache war eine alte Bedingung, die einmal ein Seattle-spezifisches Problem umgehen sollte und genau diese eine Kombination auf den falschen Objektsatz leitete. Seattle 64 Bit verwendet nun dieselben Objektdateien wie jedes andere 64-Bit-Ziel und kompiliert.
sgcOpenAPI erhält dasselbe Update
sgcOpenAPI teilt sich seinen Quellcode mit sgcWebSockets, zlib eingeschlossen, und wechselt daher im selben Release auf 1.3.1, ohne dass Sie gesondert etwas tun müssen.
Was Sie tun müssen
Installieren Sie 2026.8.0 und erstellen Sie Ihre Projekte neu. Es gibt keine Eigenschaft zu setzen, keine Unit hinzuzufügen oder zu entfernen und keine Änderung bei der Verteilung, denn zlib war bereits in Ihrer ausführbaren Datei enthalten und ist es weiterhin. Wenn Sie für Ihr eigenes Produkt eine Software-Stückliste pflegen, aktualisieren Sie den zlib-Eintrag auf 1.3.1, und Sie können jeden Hinweis auf CVE-2022-37434, den Sie mitgeführt haben, streichen.