60 saniyede patch diffing
Bir güvenlik yaması (security patch), üreticinin neyin hatalı olduğunu kamuya açık bir şekilde harfi harfine yazmasıdır. Bunu bir ifşa (disclosure) amacıyla yapmazlar; amaçları bir düzeltmedir (fix). Ancak iki çıktı (artifact) aynı baytlardır ve yamalanmış ile yamalanmamış binary arasındaki farkı okuyabilen herkesin eline zafiyet teslim edilmiş olur.
Patch diffing, bu farkı tersten okuma pratiğidir. Üretici cevabı sunar; işin özü soruyu yeniden inşa etmektir (reconstruct).
Neden düzeltme (fix) en iyi başlangıç noktasıdır?
Zafiyet araştırmalarının çoğu bir kara kutudan başlar: bir ürün, bir protokol, bir dosya formatı ve hatanın nerede olduğuna dair hiçbir fikir yoktur. Bu, çalışmanın maliyetli yoludur ve bu kadar çok girişimin hiçbir şey bulamadan sonuçlanmasının nedeni de budur.
Bir yama, problemi tersine çevirir. İçinde bir yerlerde belirli bir kod yolu (code path) bir nedenden ötürü değişmiştir ve bu neden bir hatadır (bug). Hatayı bulmak zorunda değilsiniz. Değişikliği bulmanız gerekir; ve değişiklik oldukça belirgindir — yeni bir kontrol eklenen bir fonksiyon, değişen bir uzunluk, yeri değiştirilen bir çağrı.
Üretici araştırmanın zor olan yarısını yapmış ve yayımlamıştır. Diffing, diğer yarısını toplama yönteminizdir.
İş akışı beş adımdır ve ortadaki adım her şeydir
Bir: Her iki derlemeyi (build) elde edin. Yamalı ve yamasız binary, firmware imajı veya paket. Asıl çaba gerektiren adım budur — üretici zafiyet barındıran sürümü arşivlemez ve eski firmware’ler indirme sayfasından aniden kaybolma eğilimindedir. Yansılar (mirrors), paket kayıt defterleri ve güncelleme önbellekleri genellikle bunları barındırır.
İki: Aralarındaki diff’i alın. Mekanik aşama. Fonksiyon düzeyinde diff almak bayt düzeyindekinden çok daha önemlidir; çünkü bir derleyici (compiler) değişikliği her şeyi yeniden sıralar ve asıl değişikliği bir gürültü denizinde gizler:
$ radiff2 -C vuln.bin patched.bin-C, adres ve register yeniden adlandırmalarından etkilenmeyen kod düzeyinde bir diff üretir. Daha kapsamlı çalışmalar için Diaphora (IDA) ve Ghidra’nın version tracking özelliği iki derleme arasında fonksiyon düzeyinde bir harita çıkarır; bu da tam olarak istediğiniz şeydir — “hangi fonksiyon değişti ve ne kadar değişti” sorusunun yanıtı.
Üç: Değişen fonksiyonu izole edin. Tüm mesele buradadır. Tipik bir güvenlik yaması yalnızca birkaç fonksiyona dokunur ve bu değişikliklerin çoğu önemsizdir. Asıl önemli olan; daha önce orada olmayan bir uzunluk kontrolü, sınır karşılaştırması (bounds check) veya doğrulama çağrısı eklenmiş olan fonksiyondur.
Dört: Değişikliği tersten okuyun. Düzeltme size hatayı söyler. Yeni bir if (len < 0), uzunluğun saldırgan tarafından kontrol edilebildiği anlamına gelir. Yeni bir null kontrolü, bir null değerin erişilebilir olduğu anlamına gelir. Daha küçük bir boyuta sahip yeri değiştirilmiş bir memcpy, bir taşmanın (overflow) mümkün olduğu anlamına gelir. Her düzeltme, kapattığı zafiyete dair kurulmuş bir cümledir ve bunu tersten okumak asıl uzmanlıktır.
Beş: Varyantı avlayın. Kök nedeni (root cause) anladığınızda, elinizdeki tek bir binary ile ilgilenmeyi bırakırsınız. Aynı hata sınıfı başka yerlerde de vardır — aynı fonksiyonun kardeşlerinde, aynı üreticinin diğer ürünlerinde ve aynı problemi aynı yöntemle çözen tüm kod tabanlarında.
Deltayı tersten okumak
Belirli işaretler küçüktür ve her üreticide tutarlıdır:
- Değişen bir boyut.
memcpy(dst, src, n)ifadesimemcpy(dst, src, min(n, limit))haline gelir. Yama öncesindekindeğeri zafiyetti; geriye kalan tek soru bu değerin nereden geldiğidir. - Ortaya çıkan bir kontrol. Bir indeksleme işleminden önceki bir karşılaştırma, bir yazma işleminden önceki bir aralık kontrolü, eskiden
strlenolan yerde artıkstrnlenbulunması. Kontrol yamanın kendisidir; artık reddettiği şey ise hatanın ta kendisidir. - Yeri değiştirilen bir çağrı. Hassas işlemden sonra çalışan bir kimlik doğrulama (authentication) veya yetkilendirme (authorization) çağrısı artık ondan önce çalışır. Bu sıralama değişikliği, bir düzeltme olarak yazılmış yetkilendirme eksikliği (missing authorization) bulgusudur.
Bunların hiçbiri binary’nin tamamını anlamayı gerektirmez. Deltayı anlamayı gerektirir ve delta küçüktür. Zor kısmı üretici yapmıştır; diff bir haritadır ve haritalar kısadır.
Tek bir yamadan çok sayıda zafiyete
Varyant avı, patch diffing’in 1 günlük (1-day) bir aktivite olmaktan çıkıp gerçek bir araştırmaya dönüştüğü yerdir. Kök neden (root cause) bir konum değil, bir sınıftır.
Eğer düzeltme “uzunluk alanı kopyalamadan önce hiçbir zaman doğrulanmıyordu” ise; aynı formattaki, aynı kütüphane tarafından ayrıştırılan aynı alan, aynı binary içinde başka bir yerde de kopyalanıyordur — ve üreticinin diğer ürünlerinde, ve aynı protokolün tüm üçüncü taraf uygulamalarında. Bir kez okunan tek bir yama, hiçbir fuzzer’ın önceliklendiremeyeceği bir inceleme listesi sunar; çünkü araştırmacı artık hatanın tam olarak hangi biçimde olduğunu bilmektedir.
Bir CVE ile bir araştırma çizgisi arasındaki fark budur. Yama size tek bir örnek (instance) sundu. Kök neden ise size bir sınıf sunar; ve takip eden yeni bulguların bulunduğu yer tam olarak o sınıftır.
Kanıt matrisi (Evidence matrix)
| Sinyal | Neyi kanıtlar | Negatif kontrol | Savunucu doğrulaması |
|---|---|---|---|
| Eski ve düzeltilmiş artifact’lerin kayıtlı sürümleri ve hash’leri mevcuttur | Karşılaştırma tekrarlanabilirdir ve bir paketleme uyuşmazlığından ibaret değildir | İki özdeş derlemeyi diff edin ve güvenlikle ilgili hiçbir deltanın çıkmamasını bekleyin | Analizle birlikte kökeni (provenance), sembolleri, derleyici metadatasını ve hash’leri saklayın |
| Küçük bir değişen fonksiyon, yeni bir doğrulama veya sınır kontrolü getirir | Yama, üreticinin güvensiz kabul ettiği koşula işaret eder | Değiştirilen dala hiçbir zaman ulaşmayan bir girdiyi çalıştırın | Binary deltasını kaynak kodu düzeyindeki davranışa veya eşdeğer bir kontrol akışı (control-flow) izine geri eşleyin |
| Eski derleme minimum tetikleyiciyi kabul ederken düzeltilmiş derleme reddeder | Delta yalnızca uygulama biçimini değil, güvenlik davranışını da değiştirir | Yakın bir geçerli girdiyi her iki sürümde de başarıyla çalıştırın | Her iki sürümü de aynı test düzeneğinde (harness) test edin ve yanıt, çökme veya durum farkını kaydedin |
| Kardeş çağrı noktaları yama öncesi deseni tekrarlar | Kök neden tek bir CVE örneği değil, bir hata sınıfı olabilir | Yamalanmış/korunmuş kardeşlerin tetikleyiciyle eşleşmediğini doğrulayın | Semantik varyantları arayın ve her birini aynı pozitif ve negatif kontrollerle triyaj edin |
Sürekli gördüğüm model
Patch diffing’e üreticiye yakın, biraz şüpheli bir pratik gibi yaklaşılır — sanki yayımlanmış bir değişikliği okumak zafiyet araştırmasında bir şekilde “hile yapmakmış” gibi. Oysa tam tersidir. Üretici değişikliği tam olarak insanlar uygulasın diye yayımlamıştır ve yetkin her saldırgan bunu zaten okumaktadır. Araştırmacılar diff yapmadığında kaybeden tek taraf savunmadır; çünkü kök nedeni asla öğrenemez ve dolayısıyla hata sınıfını hiçbir zaman düzeltemez.
Sürekli karşıma çıkan diğer konu ise bunun ne kadarının yalnızca sürüm disiplininden ibaret olduğudur. Çoğu kuruluş hangi binary sürümünü çalıştırdığını söyleyemez; bu da kendilerine haritası çoktan teslim edilmiş zafiyetlerin hangilerine sahip olduklarını bilemeyecekleri anlamına gelir. Yama herkese açıktır. Delta okunabilirdir. Boşluk bilgi eksikliğinde değil, kimsenin okumamasındadır.
Savunuculara teslim edilmesi gerekenler
CVE’yi değil, kök nedeni verin. “CVE-XXXX yamasını uygulayın” diyen bir rapor tek bir örneği kapatır. “Bu uzunluk alanına üç çağrı noktasında güveniliyor, yama bunlardan yalnızca birini düzeltti” diyen bir rapor ise tüm sınıfı kapatır. Diff size ikinci raporu ücretsiz verir ve sonucu değiştiren de tam olarak odur.
Etkilenen sürüm listesi. Patch diffing hangi derlemeye baktığınızı bilmeye dayanır ve çoğu ekip bu listeyi üretemez. Bunu oluşturmak, bu alandaki diğer tüm bulguların ön koşuludur.
Varyant listesi. Aynı desen başka nerede yaşıyor? Kardeş fonksiyonları, diğer ürünleri, üçüncü taraf kütüphaneleri adlandırın. Üreticinin düzeltmesini tek seferlik bir bilet yerine güvenlik duruşunuzda kalıcı bir iyileştirmeye dönüştüren kısım budur.
Yama hiçbir zaman yalnızca bir düzeltme olmadı. Üreticinin size, sahip olduğu en net ifadelerle tam olarak neyi aramanız gerektiğini söylemesiydi.
Bu teknik not ne kadar güncel?
En son kaynak incelemesi, içerik güncellemesi veya yayın tarihi gösterilmektedir.
Yazar teknik incelemeyi tamamladı. Bu etiket tek başına laboratuvar yeniden üretimi iddiası taşımaz.