sgcWebSockets ve sgcOpenAPI'de zlib 1.3.1 | eSeGeCe Blog

sgcWebSockets ve sgcOpenAPI'de zlib 1.3.1

· Bileşenler

zlib, sgcWebSockets içindeki az sayıdaki üçüncü taraf C kodundan biridir. WebSocket permessage-deflate uzantısına güç verir, yani sunucunuzun gönderdiği veya aldığı her sıkıştırılmış çerçeve onun içinden geçer, ayrıca HTTP içerik kodlamasını da o yönetir. sgcOpenAPI aynı kaynağı paylaştığı için aynı kopyayı kullanır. 2026.8.0 sürümünden itibaren bu kopya zlib 1.2.12 sürümünden zlib 1.3.1 sürümüne geçiyor.

Değişiklik API tarafında görünmez. Kodunuzda hiçbir şeye dokunmanız gerekmez ve sıkıştırma davranışı değişmemiştir. Açıklanmaya değer olan şey, küçük bir C kütüphanesinin sürüm yükseltmesinin neden bir dosya değiştirmekten ibaret olmadığı ve desteklediğimiz her derleyicide güvenli olduğundan emin olmak için neler yaptığımızdır.

1.3.1 neyi düzeltiyor ve neden etkilenmediniz

1.2.12 ile 1.3.1 arasındaki en dikkat çekici düzeltme, inflate() içindeki bir heap aşırı okuma açığı olan CVE-2022-37434'tür. Bu açığa yalnızca çağıran uygulama, zlib'e extra alanı bir arabelleği gösteren bir gz_header verdiğinde ulaşılabilir. zlib bu durumda gzip extra alanını oraya kopyalar ve 1.2.12 sürümünde bu kopyalamada sınır denetimi eksikti.

sgcWebSockets bu koşulu hiçbir zaman karşılamadı. inflateGetHeader çağrısını yalnızca sıfırlanmış bir gz_header ile yapar ve head.extra alanına asla değer atamaz, dolayısıyla etkilenen dala girilmesi mümkün değildi. Ne yapacağımıza karar vermeden önce bunu kaynak kodda denetledik ve açıkça belirtiyoruz: önceki sürümlerle derlenen uygulamalar bu yol üzerinden savunmasız değildi.

Yine de güncelledik. Otomatik tarayıcıların ve tedarikçi anketlerinin okuduğu şey çağrı grafikleri değil sürüm dizeleridir, ayrıca bağımlılık taraması yapan bir müşterinin bir bulguyu kapatmak için bizim gerekçemizi yeniden kurgulaması gerekmemelidir. Yükseltmek, bu konuşmanın defalarca yapılmasını gerektirmek yerine onu bitirir.

zlib'i güncellemek neden bir dosya değişiminden ibaret değil

zlib bir DLL olarak dağıtılmak yerine yürütülebilir dosyanızın içine derlenir, bu yüzden bir sgcWebSockets uygulamasının yanında zlib1.dll bulunmaz. Bu bağlama işlemi önceden derlenmiş nesne dosyalarıyla yapılır ve Delphi bu dosyaların biçimi konusunda titizdir. Dolayısıyla zlib'i güncellemek, bu nesne dosyalarını yeniden derlemek anlamına gelir ve tek bir küme değil, üç küme vardır.

KullananBiçimDerleyen
Delphi 7'den XE'yeOMFbcc32, ZEXPORT=__fastcall
XE2 ve sonrası, Win32OMFbcc32, ZEXPORT=__cdecl
XE2 ve sonrası, Win64COFFMSVC cl

İki 32 bit küme çağrı kuralı bakımından farklıdır, çünkü eski derleyiciler zlib'i Delphi register kuralıyla bağlarken XE2 ve sonrası cdecl kullanır. 64 bit küme ise bambaşka bir nesne biçimidir. Şunu belirtmekte fayda var: bcc64 bu kümeyi üretemez, çünkü ELF nesneleri üretir ve Delphi Win64 bağlayıcısı COFF ister, bu yüzden o küme Microsoft derleyicisiyle derlenir.

Bunların hiçbiri size görünmez. Bu yalnızca, bir zlib sürüm yükseltmesinin neden bir indirme değil bir derleme çalışması olduğunun açıklamasıdır.

Yalnızca en yenisinde değil, her derleyicide doğrulandı

Yeniden derlenen nesneler sorunsuz derlenip yine de hatalı olabilir, bu yüzden tek başına bir bağlama testi yeterli değildir. Desteklenen her derleyici, bir arabelleği sıkıştıran, geri açan, bayt bayt karşılaştıran ve bağlanan nesnelerin beklenen sürümü bildirdiğini doğrulayan bir programı derlemek ve ardından çalıştırmak için kullanıldı.

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;

Bu program Delphi 7, Delphi 2007, Delphi 2009 ve RAD Studio XE6'dan 13'e kadar olan sürümlerde, Win32 üzerinde ve platformun bulunduğu yerlerde Win64 üzerinde çalıştı. 25 kombinasyonun tamamı geçti ve 1.3.1 bildirdi.

Yol boyunca düzeltilen gizli bir 64 bit hatası

Matris, yeni sürümle hiçbir ilgisi olmayan bir sorunu ortaya çıkardı. Delphi 10 Seattle üzerinde 64 bit derlemeler 32 bit nesneleri seçiyordu, bunlar 64 bit bir yürütülebilir dosyaya bağlanamaz ve Bad object file format hatası veriyordu. Nedeni, Seattle'a özgü bir sorunu aşmak için konulmuş eski bir koşuldu, bu koşul o tek kombinasyonu yanlış nesne kümesine yönlendiriyordu. Seattle 64 bit artık diğer tüm 64 bit hedefleriyle aynı nesneleri kullanıyor ve derleniyor.

sgcOpenAPI aynı güncellemeyi alıyor

sgcOpenAPI, zlib dahil olmak üzere kaynağını sgcWebSockets ile paylaşır, dolayısıyla aynı sürümde 1.3.1'e geçer ve sizin ayrıca bir işlem yapmanız gerekmez.

Yapmanız gerekenler

2026.8.0 sürümünü kurun ve projelerinizi yeniden derleyin. Ayarlanacak bir özellik, eklenecek veya kaldırılacak bir birim ve dağıtımda bir değişiklik yok, çünkü zlib zaten yürütülebilir dosyanızın içindeydi ve hâlâ öyle. Kendi ürününüz için bir yazılım malzeme listesi tutuyorsanız zlib girdisini 1.3.1 olarak güncelleyin ve taşıdığınız CVE-2022-37434 notunu artık kaldırabilirsiniz.