- Dünya genelindeki tarayıcılarda ve yayın altyapılarında medyayı işleyen FFmpeg, karmaşık ve güvenilmez girdileri ayrıştırdığı için güvenlik açısından kritik bir saldırı yüzeyi oluşturuyor
- depthfirst'in otonom güvenlik ajanı, yaklaşık 1,5 milyon satırlık optimize edilmiş C kodunda 21 sıfır gün açığı buldu; maliyet yaklaşık $1k oldu ve bu, Anthropic'in Mythos kullanım maliyeti olan $10k'ın %10'u düzeyindeydi
- Bulgular TS demuxer, VP9 decoder, RTP/RTSP/RTMP işleme yolları gibi çeşitli bileşenlere yayılıyor ve bazı açıklar 15–20 yıl boyunca gizli kalmıştı
- AV1 RTP depacketizer açığı, yalnızca 183 baytlık bir RTP paketiyle fonksiyon işaretçisini ezebilen bir PoC'a yol açtı ve sadece
ffmpeg -i rtsp://attacker/stream komutunun çalıştırılmasıyla erişilebiliyor
- Gerçek güvenlik doğrulaması, teorik uyarılardan değil; yeniden üretilebilir girdiler ve çalıştırma doğrulaması gerektirir. Ajan tabanlı analiz, büyük C kod tabanlarındaki gizli açıkları ortaya çıkarmada doğrudan kullanılabilir
Genel Bakış
- FFmpeg, tarayıcılar ve büyük yayın platformlarının altyapıları dahil olmak üzere medyayı işleyen, yaygın biçimde dağıtılan bir yazılımdır
- Sürekli olarak karmaşık ve güvenilmez medyayı ayrıştıran bir kütüphane olduğu için güvenlik açısından kritiktir ve sıfır tıklama saldırılarının başlıca hedeflerinden biridir
- FFmpeg deposu, yaklaşık 1,5 milyon satır son derece optimize edilmiş C kodundan oluşur ve yüzlerce karmaşık medya biçimini ayrıştırır
- FFmpeg, 20 yılı aşkın süredir fuzzing ve manuel denetimlerden geçti; yakın zamanda Google Big Sleep ekibi FFmpeg'te 13 güvenlik açığı yayımladı
- Anthropic, Mythos modeliyle FFmpeg'i tarayarak bazı güvenlik sorunları buldu
- Bu önceki çalışmaların ardından FFmpeg'te yeni açıklar bulmak daha zor hale geldi ve bu durum, büyük kod tabanlarını derinlemesine tarayan ajan tabanlı sistemlerin yeteneklerini doğrulamak için uygun bir hedef oluşturdu
Depthfirst'in Güvenlik Ajanı
- Kodlama ajanları ile güvenlik ajanları aynı temel modeli kullanabilir, ancak hedefleri büyük ölçüde farklıdır
- Kodlama ajanı genellikle insanların verdiği görevleri alıp uygulama kodu yazmaya odaklanır
- Güvenlik ajanı ise somut talimatlar olmadan mevcut sistemlerde gerçekten istismar edilebilir güvenlik sorunlarını bulmaya yönelik, dar ve hedef odaklı bir rol üstlenir
- Güvenlik ajanı önce kod tabanının mimarisini, dışa açık parser ve protokol işleyicilerini ve saldırganın kontrol ettiği girdilerin sisteme giriş noktalarını anlamalıdır
- Ardından depoyu düz bir dosya yığını gibi ele almak yerine, saldırı yüzeyindeki koddan ilgili bileşenleri izleyerek veri akışını takip eder
- Pratik bir güvenlik ajanında; eksik koşulları uydurmasını, teorik hataları abartmasını veya çok sayıda yanlış pozitif üretmesini engelleyen koruma mekanizmaları gerekir
- Saldırganın gerçekten geçerli girdiyi kontrol edip etmediği, açığa giden yola erişimin mümkün olup olmadığı ve şüpheli kusurun yeniden üretilebilir olup olmadığı doğrulanmalıdır
- Gerekirse, hedef bileşenle etkileşen bir harness belirlenmeli veya oluşturulmalı ve hipotez somut olarak test edilmelidir
- depthfirst'in özel güvenlik ajanı kodu derinlemesine analiz eder ve birden fazla hipotezi paralel olarak dallandırıp test eder
- Sonuç; teorik raporlar veya muğlak uyarılar değil, yeniden üretilebilir somut girdilerle çalıştığı doğrulanmış güvenlik sorunlarıdır
Bulgular
- Ajan toplam 21 sıfır gün açığı buldu ve bunlar TS demuxer'dan VP9 decoder'a kadar uzanan bir alana yayılıyor
- Toplam maliyet yaklaşık $1k oldu; bu, Anthropic'in Mythos kullanımı için harcadığı maliyetin %10'u düzeyinde
- Maliyet karşılaştırması: {b:1,10}
-
CVE atanan açıklar
- CVE-2026-39210, TS demuxer'da iki bayt okumadan önce uzunluk sınırı kontrolünün eksik olması nedeniyle oluşan bir heap buffer overflow; 2010'da eklendi
- CVE-2026-39211, swscale refactoring sırasında üst sınırı olmayan boyut katsayısı formülü nedeniyle kullanıcı kontrollü parametrelerin keyfi büyüklükte ölçeklemeye yol açabildiği bir integer overflow; 2010'da eklendi
- CVE-2026-39212,
ffmpeg_opt.c içinde preset dosyalarının derinlik sınırı olmadan seçenek ayrıştırmayı özyinelemeli biçimde tetikleyebilmesi sonucu oluşan bir stack overflow; 2025 Temmuz regresyonu olarak eklendi
- CVE-2026-39213, yuv4mpegenc rawvideo giriş yolunda paket boyutuna ilişkin boyut doğrulamasının eksik olmasından kaynaklanan bir heap buffer overflow; 2023'te eklendi
- CVE-2026-39214, özgün SDT uygulamasında kalan alan izlenmeden service entry yazılması sonucu oluşan bir stack buffer overflow; 2003'te eklendi ve 23 yıl boyunca gizli kaldı
- CVE-2026-39215,
update_mb_info() içindeki mantık hatası nedeniyle sonraki çağrıların ayrılan tamponun 12 bayt sonrasına yazmasına yol açan bir heap buffer overflow; 2012'de eklendi
- CVE-2026-39216,
img2enc.c içinde güvenli chroma boyutunun, boyuta dayalı sınırsız bir değerle değiştirilmesi sonucu oluşan bir heap buffer overflow; 2012'de eklendi
- CVE-2026-39217, VP9 decoder'da yeniden düzenlenen boyut güncelleme fonksiyonu nedeniyle tile thread tamponunun gerekli yeniden tahsisi kaçırmasına yol açan bir heap buffer overflow; 2025 Mart regresyonu olarak eklendi
- CVE-2026-39218, DASH demuxer'da negatif duration değerlerinin reddedilmemesi nedeniyle fragment dizi indeksinin negatif hale gelmesiyle oluşan bir heap buffer overflow; 2017'de eklendi
-
Dahili izleme kimlikleriyle anılan açıklar
- DFVULN-127, RTP AV1 depacketizer içindeki
av1_handle_packet() fonksiyonunun Temporal Delimiter OBU'yu atlayıp obu_size kadar çıktı konumunu ilerletmesine rağmen aynı büyüklükte alan ayırmaması nedeniyle, sonraki OBU'nun tampon sınırı dışına yazılmasına yol açan bir heap buffer overflow'dur
- DFVULN-126, swscale graph kodundaki
run_legacy_unscaled() fonksiyonunun interlaced YUV420P→NV12 dönüşümünü hatalı işlemesi nedeniyle hedef Y-plane'in 576 bayt ötesine yazan bir heap buffer overflow'dur
- DFVULN-125, RTP JPEG depacketizer içindeki
jpeg_create_header() fonksiyonunun 1024 baytlık stack tamponunda quantization-table bölümünü oluştururken, qtable_len >= 1024 paketinden sonra gelen AV_WB16 yazımının sonu 2 bayt aşmasına yol açan bir stack buffer overflow'dur
- DFVULN-124, AVIF overlay yolundaki
istg_parse_tile_grid() fonksiyonunun sıfır tile entry içeren dimg referansını reddetmemesi nedeniyle, işaretsiz wraparound sonrasında 1 baytlık heap tahsiste sınır dışı okumaya yol açan bir heap buffer overflow'dur
- DFVULN-123, RTP LATM depacketizer içindeki
latm_parse_packet() fonksiyonunda signed 32-bit toplama taşması yüzünden sınır kontrolünün atlanmasına ve memcpy çağrısının heap tamponunun sonundan yaklaşık 1GB sonrasını okumasına yol açan bir integer overflow'dur
- DFVULN-122, RTP MPEG-4 depacketizer içindeki
aac_parse_packet() fonksiyonunun AU-headers-length 0 değerini kabul ederek 1 baytlık tahsis oluşturması ve AU header varlığını doğrulamadan 4 baytlık alandan okuma yapması sonucu oluşan bir heap buffer overflow'dur
- DFVULN-121, CAF demuxer içindeki
read_seek() fonksiyonunun av_index_search_timestamp() çağrısının -1 dönüşünü kontrol etmeden bunu dizi indeksi olarak kullanması ve index_entries[-1] erişimine yol açması nedeniyle oluşan bir heap buffer underflow'dur
- DFVULN-120, AVI demuxer içindeki
ff_read_riff_info() fonksiyonunun size >= 4 kontrolü olmadan size - 4 kullanması nedeniyle, LIST chunk boyutu 0 olduğunda yaklaşık 4GB'lık underflow ve yaklaşık 2GB tahsise yol açan bir integer underflow'dur
- DFVULN-119, option parser içindeki
opt_map() fonksiyonunda gereksiz bir artış nedeniyle link-label'ın file index olarak yanlış ayrıştırılmasına ve stream index -1 değerinin saklanmasına yol açan; bunun sonucunda sonraki döngünün AVStream** dizisinin öncesini okuduğu bir heap buffer overflow'dur
- DFVULN-118, RTSP server yolundaki
rtsp_read_announce() fonksiyonunun negatif Content-Length değerini geçerli işlemesi nedeniyle, uzaktaki ANNOUNCE ve Content-Length: -1 ile sdp[-1] konumuna sınır dışı yazmaya yol açan bir heap buffer overflow'dur
- DFVULN-117, RTMP istemcisindeki
rtmp_calc_swfhash() fonksiyonunun in_size < 8 yerine yalnızca in_size < 3 kontrolü yapması nedeniyle, en az 3 baytlık bir tampondan 8 bayt okuyan bir heap buffer overflow'dur
- DFVULN-116, RTSP SDP ayrıştırmasındaki
sdp_parse_line() fonksiyonunun boş dizgede strlen(control_url) - 1 hesaplaması yapması nedeniyle size_t değerinin SIZE_MAX'a wraparound olması ve 1 baytlık pre-buffer read oluşmasıyla sonuçlanan bir heap buffer overflow'dur
Atlanan Çerçeve İşaretçisinden PC Kontrolüne
- 21 bulgu arasında AV1 RTP depacketizer içindeki heap buffer overflow, ağ üzerinden özel bayraklar olmadan erişilebilir durumda
- Kurbanın yalnızca
ffmpeg -i rtsp://attacker/stream komutunu çalıştırması yeterli ve tek bir 183 baytlık paket yürütme akışını değiştirebiliyor
- FFmpeg bir RTSP akışı aldığında, sunucu kodlanmış videoyu bir RTP paketleri dizisi olarak gönderir
- AV1, bit akışını OBU (Open Bitstream Units) yapılarıyla düzenler ve RTP payload formatı bu OBU'ları birden çok pakete böler
- FFmpeg'in depacketizer bileşeni, bölünmüş OBU'ları yeniden temiz bir elementary stream halinde birleştirir
- Temporal Delimiter (TD), bir temporal unit'i, yani bir kare ile sonraki kareyi ayıran küçük bir işaretçidir
- Spesifikasyon, payload içindeki TD'nin depacketizer tarafından “ignore and remove” edilmesini şart koşar
- Sorun da bu “ignore and remove” işlemi sırasında ortaya çıktı ve ajan bu noktayı tespit etti
Kök Neden
- depacketizer, çıktı paketini kademeli olarak oluşturur;
pktpos imleci pkt->data içinde bir sonraki baytın yazılacağı konumu izler
pktpos, paketin mevcut sonundan başlar
// libavformat/rtpdec_av1.c:199
pktpos = pkt->size;
- Kod, paket içindeki OBU elemanlarını dolaşırken gerçekten dışa aktaracağı her bayttan önce
av_grow_packet çağrısı yapar ve bu çağrı pkt->data için heap tahsisini büyütür
- Tüm rutinin dayandığı değişmez kural,
pktpos değerinin pkt->data için ayrılan boyutun önüne geçmemesi gerektiğidir
- Temporal Delimiter işleme kodu bu değişmez kuralı bozar
// libavformat/rtpdec_av1.c:250
if ((obu_type == AV1_OBU_TEMPORAL_DELIMITER) ||
(obu_type == AV1_OBU_TILE_LIST)) {
pktpos += obu_size;
rem_pkt_size -= obu_size;
obu_cnt++;
continue;
}
- TD atlandığında
pktpos, saldırganın bildirdiği obu_size kadar ileri alınır; ancak bu ilerlemeyi destekleyecek bellek ayrılmaz
- Girdi işaretçisi
buf_ptr da TD baytlarının ötesine taşınmaz
- TD için
obu_size = 148 olduğunda pktpos 148 olur, ancak pkt->data hâlâ ayrılmamış olabilir ya da 148 bayttan çok daha küçük olabilir
- Sonraki döngü TD'nin kendi baytlarını yeniden ayrıştırır, TD header baytını yeni bir OBU uzunluğu olarak tekrar okur ve payload'ı manipüle edilmiş OBU içeriği olarak kullanır
- Sonraki normal OBU'da paket yalnızca o OBU'nun boyutu kadar büyütülür
// libavformat/rtpdec_av1.c:296
if ((result = av_grow_packet(pkt, output_size)) < 0)
return result;
// libavformat/rtpdec_av1.c:304 / 336
pkt->data[pktpos++] = *buf_ptr++ | AV1F_OBU_HAS_SIZE_FIELD;
memcpy(pkt->data + pktpos, buf_ptr, obu_payload_size);
- Manipüle edilmiş OBU 17 baytsa,
av_grow_packet 17 bayt ile FFmpeg'in 64 baytlık input padding'ini ekleyerek 81 baytlık bir tampon ayırır
- Yazma işlemi
pkt->data[148] konumunda başlar ve tahsis edilmiş alanın sonundan 67 bayt sonra gerçekleşir
- Bu kusur, saldırganın hem ofseti hem de içeriği kontrol edebildiği bir heap buffer overflow haline gelir
İstismar Yöntemi
- Kontrol edilebilir bir overflow'un işe yaraması için tamponun hemen arkasında üzerine yazılabilecek bir hedef bulunmalıdır; FFmpeg'in allocator'ı bu hedefi sağlar
av_grow_packet paket veri tamponunu ayırırken av_buffer_alloc üzerinden gider ve bu fonksiyon veri tamponunu, AVBuffer bookkeeping struct'ını ve AVBufferRef yapısını sırasıyla heap'e ayırır- FFmpeg, 64 bayt hizalamalı
posix_memalign tahsisleri kullandığından, 81 baytlık veri tamponu 128 baytlık bir chunk kaplar ve hemen arkasına AVBuffer struct'ı yerleşir
AVBuffer struct'ı, serbest bırakma callback'i olarak kullanılan bir fonksiyon işaretçisi içerir
// libavutil/buffer_internal.h
struct AVBuffer {
uint8_t *data; // +0
size_t size; // +8
atomic_uint refcount; // +16
void (*free)(void *opaque, uint8_t *data); // +24
void *opaque; // +32
...
};
- Veri tamponunun başlangıcına göre
AVBuffer.free işaretçisi 152 ofsetinde bulunur
- TD için
obu_size = 148 olduğunda yazma işlemi pkt->data[148] konumunda başlar
- TD header baytı
0x10, uzunluğu 16 olacak şekilde yeniden yorumlanır ve manipüle edilmiş 16 baytlık OBU'nun header ve payload'ı 148 ofsetinden itibaren yazılır
AVBuffer.refcount, 144–147 ofsetlerinde bulunduğu için yazmanın başlangıç noktası olan 148'in öncesinde kalır ve özgün 1 değerini korur- İstismar, TD payload içine üçüncü bir manipüle OBU yerleştirerek bir kez daha
av_grow_packet çağrısı yapılmasını sağlar
- Tampon
av_buffer_realloc yerine av_buffer_alloc ile oluşturulduğu için yeniden tahsis edilebilir olarak işaretlenmez ve FFmpeg yeni bir tampon ayırıp eski tamponu serbest bırakan yolu izler
// libavutil/buffer.c:209
if (!(buf->buffer->flags_internal & BUFFER_FLAG_REALLOCATABLE) || ...) {
ret = av_buffer_realloc(&new, size);
memcpy(new->data, buf->data, ...);
buffer_replace(pbuf, &new);
return 0;
}
buffer_replace, eski tamponun refcount değerini 1'den 0'a düşürür ve serbest bırakma callback'ini çağırır
// libavutil/buffer.c:129
if (atomic_fetch_sub_explicit(&b->refcount, 1, memory_order_acq_rel) == 1) {
b->free(b->opaque, b->data);
}
- Bu noktada üzerine yazılmış
free işaretçisi çağrılır ve instruction pointer kontrolü mümkün hale gelir
- Release build'de tek bir 183 baytlık RTP paketi
rip değerini 0xdeadbeef yaptı
#0 0x00000000deadbeef in ?? ()
rip 0xdeadbeef 0xdeadbeef
#1 buffer_replace (buffer.c:133)
#2 av_buffer_realloc (buffer.c:220)
#3 av_grow_packet (packet.c:151)
#4 av1_handle_packet (rtpdec_av1.c:296)
#5 rtp_parse_packet_internal (rtpdec.c:743)
Etki Alanı ve PoC
- FFmpeg'in saldırganın etkileyebildiği bir RTSP URL'sini açmaya zorlandığı dağıtımlar bu açıktan etkilenir
- Kullanıcı tarafından sağlanan stream URL'lerini alan medya ingest pipeline sistemleri etki alanına girer
- RTSP feed alan surveillance ve CCTV sistemleri etki alanına girer
- Uzak AV1-over-RTP kaynaklarını işleyen transcoding service'ler etki alanına girer
- Kimlik doğrulama ya da akışı açmanın ötesinde herhangi bir kullanıcı etkileşimi gerekmez; alışılmadık bir command-line flag de gerekmez
- Açık, bu istemcilerin tasarım gereği yürüttüğü normal RTSP
PLAY aşamasında tetiklenir
- PoC kodu ffmpeg-dfvuln127 adresinde yer alıyor
1 yorum
Hacker News yorumları
FFmpeg güvenlik açısından özellikle kötü bir sicile sahip
Eskiden beri her fuzzer çalıştırıldığında neredeyse sonu gelmeyen bellek bozulması hataları çıkıyordu; 10 yıl önce Google çalışanlarının yaptığı bir çalışma da vardı: https://security.googleblog.com/2014/01/ffmpeg-and-thousand-...
Bu yüzden bu, LLM yeteneklerini gösteren bir demo olsa da şaşırtıcı değil. Güvenilmeyen ya da kullanıcı tarafından sağlanan içerikle uğraşıyorsanız FFmpeg’i sandbox dışında çalıştırmamalısınız; bunu yapmak mantıksız bir risk almak olur
90’lardan kalma bir video oyununda kullanılabilecek kadar niş bir codec’te açık vardı; bunu bildiren kişi çok büyük bir olaymış gibi davranmıştı ama geliştiriciler bunun pratikte neredeyse hiç kullanılmayan bir codec olduğunu söyleyerek önemsizleştirdi
Ama saldırgan bir video dosyası sağlayabiliyorsa istediği video codec’i seçebileceği gerçeğini bilmiyorlar mı diye düşündüm. Geliştirici o codec’in hiç kullanılmadığını sansa bile, hâlâ kullanılabiliyorsa saldırgan da kullanabilir
Acaba benim kaçırdığım bir nokta mı var, bu codec açığının gerçekten önemsiz sayılması için geçerli bir neden var mı merak ediyorum
Yakın zamana kadar yerel virtio GPU context yoktu; bu yüzden donanım hızlandırmanın tamamını kaybetmeden video oynatıcıyı sandbox’a almak bile mümkün değildi. En azından dışarıdan zorla yapmak öyleydi; içeriden ise Chromium’un yaptığı gibi FFmpeg’i izole edip seccomp ile sıkıca kısıtlamak mümkündü
Bu yalnızca FFmpeg’in sorunu değil. Apple’ın da sayısız görüntü ve video decoder açığı oldu. Bu alan başlı başına çok zor ve FFmpeg herkesten daha fazla iş yapıyor
Bence sektör yanlış şeyi optimize ediyor. Mythos preview 1 ya da GPT-5.5 gibi araçlarla AI tarafından yazılmış binlerce bug report üretmek kolay. Zor olan bug’ı gerçekten düzeltmek
Birkaç aydır kritik güvenlik sorunlarını bulup sadece rapor açmak yerine doğrudan PR açan bir sistem kuruyorum. Şu ana kadar kabul oranı yaklaşık %94. Başarısızlıkların çoğu güvenlik açığını yanlış değerlendirmekten değil, belgelenmemiş projeye özgü kill switch’ler ya da iç mekanizmalardan kaynaklandı
Geliştiriciler genel olarak bu yaklaşımı daha çok seviyor gibi. Bug report iş çıkarır, iyi bir PR ise işi azaltır. Bu çok açık görünüyor ama birçok güvenlik ürünü hâlâ rapor üretip orada bırakıyor deniyor
Sektör var olduğundan beri hep böyleydi ve ancak şimdi bunun yarattığı hasarı ve genel kırılganlığı değerlendirecek uygun araçlara sahip olmaya başlıyoruz
Bu bug, erişim kapsamı nedeniyle ciddi. FFmpeg’in saldırgan etkisindeki bir RTSP URL’sine baktığı her deployment etkileniyor
Kullanıcı tarafından sağlanan stream URL’lerini alan medya alım pipeline’ları, RTSP feed çeken gözetim/CCTV sistemleri, uzak AV1-over-RTP kaynaklarını işleyen transcoding servisleri buna dahil. Gerçekten oldukça ciddi ve hatta bunun kamuya açıklanmış olması bile şaşırtıcı. Şu anda hemen istismar edilebilecek birkaç servis aklıma geliyor
Bu bir güvenlik şirketi reklamı gibi göründüğü için sanıldığı kadar büyük bir olay olmasa bile, piyasaya sürdüğünüz her uygulamanın bir yerinde güvenlik deliği bulunduğunu ve artık script kiddie’lerin bunu yayına çıktıktan 5 dakika sonra 2 dolarlık krediyle bulabildiğini hatırlatıyor
Yayına almadan önce kodu red team ile doğrulamazsanız, yayınlandıktan sonra bunu hacker’lar sizin yerinize yapar
Zero-day terimi abartılı biçimde kullanılıyor. Açıklanan açıkların hiçbiri aslında gerçek bir zero-day değil ama böyle denince kulağa daha iyi geliyor ve daha çok tıklama alıyor
“Bu noktada bozulmuş free pointer çağrılıyor ve komut işaretçisi kontrolü bize geçiyor” ifadesi çok ciddi
Yine de pratikte yalnızca bu bug ile rastgele uzak kod çalıştırmaya kadar gidilebilecek gibi görünmüyor. Özellikle ASLR varsa daha da zor; ayrıca bir yerde hem yazılabilir hem çalıştırılabilir bellek sayfası olması gerekir
Yine de ASLR’yi aşmak için başka bir exploit gerekir
Bunun anlamı “zero-day” değil
Güvenlik araştırması alanındaki teşvik yapısı fena halde bozulmuş durumda
Bunlar FOSS dünyasının orta kademe yöneticileri gibi. Gönüllülerin üzerine daha fazla iş yıkarak övgü topluyorlar ve iş ne kadar acilse o kadar çok övülüyorlar. Sorunların gerçek etkisini ya da pratik sonuçlarını kabul etmek onların teşvikleriyle çelişiyor
Yazılım sektörünün dip temizliğini yapan insanlar gibi görünmemek zor ve artık onlara dışlanan kişiler gibi davranılmaya başlanması gerektiğini düşünüyorum. Ya PR gönderin ya da sessiz olun deniyor
FFmpeg’i hem kişisel olarak hem de yaptığım servislerde çok uzun zamandır kullanıyorum. Fabrice Bellard bir dahi ve FFmpeg’i buraya getiren geliştiriciler dünyayı ölçülebilir biçimde daha zengin hale getirdi
Ama güvenilmeyen girdilerle çalıştırıldığında, FFmpeg kadar sandbox içine alınmaya değer başka bir program aklıma gelmiyor. Çünkü kötü şöhretli derecede kusursuz yapması zor olan karmaşık video·ses codec’leri devasa bir C kod tabanı tarafından ele alınıyor
Yine de pratikte bu o kadar büyük bir sorun değil. FFmpeg’i bir VM ya da gVisor içinde çalıştırırsınız ve nihai çıktı da genelde zaten tarayıcıda oynatmaya razı olacağınız bir video dosyası olur. Tarayıcıda da ayrıca başka bir sandbox içinde decode edildiği için bu zaten baştan zor bir iş
Güvenli sandboxing, kopyalamayı sınırsız hale getirecek bir fırsata kolayca dönüşebilir
RTP LATM depacketization kodunda latm_parse_packet() işaretli 32 bit toplama yaparken taşmaya uğrayıp sınır kontrolünü atlattığı bir zafiyet
Yine kontrolsüz toplama yüzünden bir zafiyet ortaya çıkmış; buna rağmen Rust ya da Go gibi modern diller taşmada istisna fırlatmıyor, RISC-V gibi modern CPU mimarileri de overflow trap sunmuyor. C ya da C++ gibi eski dillerde de taşma kontrolü yok
Komik bir durum. İnsanların doğru aritmetik kod yazacağına güvenilemeyeceği açık
Rust’ın release modundaki varsayılan tamsayı taşması davranışı da tanımlıdır; sadece wrap olur. Bu yüzden zafiyete dönüşme olasılığı azalır. Tabii unsafe Rust kullanmaya başlarsanız durum değişir
Rust varsayılan olarak taşma istisnası vermez ama 123.checked_add(321) gibi yazabilirsiniz. Böyle olunca kodu okumak zorlaşır ama taşmaya karşı güvenli olur
Dürüst olmak gerekirse benim kod yazma tarzımda satır sonu yorumu gibi bir biçim daha iyi olurdu. Mesela
var x = y + z; # wrappedgibiTek bir satır içinde wrap eden·kontrollü·doyumlu aritmetiği karıştırma ihtimali çok düşük. Zig’de her satırın başka bir kod bağlamı olmadan da kendi başına derlenebilir olması gerektiğinden
doing(wrapped) { x + y }gibi bir derleyici durumu olamaz. Fonksiyon adları fazla uzun, tür dönüşümleri de fazla uzun. İfade düzeyinde bir değiştirici iyi bir orta yol olabilir