Tek TIFF Dosyası ile Sunucunuzu Çökertmek Mümkün: CVE-2026-4775

Görüntü işleme kütüphaneleri güvenlik gündemine nadiren birinci sıradan girer — ancak bu kez libtiff, CVSS 7.8 skoruyla masaya geldi ve durum hafife alınacak cinsten değil. CVE-2026-4775, saldırgana tek bir özel hazırlanmış TIFF dosyası göndererek uygulamayı çökertme ya da uzaktan kod çalıştırma (remote code execution — RCE) imkânı tanıyor. Peki bu kütüphaneyi arka planda sessizce kullanan kaç uygulama var kurumunuzda?

🔍 Zafiyet Nedir ve Teknik Olarak Ne Oluyor?

libtiff, onlarca yıldır TIFF (Tagged Image File Format) dosyalarını işlemek için kullanılan, açık kaynaklı ve son derece yaygın bir kütüphanedir. Sorun, kütüphanenin içindeki putcontig8bitYCbCr44tile adlı fonksiyonda yatıyor. Bu fonksiyon, YCbCr renk uzayındaki 4:4 alt örneklemeli (subsampled) döşeme verilerini bellekte işlerken bir işaretli tamsayı taşması (signed integer overflow) hatasına düşüyor.

Mekanizmanın özeti şu: Fonksiyon, bellek adresi hesaplarken tamsayı aritmetiği kullanıyor. Özel hazırlanmış, aşırı büyük ya da beklenmedik boyutlarda döşeme (tile) verileri içeren bir TIFF dosyası beslendiğinde, bu hesaplama taşıyor ve işaret biti hatalı yorumlanıyor. Sonuç: yanlış bir bellek adresine yazma işlemi, yani yığın dışı bellek yazımı (out-of-bounds heap write). Burası kritik — çünkü yığın (heap) üzerindeki denetimli bir yazım, deneyimli bir tehdit aktörü elinde çoğu zaman kod yürütme primitifine dönüşür.

Bu zafiyetin iki olası çıktısı var: ya uygulama çöküyor (hizmet aksatma — DoS) ya da saldırgan, hedef işlemin izin düzeyinde rastgele kod çalıştırabiliyor. İkinci senaryo çok daha tehlikeli ve asıl dikkat edilmesi gereken bu.

⚠️ Saldırı Nasıl Çalışır? Senaryo Bazlı Analiz

Saldırı yüzeyi düşündüğünüzden çok daha geniş. Şöyle düşünün: Kullanıcıların görüntü yükleyebildiği her uygulama — içerik yönetim sistemleri, e-ticaret platformları, belge yönetim çözümleri, tıbbi görüntüleme yazılımları, hatta e-posta eklenti işleyicileri — arka planda libtiff kullanıyor olabilir.

Somut bir saldırı senaryosu şöyle işleyebilir:

1. Adım — Silah haline getirme: Saldırgan, özellikle kötü amaçlı biçimlendirilmiş, YCbCr 4:4 subsampling içeren bir TIFF dosyası oluşturur. Dosyanın görsel içeriği tamamen meşru görünebilir; zararlı olan yalnızca metadata ve döşeme boyut değerleridir.
2. Adım — Teslim: Dosya; bir form aracılığıyla yüklenebilir, e-posta eki olarak iletilir ya da bir CDN üzerinden çektirilir. Uygulama TIFF dosyasını işlediği anda tetikleme gerçekleşir.
3. Adım — İstismar: putcontig8bitYCbCr44tile fonksiyonu tamsayı taşmasına düşer, yanlış heap adresine yazar. Eğer saldırgan bu yazımı kontrol edebiliyorsa (kontrollü heap düzeni saldırısı — heap grooming), fonksiyon işaretçilerini üzerine yazarak kod akışını ele geçirebilir.
4. Adım — Sonuç: Uygulama sunucu yetkisiyle çalışıyorsa bu adım doğrudan ayrıcalıklı kod yürütme anlamına gelir.

MITRE ATT&CK çerçevesindeki karşılıkları şunlar:

T1190 — Herkese Açık Uygulama İstismarı (Exploit Public-Facing Application): Web üzerinden görüntü kabul eden her uygulama doğrudan hedef.
T1203 — İstemci Tarafı Uygulama İstismarı (Exploitation for Client Execution): Masaüstü uygulamaları veya görüntü önizleyiciler üzerinden tetiklenebilir.
T1059 — Komut ve Betik Yorumlayıcısı (Command and Scripting Interpreter): Başarılı RCE sonrası yük (payload) çalıştırma aşaması.

🏢 Kurumsal Açıdan Kimin İçin Ne Kadar Kritik?

libtiff bağımlılığı, çoğu kurumun farkında bile olmadığı bir yerde oturuyor. Birkaç sektör özelinde konuşalım:

Sağlık: DICOM görüntülemede TIFF formatı sıklıkla kullanılır. Hasta görüntü sistemleri bu açıdan birincil risk grubu. Üstelik bu sistemler genellikle yama döngüsü yavaş, kritik üretim ortamlarıdır.
Medya ve Yayıncılık: Görüntü işleme boru hatları (pipeline), toplu TIFF dönüşümleri ve otomatik küçük resim üretimi sistemleri doğrudan etkilenebilir.
E-ticaret ve Dijital Varlık Yönetimi: Ürün görseli yükleme alanları bu zafiyetin tetiklenmesi için biçilmiş kaftan.
Kurumsal Belge Yönetimi: Tarayıcı çıktıları çoğunlukla TIFF formatındadır. Bu dosyaları otomatik işleyen sistemlerde kullanıcı etkileşimi bile gerekmez.

Buradaki asıl tehlike şu: libtiff, genellikle doğrudan değil dolaylı bir bağımlılık olarak gelir. ImageMagick, GraphicsMagick, GDAL, Pillow (Python) ve daha onlarca kütüphane ya doğrudan libtiff’e bağlıdır ya da sistem kütüphanesi olarak olanı kullanır. Yani “biz TIFF kullanmıyoruz” demek yeterli değil — bağımlılık ağacınızı incelemeniz gerekiyor.

🔧 Wazuh ile Tespit: Kural ve İzleme Yaklaşımı

Kurumda Wazuh kullandığınızda bu tür zafiyetlere karşı birkaç farklı katmanda savunma kurabilirsiniz. Önce basit ama etkili bir yaklaşım: uygulama çökmelerini (crash) ve heap bozulma sinyallerini yakalamak için özel Wazuh kuralları yazın.

Aşağıdaki kural, libtiff işlediği bilinen bir süreçteki segmentation fault veya heap corruption mesajlarını yakalayıp yüksek öncelikli uyarı olarak işaretler:

<!-- /var/ossec/etc/rules/local_rules.xml dosyasına eklenecek -->

<group name="libtiff,cve-2026-4775,heap_overflow">

  <!-- Uygulama çökmesi: heap corruption veya segfault tespiti -->
  <rule id="100500" level="12">
    <if_sid>1002</if_sid>
    <match>corrupted|heap corruption|segmentation fault|double free</match>
    <description>Olasiheap bozulmasi tespit edildi - CVE-2026-4775 ile iliskili olabilir</description>
    <mitre>
      <id>T1190</id>
      <id>T1203</id>
    </mitre>
    <group>attack,exploit_attempt</group>
  </rule>

  <!-- Web uygulamasi uzerinden TIFF dosyasi yukleme girisimleri -->
  <rule id="100501" level="8">
    <if_sid>31108</if_sid>
    <url>upload|file|image</url>
    <match>\.tiff|\.tif</match>
    <description>Web uygulamasina TIFF dosyasi yukleme girişimi - manuel inceleme onerilen</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>web,file_upload</group>
  </rule>

  <!-- libtiff surumunu FIM ile izleme: yetkisiz guncelleme veya degisiklik -->
  <rule id="100502" level="10">
    <if_sid>550</if_sid>
    <field name="file">libtiff|libtiff\.so</field>
    <description>libtiff kutuphane dosyasinda degisiklik tespit edildi - yamalama veya kurcalama?</description>
    <group>fim,library_tampering</group>
  </rule>

</group>

Wazuh’un Dosya Bütünlüğü İzleme (File Integrity Monitoring — FIM) modülüyle libtiff kütüphane dosyalarını da takibe alabilirsiniz. ossec.conf içindeki FIM bloğuna şunu ekleyin:

<!-- ossec.conf - syscheck blogu icerisine ekleyin -->
<directories realtime="yes" report_changes="yes" check_all="yes">
  /usr/lib/x86_64-linux-gnu/libtiff*
  /usr/lib64/libtiff*
  /usr/local/lib/libtiff*
</directories>

Bu yapılandırma sayesinde libtiff dosyaları beklenmedik bir şekilde değiştirildiğinde — ister yamalama sürecinde ister kötü amaçlı bir müdahaleyle — anında uyarı alırsınız.

Etkilenen libtiff sürümünü hızlıca bulmak için tüm Linux sistemlerinizde şu komutu çalıştırabilirsiniz:

# Debian/Ubuntu tabanli sistemler
dpkg -l | grep libtiff

# RHEL/CentOS/Rocky tabanli sistemler
rpm -qa | grep libtiff

# Hangi surumun kurulu oldugunu gormek icin
ldconfig -p | grep libtiff
tiffinfo --version 2>&1 | head -1

# ImageMagick uzerinden dolayli bagimlilik kontrolu
ldd $(which convert) | grep tiff

🛡️ Ne Yapmalısınız? Öncelikli Aksiyon Listesi

1. Bağımlılık envanteri çıkarın: Yalnızca libtiff’i doğrudan kullanan uygulamaları değil, ImageMagick, GDAL, Pillow, LibreOffice gibi dolaylı bağımlılıkları da tarayın. apt-rdepends libtiff5 veya rpm -q --whatrequires libtiff komutları başlangıç için yeterli.
2. Yamayı öncelikli yapın: Dağıtımınızın güvenlik deposundan güncellenmiş libtiff paketini en kısa sürede uygulayın. Üretim ortamında doğrudan yamalama öncesinde test ortamında doğrulama yapın; libtiff geniş bir ekosistem etkisine sahip.
3. Girdi doğrulamasını güçlendirin: TIFF yüklemesini mutlaka yapmanız gereken uygulamalarda dosya boyutu sınırı, tür doğrulama (yalnızca magic byte kontrolü, uzantı yeterli değil) ve ayrı bir izole işlem (sandbox) içinde işleme koyun.
4. Ağ segmentasyonu ve ayrıcalık kısıtlaması: Görüntü işleyen servisleri en az ayrıcalık (least privilege) ilkesiyle çalıştırın. Root ya da yüksek yetkili kullanıcıyla çalışan bir görüntü işleme servisi, başarılı RCE durumunda çok daha büyük hasar verir.
5. Wazuh FIM ve crash tespitini devreye alın: Yukarıdaki kural setini ortamınıza uyarlayıp aktif hale getirin. Özellikle üretim sunucularında libtiff kütüphane dosyalarını gerçek zamanlı izlemeye (realtime FIM) alın.
6. Konteyner ve CI/CD boru hatlarını gözden geçirin: Docker imajlarınızda libtiff’in hangi sürümünün bulunduğunu kontrol edin. trivy image <imaj_adi> komutu CVE tespiti için hızlı bir başlangıç noktasıdır.

Kişisel Değerlendirme: “Görüntü Kütüphanesi” Deyip Geçmeyin

Bu tür zafiyetler, güvenlik ekiplerinin radarına geç girme eğilimindedir. “Görüntü kütüphanesi” etiketi, yanlış bir güven algısı yaratıyor. Oysa libtiff gibi kütüphaneler; web sunucuları, belge sistemleri, tıbbi yazılımlar ve hatta komut satırı araçları içinde yıllarca ses çıkarmadan çalışır. Yama yönetimi (patch management) süreciniz yalnızca birincil uygulamaları değil, bu tür sistem düzeyindeki bağımlılıkları da kapsamıyorsa gerçek saldırı yüzeyinizi göremiyorsunuz demektir.

Rails üzerindeki benzer bir aşırı bellek tüketimi zafiyetini daha önce burada ele almıştık; ya da LaTeX işleyicisindeki RCE için şu yazıya bakabilirsiniz. Ortak tema aynı: meşru görünen girdi, yanlış ele alındığında kritik bir silaha dönüşüyor. CVE-2026-4775 de bu zincirin bir halkası.

📊 Son bir not: Güvenlik açığının henüz yaygın istismar edildiğine dair kamuya açık bir kanıt yok. Ancak CVSS 7.8 skoru ve heap yazım primitifinin varlığı, bu zafiyetin konsept kanıtı (proof-of-concept) araştırmacılar için cazip olduğu anlamına geliyor. Yamanın önüne geçmeden harekete geçin.

Orijinal kaynak: https://nvd.nist.gov/vuln/detail/CVE-2026-4775

Securtr