deniz.in

Piyasalar

Hava durumu

Hava durumu yükleniyor

· kaynak Hacker News – Front Page (native)

HEIF Heist: libheif görsel çözücü hataları Slack, Meta ve OpenAI'yi RCE'ye maruz bıraktı

Araştırmacılar, hazırlanmış HEIC ve AVIF yüklemelerinin bellek bozulması, veri sızıntısı ve RCE'yi tetiklemesine olanak tanıyan bir dizi libheif ve libde265 çözücü açığını anlatıyor; Slack, Meta ve OpenAI ürünleri dahil birçok hizmet etkilenebiliyordu.

HEIF Heist: libheif görsel çözücü hataları Slack, Meta ve OpenAI'yi RCE'ye maruz bıraktı

Tek bir çözüm yığını, çok sayıda hedef

Güvenlik araştırmacıları, kullanıcıların sağladığı HEIF, HEIC veya AVIF görsellerini işleyen hizmetleri tehlikeye atmak için yerel C ve C++ görsel çözücüler libheif ve libde265'deki hataları istismar eden bir saldırı yolları koleksiyonu olan "HEIF Heist"in ayrıntılarını yayımladı. 18 Eylül'de Hacker News'in ana sayfasına ulaşan araştırmacıların yazısına göre bu hatalar, Slack'te, Meta'nın temel ürün ailesinde, GitHub Enterprise'da ve Discourse'ta uzaktan kod çalıştırmak, birden fazla uygulamadan dosya ve token çalmak, hatta OpenAI'nin özel depolarını ele geçirmek için kullanılabilirdi.

Bu çalışma, Hacktron araştırma ekibinden — Harsh Jaiswal, Mohan SRK, Rahul Maini ve Sudhanshu Rajbhar — geliyor. Ekip, Discourse'ta bir libheif uzaktan kod çalıştırma açığı bulup bildirdikten sonra kaç ürünün aynı görsel işleme yığını üzerinde oturduğunu sorarak başlayan aylarca süren bir araştırmayı anlatıyor.

Saldırı zinciri nasıl çalışıyor

Güvenlik açığı uygulamaların kendisinde değil, onların altındaki çözücülerde yer alıyor. Bu kütüphaneler genellikle üretime dolaylı yoldan ulaşır: ImageMagick, libvips veya Sharp gibi üst düzey sarmalayıcılar aracılığıyla paketlenmiş, standart dağıtım paketleri olarak kurulmuş ya da önceden oluşturulmuş container temel imajlarına gömülmüş durumdadır. Sonuç, neredeyse kimsenin doğrudan denetlemediği ama neredeyse herkesin kullanıcı yüklemelerine maruz bıraktığı bir bağımlılıktır.

Araştırmacıların anlattığı saldırı akışı, bir yükleme uç noktasını hatalı biçimlendirilmiş .avif veya .heic dosyalarıyla yoklayarak başlıyor. Farklı libheif sürümleri hazırlanmış girdilere farklı tepkiler verdiği için saldırgan, uzak hizmetin hangi sürüm ailesini çalıştırdığını tespit edebilir ve ardından bellek bozulması, veri sızdırma veya tam uzaktan kod çalıştırmayı tetiklemek için o sürüme özel bir yük — bilinen bir n-day ya da yepyeni bir zero-day — gönderebilir.

Araştırmacılara göre kod çalıştırmanın hemen mümkün olmadığı durumlarda bile bu ilkeller çoğu zaman süreç yığınından, diğer kullanıcıların bilgileri ve ortam değişkenleri dahil, veri okumaya olanak tanıyor. Addaki "heist" (soygun) ifadesi de buradan geliyor.

Kimler etkileniyor

Yazıda uzun bir liste halinde kanıtlanmış etkiler sıralanıyor: dosya sızdırabilme yeteneğiyle Slack'te uzaktan kod çalıştırma; görsel yükleme yoluyla Meta'nın temel ürün ailesinde kod çalıştırma; kullanıcı token'larının ve AWS erişim kimlik bilgilerinin sızması; Discourse'ta kimlik doğrulamalı RCE; Next.js'te AVIF görsel iyileştirme özelliği aracılığıyla kimlik doğrulamasız RCE; CVE-2026-19118 olarak izlenen GitHub Enterprise'da kimlik doğrulamalı RCE; çeşitli web framework'lerinde ve içerik yönetim sistemlerinde RCE; ve OpenAI'nin özel depolarına erişim.

Bu iddialar eşgüdümlü satıcı duyurularından değil, araştırmacıların kendi sitesinden geliyor ve yayımlanan listede bazı etkilenen hedeflerin adları sansürlenmiş durumda.

İstismar çabası ve yapay zekâ desteği

Bu, hazır bir exploit değil. Araştırmacılar, çalışan bir saldırının hedefin çözücü sürümünü parmak iziyle tespit etmeyi ve yük görsellerini buna göre uyarlamayı gerektirdiğini, bazı kod çalıştırma girişimlerinin yalnızca binlerce görsel yüklemesinden sonra başarılı olduğunu belirtiyor. Ayrıca, ileri düzey bir model etrafında kurulan agent tabanlı bir iş akışının, ilk yoklamadan uzaktan kod çalıştırmaya kadar exploit geliştirme süresini kabaca bir ila üç güne indirdiğini iddia ediyorlar — bu da yapay zekâ araçlarının bellek güvenliği hatalarını bulmak ile silaha dönüştürmek arasındaki süreyi nasıl sıkıştırdığının bir göstergesi.

Düzeltmeler ve önlemler

HEIF Heist tek bir sürüme bağlı değil; 1.19.x, 1.20.x, 1.22.x ve 1.23.x dahil olmak üzere birden fazla libheif sürüm ailesini kapsıyor. Araştırmacılara göre en son yukarı akış güvenlik yamalarının bulunmadığı her dağıtım potansiyel olarak savunmasız.

Önerileri şöyle: libheif'i v1.23.2 veya sonrasına, libde265'i ise dağıtım güvenlik kanalları veya kaynak kod derlemesi aracılığıyla en yeni sürüme güncellemek; gerçekten gerekmediği her yerde güvenilmeyen HEIF ve AVIF kod çözümünü kapatmak; ve ISO temel medya dosya biçiminin karmaşıklığı göz önüne alındığında daha fazla bellek güvenliği açığının çıkmasının muhtemel olduğu gerekçesiyle görsel işleme hatlarını sertleştirilmiş, tek kullanımlık sandbox'larda izole etmek. Discourse veya Next.js'i kendi sunucularında barındıran operatörler en yeni sürümlerde olmalı ve bu projelerin güvenlik duyurularını takip etmelidir.

Neden önemli

Modern bir web hizmetindeki en sonuç doğuran güvenlik açığı, kendi kodunun birkaç kat altında oturabilir. Görsel kod çözme, neredeyse her arka ucun bilinmeyen ikili girdiyi bellek güvensiz C/C++ kütüphaneleriyle bilerek ayrıştırdığı nadir yerlerden biridir ve bu kütüphaneler, çoğu mühendislik ekibinin envanterine hiç dahil etmediği sarmalayıcılar, dağıtım paketleri ve temel imajlar aracılığıyla dolaylı yoldan gelir.

Bu desen, ImageTragick, ForcedEntry ve libwebp açığı gibi önceki ayrıştırıcı olaylarını yansıtıyor: tek bir düşük seviyeli kütüphane, binlerce bağımlı ürün ve zayıflık onların altında yaşadığı için diller ile framework'ler ötesine geçen tek bir hata sınıfı. Platform ekipleri için pratik dersler şunlar: hangi çözücünün, hangi sürümde, hangi yükleme yolundan erişilebilir olduğunu tam olarak bilmek ve ayrıştırıcının hata üretmeye devam edeceğini varsaymak — bu da sandbox kullanımını ve agresif yama temposunu herhangi bir tekil CVE kadar önemli kılıyor.

  • #security
  • #vulnerability
  • #libheif
  • #image-processing
  • #rce
  • #supply-chain

İlgili yazılar