Hafta 1 — Güvenli Programlamaya Giriş ve Uygulama Koruma Planı¶

Sunumun içine tıklayıp ok tuşlarıyla ilerleyin; tam ekran için sunumun sağ altındaki düğmeyi ya da yukarıdaki "Sunumu tam ekran aç" bağlantısını kullanın.

mkdir C:\Dersler; cd C:\Dersler
git clone https://github.com/ucoruh/cen429-secure-programming.git
cd cen429-secure-programming\code
.\build.ps1
cd week-01\01-path-spoofing
.\demo.ps1

sudo apt install -y build-essential cmake gdb valgrind binutils
git clone https://github.com/ucoruh/cen429-secure-programming.git
cd cen429-secure-programming/code
./build.sh
cd week-01/01-path-spoofing
sh demo.sh

0. Başlamadan önce¶

Bu bölüm haftaya hazırlık içindir. Dersin ilk haftası olduğu için önceki bir konuya dayanmıyoruz: aşağıdaki kavram haritası bu haftanın kavramlarını birer cümleyle tanımlar ve her birini ayrıntılı anlatıldığı bölüme bağlar.

Bu haftanın kavram haritası¶

1. Güvenlik nedir?¶

Güvenlik, bir sistemi ona zarar vermek isteyen kasıtlı bir saldırgana karşı korumaktır; sıradan bir yazılım hatasından farkı, karşısında bilinçli bir düşmanın bulunmasıdır. Bunu somutlaştırmak için bir bankanın kasasını düşünün. Kasanın içindeki para varlıktır. Parayı çalmak isteyen biri tehdittir. Kasanın kilidinin arızalı olması bir zafiyettir. Hırsızın o arızalı kilidi kullanması bir saldırıdır. Risk ise "bu olay ne kadar olası ve olursa ne kadar zarar verir?" sorusunun cevabıdır.

Yazılımda da aynı zincir vardır; yalnız kasanın yerinde program, paranın yerinde veri durur.

Güvenliğin üç hedefi: CIA¶

Güvenlikten söz ettiğimizde neredeyse her zaman şu üç şeyi korumaya çalışırız; bu üçlü birlikte CIA üçlüsü (confidentiality, integrity, availability) olarak anılır:

Bunlara sıklıkla üç kavram daha eklenir: kimlik doğrulama (sen gerçekten o musun?), yetkilendirme (bunu yapmaya iznin var mı?) ve hesap verebilirlik / inkâr edilemezlik (bunu kim yaptı, sonradan inkâr edebilir mi?).

Hata ile zafiyet arasındaki fark¶

Her yazılım hatası bir güvenlik açığı değildir; ama güvenlik açıklarının çok büyük kısmı sıradan yazılım hatalarıdır. Bir hata, bir saldırganın kendi istediği sonucu elde etmesine izin veriyorsa artık bir zafiyettir.

2. Neden "güvenli programlama"?¶

Güvenlik duvarları, antivirüsler, ağ izleme… Bunların hepsi önemlidir; ama hatalı yazılmış bir programı kurtaramazlar. Saldırgan izin verilen kapıdan — yani programın kendisinden — içeri girer. Güvenli programlama, güvenliği sonradan eklenen bir katman olarak değil, kodu yazarken verilen kararlar olarak ele alır:

• Girdiye güvenme; her girdiyi doğrula (uzunluk, tür, aralık, izin verilen karakterler).
• Sırları mümkün olan en kısa süre bellekte tut, işin bitince güvenle sil.
• Programın çalıştığı ortama (ortam değişkenleri, dosya izinleri, çağırdığı programlar) güvenme.
• Hata olursa güvenli tarafta kal: reddet, kapat, sızdırma.
• Derleyicinin ve işletim sisteminin sunduğu korumaları aç ve araçlarla (sanitizer, fuzzing) sına.

Dönem boyunca bu ilkeleri önce C/C++'ta, sonra Java'da; ardından "program saldırganın elindeyse" dünyasında (çalışma zamanı koruması, kod gizleme, whitebox kriptografi) uygulayacağız.

3. Saldırgan kim, neye erişebiliyor?¶

Bir güvenlik önlemini değerlendirmenin ilk sorusu şudur: "Kime karşı?" Aynı önlem bir saldırgana karşı yeterli, başka birine karşı işe yaramaz olabilir. Bu yüzden her projede önce saldırgan modeli yazılır.

4. Güvenli tasarımın temel ilkeleri¶

1975'te Saltzer ve Schroeder'in yazdığı ilkeler bugün de güvenli tasarımın omurgasıdır. Her birini tek cümlelik bir örnekle aklınızda tutun:

Bunlara modern bir ilke ekleyelim: Derinlemesine savunma (defense in depth). Tek bir önleme güvenmeyiz; birbirini tamamlayan katmanlar kurarız. Biri aşılırsa diğeri devreye girer. 3. haftada hassas bir anahtarın tam dört ayrı koruma katmanı (güvenlik kabuğu) içinde nasıl taşındığını göreceğiz.

5. Uygulama korumasına genel bakış: katmanlı savunma haritası¶

Buraya kadar güvenliğin ne olduğunu ve kime karşı korunduğunu konuştuk. Şimdi dönemin geri kalanında kullanacağımız araç kutusunun haritasını çıkaralım. "Uygulama koruması" (application protection) tek bir teknik değil, birbirini tamamlayan katmanlar bütünüdür. Her katman farklı bir soruyu cevaplar ve farklı bir saldırgan yeteneğine karşı durur.

Neden tek bir önlem yetmez?¶

Bir binayı düşünün. Kapıya iyi bir kilit taktınız. Ama pencere açıksa, anahtar paspasın altındaysa ya da içerideki kasa şifresizse kilit tek başına bir şey ifade etmez. Yazılımda da durum aynıdır:

• Kodunuz hatasız olabilir, ama saldırgan binary dosyayı açıp mantığınızı okuyabilir.
• Mantığınızı gizleyebilirsiniz, ama saldırgan programı çalışırken bir hata ayıklayıcıyla durdurup belleğini okuyabilir.
• Belleği izlenmeye karşı koruyabilirsiniz, ama anahtar kodun içinde düz metin duruyorsa bir dize taraması yeter.
• Anahtarı gizleyebilirsiniz, ama saldırgan binary dosyadaki bir denetimi değiştirip (ör. "lisans geçerli mi?" sorusunu her zaman "evet" yapıp) korumayı tamamen atlayabilir.

Her satır, bir önlemin neyi çözmediğini gösteriyor. Katmanlı savunmanın mantığı budur: her katman bir öncekinin açık bıraktığı yolu kapatır; saldırganın hepsini aynı anda aşması gerekir ve bu da maliyeti katlar.

Yedi katman¶

Aşağıdaki şema, bu dönem göreceğimiz katmanları içten dışa sıralar. İç katmanlar "kodu doğru yaz" sorusuyla, dış katmanlar "kod saldırganın elindeyken ne olacak?" sorusuyla ilgilenir.

Hangi katman ne zaman önemlidir? Saldırgan modeline göre seçim¶

Her uygulamanın yedi katmanın hepsine eşit ihtiyacı yoktur. Seçimi, 3. bölümde tanımladığımız saldırgan modeli belirler:

Burada kritik ayrım şudur: sunucu tarafında kodunuz sizin kontrolünüzdeki bir makinede çalışır; saldırgan yalnız girdileri kontrol eder. İstemci tarafında (telefon, masaüstü, oyun konsolu) ise saldırgan programın kendisine sahiptir: onu kopyalayabilir, açabilir, değiştirebilir, istediği kadar yeniden çalıştırabilir. Bu modele "beyaz kutu" (white-box) saldırgan denir ve 4, 5, 6 numaralı katmanlar tam olarak bu saldırgan için vardır.

Beyaz kutu saldırganın altı yolu¶

İstemci tarafında çalışan hassas bir kütüphanenin güvenlik kılavuzu, saldırganın hedeflerini genellikle altı satırlık bir saldırı tablosuyla özetler. Her satır, katmanlardan en az birinin cevap vermesi gereken bir sorudur:

Bu tablo, koruma planındaki tehdit bölümünün başlangıç noktasıdır: her varlık için bu altı yolun her birinin nasıl kapatıldığı yazılır.

Aynı gereksinim setinde iki madde daha, katmanlı savunmanın neden zorunlu olduğunu açıkça söyler:

• Uygulama, güvencesi olmayan güvenlik işlevlerine tek başına dayanmamalıdır: işletim sisteminin korumaları, anahtar zinciri, uygulama kum havuzu ya da donanım destekli anahtar deposu gibi özellikler cihazdan cihaza değişir ve saldırgan tarafından devre dışı bırakılabilir.
• Platformun sunduğu mekanizmalar (ör. işletim sisteminin kripto kütüphanesi) kullanılabilir, ama yalnız uygulamanın kendi korumalarına ek olarak.

Savunmacı programlama da aynı listede tek tek sayılır: her girdi ve çıktı denetlenir; varlıklar mümkün olan en kısa süre işlenir; varlıklar kod içindeki arayüzlerden bile açık halde geçirilmez; zamanlamaya dayalı ilişkilendirme saldırılarına karşı gecikmeler eklenir; iş bitince veriyi silen güvenli bir silme fonksiyonu kullanılır. Bu kuralların hepsini dönem boyunca tek tek uygulayacağız.

Korumanın maliyeti: her katmanın bir bedeli var¶

Katman eklemek bedava değildir; güvenlik, hız ve karmaşıklık arasında sürekli bir ödünleşim (trade-off) kurmayı gerektirir — hedef sonsuz koruma değil, dengeli koruma ve açıkça yazılmış bir kalan risktir. Bir koruma planı yazarken her katman için şu dört bedeli tartarsınız:

1. Performans: Gizlenmiş kod daha yavaş çalışır (ör. kontrol akışı düzleştirme bir fonksiyonu birkaç kat yavaşlatabilir). Bütünlük denetimi ve hata ayıklayıcı algılama da işlemci zamanı harcar.
2. Boyut: Gizleme, sanallaştırma ve tablo tabanlı whitebox kriptografi binary dosyayı büyütür.
3. Geliştirme ve bakım: Gizlenmiş kodun hatası zor ayıklanır; çökme raporları okunaksız olur. Bu yüzden gizleme yalnız hassas bölümlere uygulanır ve sembol eşleme dosyaları güvenli yerde saklanır.
4. Yanlış pozitif: Aşırı hassas bir root ya da emülatör algılaması, meşru kullanıcıyı (ör. geliştirici seçenekleri açık bir telefonu) cezalandırabilir.

Bu yüzden bir koruma planında her önlem gerekçesiyle yazılır: "Şu varlığı, şu saldırgana karşı, şu maliyetle koruyoruz." Gerekçesi yazılmamış bir önlem ya gereksizdir ya da yanlış yerdedir.

Dönem boyunca izleyeceğimiz yol¶

Bu haritayı her hafta bir katmanı açarak dolduracağız:

Kendini dene¶

1. Bir çevrimdışı parola yöneticisi (tüm veriler kullanıcının bilgisayarında) için saldırgan modeli nedir? Yedi katmandan hangileri en önemlidir? Neden?
2. "Uygulamamız sunucuda çalışıyor, gizlemeye gerek yok" cümlesi hangi durumda doğrudur, hangi durumda yanlıştır?
3. Bir oyun şirketi hile yapılmasını engellemek için yalnız gizleme kullanıyor. Hangi saldırı yolu açık kalır?

6. Uygulama koruma planı¶

Bir yazılımın güvenliği şansa bırakılmaz; yazılı bir planla yönetilir. Bağımsız bir laboratuvarın güvenlik sertifikasyonundan geçen ürünlerde bu plan, yüzlerce sayfalık bir güvenlik kılavuzuna dönüşür. Bu derste siz de dönem projeniz için bunun küçük bir sürümünü yazacaksınız. Planın omurgası şudur:

Plan bir kez yazılıp bırakılmaz: ürün her değiştiğinde (yeni özellik, hata düzeltmesi, yeni sürüm) 1. adıma dönülür ve plan güncellenir.

1. Kapsam: Neyi değerlendiriyoruz? Yalnız "sürüm 2.1" demek yetmez; hangi binary dosya, hangi kaynak kod, hangi özet değeri? Sertifikasyonda buna değerlendirme hedefi denir.
2. Mimari ve arayüzler: Bileşenler neler, birbirleriyle hangi kanaldan konuşuyor, her kanalda kimlik nasıl doğrulanıyor?
3. Varlıklar: Korunacak her veri tek tek listelenir: nerede durur, ne zaman oluşur, ne zaman silinir, gizlilik (C) mi bütünlük (I) mü gerekir?
4. Tehditler: Saldırgan kim (bkz. bölüm 3), her varlığa hangi yoldan ulaşabilir?
5. Karşı önlemler: Her tehdit için hangi önlem, hangi katmanda?
6. Doğrulama: Her önlemin çalıştığı nasıl kanıtlanıyor — birim testi, atlatma denemesi?
7. Kalan risk: Kapatılamayan ya da bilerek kabul edilen riskler ve nedenleri (ör. performans).

Planın iki temel aracı: arayüz tablosu ve varlık tablosu¶

Planın 2. ve 3. adımları iki tabloyla yazılır; bu derste bütün dönem boyunca aynı yöntemi kullanacağız. Yöntemi bir örnek mimari üzerinde görelim: telefonun NFC'si üzerinden temassız ödeme yapan bir mobil uygulama ve onun kritik işlerini yapan bir güvenlik kütüphanesi. Kütüphanenin bir kısmı Java'da, güvenlik açısından en hassas kısmı ise C/C++ ile yazılmış yerel (native) katmanda çalışır.

Bu şemada iki şeye dikkat edin:

• Telefon kutusunun başlığı "güvenilmez ortam". Telefon, kullanıcının — yani potansiyel saldırganın — elinde. Root yetkisi alınmış olabilir, hata ayıklayıcı bağlanmış olabilir. Bu yüzden tasarım baştan "telefona güvenmiyorum" varsayımıyla yapılır.
• Harflerle gösterilen her ok bir arayüzdür. Her arayüz için şu tablo doldurulur:

Ve varlık tablosundan bir kesit (değerler sentetiktir):

7. Tehdit modelleme: STRIDE ve saldırı ağaçları¶

Tehdit modelleme, "saldırgan olsaydım buraya nasıl saldırırdım?" sorusunu düzenli biçimde sormaktır. En yaygın yöntemlerden biri Microsoft'un geliştirdiği STRIDE'dır: her harf bir tehdit ailesi ve bozduğu güvenlik özelliğidir.

Uygulaması basittir: sistemin veri akış diyagramını çizin (dış varlıklar, süreçler, veri depoları, veri akışları ve güven sınırları), sonra her öğe için altı harfi tek tek sorun. Güven sınırını geçen her ok, en çok tehdidin çıktığı yerdir.

Saldırı ağacı¶

Saldırı ağacında kök, saldırganın hedefidir; alt dallar o hedefe ulaşmanın yollarıdır. VEYA düğümünde dallardan biri yeter, VE düğümünde hepsi gerekir. Ağaç çizildiğinde en ucuz yol ve savunulacak kilit noktalar kendiliğinden ortaya çıkar.

Bu ağaçtan hemen şu sonuçlar çıkar: (1) C yolu iki katmanı birden kırmayı gerektirdiği için pahalıdır — işte derinlemesine savunma. (2) B yolunun üç alternatifi var; demek ki bellekteki anahtar en zayıf nokta ve buna karşı özel önlemler (bu hafta Demo 2, 6. hafta çalışma zamanı koruması, 11. hafta whitebox) gerekir.

Aşağıdaki animasyon aynı fikri biraz genişletilmiş bir ağaçta (4 dal, 11 yaprak) sayısal olarak hesaplıyor: her VE/VEYA düğümünün maliyeti nasıl aşağıdan yukarı hesaplanır, en ucuz yol hangisidir?

Örnek seçiciden payment-key, license-check (kök VE) ve iki uç durumu (zorunlu iki katman / her düğüm VE) deneyin; 🎲 ile kendi ağacınızı da değerlendirebilirsiniz.

8. Tehdit modellemeyi derinleştirmek: veri akış diyagramı, STRIDE ayrıntıları ve risk puanı¶

Önceki bölümde STRIDE'ı ve saldırı ağacını tanıdık. Bu bölümde yöntemi bir mühendis gibi adım adım uygulamayı öğreneceğiz: diyagramı nasıl çizeriz, her öğeye hangi harfleri sorarız, çıkan onlarca tehdidi nasıl sıralarız?

Veri akış diyagramının (VAD) dört öğesi ve güven sınırı¶

Tehdit modellemede kullanılan diyagram, yazılım mühendisliği derslerinden bildiğiniz veri akış diyagramının sadeleştirilmiş halidir. Yalnız beş sembol vardır:

Güven sınırı kavramı yöntemin kalbidir. Bir veri, güven sınırını geçtiği anda "öbür taraftan gelen veri" olur ve doğrulanmadan kullanılamaz. Tehditlerin çoğu bu geçişlerde doğar. Pratik bir kural: diyagramınızda güven sınırını geçen her oku kırmızıyla boyayın; incelemeye oradan başlayın.

Hangi öğeye hangi harf sorulur?¶

Her öğe altı tehdidin hepsine açık değildir. Microsoft'un yaygınlaştırdığı "öğe başına STRIDE" tablosu, hangi soruların anlamlı olduğunu gösterir:

¹ Veri deposu bir denetim kaydıysa (log), inkâr tehdidi de sorulur: kayıt silinirse ya da değiştirilirse kimin ne yaptığı kanıtlanamaz.

Aşağıdaki animasyon bu tabloyu küçük bir sistemin (öğrenci not sistemine benzer, 12 öge) üzerinde öge öge uygular: her öge için altı harfin hangilerinin anlamlı olduğunu, nedenini açıklayarak gösterir.

Örnek seçiciden grade-system, password-vault ve iki uç durumu (hepsi veri akışı / hepsi dış varlık) deneyin; 🎲 ile kendi karışık sisteminizi de üretebilirsiniz.

Tablonun mantığı sezgiseldir: bir veri akışı (ör. ağ paketi) kimlik taklidi yapamaz, çünkü bir "kimliği" yoktur; ama dinlenebilir (I), değiştirilebilir (T) ya da kesilebilir (D). Bir süreç ise altı tehdide de açıktır: taklit edilebilir, kodu değiştirilebilir, belleği okunabilir, çökertilebilir, yetkisi kötüye kullanılabilir.

Her harf için sorulacak sorular ve tipik karşı önlemler¶

Tehditleri sıralamak: olasılık × etki¶

Orta büyüklükte bir sistemde tehdit modelleme kolayca 50–100 tehdit üretir. Hepsini aynı anda kapatamazsınız. Bu yüzden her tehdide bir risk puanı verilir. En sade yöntem, olasılık ve etkiyi 1–3 arasında puanlayıp çarpmaktır:

Aşağıdaki animasyon bir parola kasası uygulamasının 12 tehdidini bu matrise tek tek yerleştirir, sonra hepsini puana göre sıralar:

Örnek seçiciden vault, terminal ve iki uç durumu (hepsi kritik / hepsi düşük) deneyin; 🎲 ile kendi tehdit listenizi de puanlayabilirsiniz.

Olasılığı belirlerken saldırganın ihtiyaç duyduğu şeyleri sorun: fiziksel erişim mi gerekiyor, yoksa internetten mi yapılabilir? Özel araç ya da uzmanlık gerekiyor mu? Saldırı otomatikleştirilebilir mi? Etkiyi belirlerken varlık tablosuna dönün: hangi varlık etkileniyor, kaç kullanıcı etkileniyor, parasal ya da hukuki sonucu nedir?

Tehdide verilebilecek dört yanıt¶

Her tehdit için dört seçenekten birini bilinçli olarak seçer ve plana yazarsınız:

1. Azalt (mitigate): Bir karşı önlem ekle. En sık seçilen yanıt.
2. Ortadan kaldır (eliminate): Tehdide yol açan özelliği tamamen kaldır. Ör. "parolayı hatırla" özelliği gerekli değilse hiç yazmamak, parolanın diskte saklanması tehdidini sıfırlar. En güçlü yanıttır.
3. Aktar (transfer): Riski bir başkasına devret. Ör. kart verisini hiç saklamayıp ödeme hizmet sağlayıcısına bırakmak ya da bir sigorta.
4. Kabul et (accept): Riski bilerek üstlen ve gerekçesini yaz. Ör. "Fiziksel olarak çipin açılıp incelenmesine karşı önlem almıyoruz; bu saldırının maliyeti korunan değerden yüksektir."

9. Uygulamalı örnek: bir koruma planını adım adım yazmak¶

Şimdi önceki üç bölümdeki bütün araçları küçük bir uygulama üzerinde, baştan sona uygulayalım. Bu örnek, dönem projenizin ilk teslimi için bir şablon görevi görecek.

Adım 0 — Uygulamayı tanımla¶

"Kasa", C++ ile yazılmış, masaüstünde çalışan bir parola kasası olsun:

• Kullanıcı bir ana parola belirler. Kasa, içindeki kayıtları (site adı, kullanıcı adı, parola) bu ana paroladan türetilen bir anahtarla şifreleyip tek bir dosyada saklar.
• Kullanıcı bir kaydın parolasını panoya kopyalayabilir.
• İsteğe bağlı olarak şifreli kasa dosyası bir yedekleme sunucusuna gönderilebilir.
• Uygulama, yeni sürümleri bir güncelleme sunucusundan indirir.

Adım 1 — Kapsam¶

"Kapsam dışı" satırı önemlidir: neyi korumadığınızı açıkça yazmak, neyi koruduğunuzu yazmak kadar değerlidir.

Adım 2 — Mimari ve arayüzler¶

Adım 3 — Varlıklar¶

"Koruma" sütununda dört değer kullanılır: C (gizlilik), I (bütünlük), I+ (bütünlüğe ek olarak hesap verebilirlik ve kimlik doğrulama: verinin kimden geldiğinin de doğrulanması gerekir; sahada bunu sunucuyla paylaşılan bir kimlik doğrulama kodu sağlar) ve N (koruma gerekmez). Sahada kullanılan varlık tabloları bunlara ek olarak her varlığın boyutunu, değerinin kaynağını, varsayılan değerini ve hangi tabloda ya da dosyada durduğunu da yazar; statik, dinamik ve kriptografik varlıklar ayrı tablolarda listelenir.

Adım 4 — Tehditler (STRIDE, arayüz arayüz)¶

Adım 5 — Karşı önlemler¶

Adım 6 — Doğrulama planı¶

Her önlem için "çalıştığını nasıl kanıtlarım?" sorusunun cevabı yazılır. Bir önlemin testi yoksa, o önlem değerlendirici gözünde yok sayılır.

Adım 7 — Kalan risk¶

Sık yapılan hatalar¶

• Varlıkları unutmak: Yalnız "kullanıcı verisi" yazıp anahtarları, belirteçleri, sayaçları, yapılandırma dosyalarını ve kodun kendisini (bütünlüğü korunacak bir varlıktır) listelememek.
• Güven sınırını yanlış çizmek: Kendi yazdığınız istemci uygulamasını "güvenilir" kutusuna koymak. İstemci, kullanıcının makinesinde çalışıyorsa güvenilmezdir.
• Önlemi tehditle eşleştirmemek: "TLS kullanıyoruz" demek, TLS'in hangi tehdidi kapattığını (dinleme ve değiştirme) ve hangisini kapatmadığını (sunucudaki veri, istemcinin kendisi) söylemeden eksiktir.
• Testsiz önlem: "Parolayı bellekten siliyoruz" deyip derleyicinin bu silme işlemini kaldırıp kaldırmadığını hiç denetlememek (bu haftanın Demo 2'si tam olarak budur).

10. Program başlarken: güvenilmeyen ortam¶

Bir program çalışmaya başladığında boş bir sayfayla başlamaz. Onu çalıştıran kişiden birçok şey devralır: ortam değişkenleri (PATH, LD_PRELOAD, IFS...), açık dosya tanıtıcıları, çalışma dizini, umask, kaynak sınırları. Program bunlara güvenirse, onları kontrol eden kişi programın davranışını da kontrol eder. Kaynak kitabımızın ilk bölümü (Viega & Messier, tarif 1.1–1.9) tam olarak bu "güvenli başlatma" konusunu işler.

Demo 1 — PATH ile kandırma¶

Kabuk bir komutu mutlak yolu olmadan çağırdığınızda, programı PATH değişkenindeki klasörlerde soldan sağa arar ve ilk bulduğunu çalıştırır:

Windows'ta durum daha da kötüdür: cmd.exe komutu PATH'ten önce çalışma klasöründe arar ve .bat, .cmd gibi uzantıları da dener. Programı hangi klasörden çalıştırdığınız bile hangi dosyanın çalışacağını değiştirir.

Hatalı kod:

#ifdef _WIN32
#define COMMAND "hostname"
#else
#define COMMAND "date"
#endif

int main(void)
{
    printf("=== Monthly Sales Report ===\n");
    fflush(stdout);

    /* BUG: bare command name + shell + inherited environment (PATH, ...) */
    int status = system(COMMAND);
    ...
}

Demoyu çalıştırın:

cd code\week-01\01-path-spoofing
.\demo.ps1

cd code/week-01/01-path-spoofing
sh demo.sh

STEP 1 - Normal run: the program finds the real date
=== Monthly Sales Report ===
Report date: Sat Sep 26 12:05:45 +03 2026

STEP 2 - Attack: the fake/ folder is added to the front of PATH
$ PATH="$PWD/fake:$PATH" ./bin/linux/report
=== Monthly Sales Report ===
Report date:
  !!! FAKE 'date' ran !!!
  The program was fooled through PATH. ...

STEP 3 - The fixed version under the same attack
=== Monthly Sales Report ===
Report date: Sat Sep 26 12:05:45 +03 2026

Sahte date burada yalnız bir mesaj basıyor. Gerçek bir saldırgan aynı noktada programı çalıştıran kişinin bütün yetkileriyle istediği her şeyi yapabilirdi. Program yüksek yetkiyle çalışıyorsa (ör. bir sistem servisi), bu doğrudan yetki yükseltmedir.

Düzeltilmiş kod üç şeyi birden yapar: 1) mutlak yol, 2) kabuk yok, 3) küçük, bilinen ortam.

char *const args[]      = { "date", NULL };
char *const clean_env[] = { "PATH=/usr/bin:/bin", "LANG=C", NULL };

pid_t pid;
int err = posix_spawn(&pid, "/bin/date", NULL, NULL,
                      args, clean_env);

/* 1) C:\Windows\System32\hostname.exe — tam yol */
GetSystemDirectoryW(system_dir, MAX_PATH);
swprintf(program_path, MAX_PATH, L"%ls\\hostname.exe", system_dir);

/* 3) ortam bloğunda yalnız SystemRoot */
swprintf(env_block, MAX_PATH + 16, L"SystemRoot=%ls", sys_root);

/* 2) cmd.exe yok: program doğrudan başlatılır */
CreateProcessW(program_path, cmd_line, NULL, NULL, FALSE,
               CREATE_UNICODE_ENVIRONMENT, env_block, NULL, &si, &pi);

Aşağıdaki animasyonda kabuğun PATH dizinlerini sırayla nasıl denediğini ve sahte programın nerede kazandığını adım adım izleyin.

Örnek seçiciden saldırı yok (normal), sahte dizin PATH'in başına eklendi (zor) ve uç durumlar sahte dizin ortada ama yine de kazanıyor ile güvenli sürüm — mutlak yol, arama yok'u deneyin — ya da 🎲 ile rastgele bir PATH listesi üretin, ya da kendi dizin listenizi yazın (dizin:real / dizin:fake işaretleriyle, ya da ABSOLUTE date /bin/date ile mutlak-yol sürümünü deneyin).

11. Güvenli başlatma: programın ilk satırlarında yapılacaklar¶

Demo 1, programın devraldığı tek bir ortam değişkeninin (PATH) bütün güvenliği nasıl altüst ettiğini gösterdi. PATH tek tehlike değildir. Kaynak kitabımızın birinci bölümü (Tarif 1.1–1.9), bir programın main() fonksiyonunun ilk satırlarında yapması gerekenleri sıralar. Bu bölümde o listeyi bugünün sistemlerine göre güncelleyip adım adım işleyeceğiz.

Program başladığında elinde ne var?¶

Bir süreç exec ile başlatıldığında (Windows'ta CreateProcess) şu durumu ebeveyninden devralır:

Kural basittir: programın kendisinin kurmadığı hiçbir şeye güvenme. Programın ilk işi, bu devralınan durumu bilinen ve güvenli bir duruma getirmektir.

Adım 1 — Ortamı temizle (Tarif 1.1)¶

İki yaklaşım vardır: kötü değişkenleri tek tek silmek (kara liste) ya da ortamı tamamen boşaltıp gerekenleri yeniden kurmak (beyaz liste). Kara liste her zaman eksik kalır, çünkü yarın hangi değişkenin tehlikeli olacağını bilemezsiniz. Doğru olan beyaz listedir:

#include <stdlib.h>
#include <string.h>

static void sanitize_environment(void)
{
    const char *tz = getenv("TZ");          /* copy the variable to keep, first */
    char tz_copy[64] = "";
    if (tz && strlen(tz) < sizeof tz_copy)
        strcpy(tz_copy, tz);

    clearenv();                              /* glibc-specific; not portable (see below) */
    setenv("PATH", "/usr/bin:/bin", 1);      /* known, non-writable directories */
    if (tz_copy[0])
        setenv("TZ", tz_copy, 1);
}

Bir değişkeni kullanmanız gerekiyorsa (ör. kullanıcının HOME'u), ona bir girdi gibi davranın: uzunluğunu sınırlayın, beklenen biçimde olduğunu doğrulayın (Tarif 3.6). Windows'ta ortam aynı şekilde devralınır; orada PATH'in yanında DLL arama sırası da tehlikedir (aşağıda Adım 6).

Adım 2 — Dosya tanıtıcılarını düzenle (Tarif 1.5)¶

İki ayrı sorun vardır:

1. 0, 1, 2 kapalıysa: Saldırgan programı standart çıktısı kapalı olarak başlatır. Programın açtığı ilk dosya (ör. parola dosyası) tanıtıcı 1'i alır. Sonraki her printf, o dosyanın içine yazar.
2. Fazladan açık tanıtıcılar: Ebeveyn, close-on-exec işaretlemeden açık bıraktığı bir dosyayı ya da soketi çocuğa devreder. Çocuk bu tanıtıcıyla, normalde erişemeyeceği bir kaynağa erişebilir.

#include <fcntl.h>
#include <unistd.h>
#include <stdlib.h>

static void sanitize_file_descriptors(void)
{
    for (int fd = 0; fd <= 2; fd++) {
        if (fcntl(fd, F_GETFD) == -1) {           /* closed? */
            int new_fd = open("/dev/null", O_RDWR);
            if (new_fd != fd)                        /* must get exactly that number */
                abort();
        }
    }
    /* Linux 5.9+ / glibc 2.34+: close 3 and above in one call */
    close_range(3, ~0U, 0);
}

Daha eski sistemlerde sysconf(_SC_OPEN_MAX)'a kadar döngüyle close() çağrılır; sınır çok büyükse (ör. bir milyon) bu yavaş olabilir, close_range bu yüzden eklendi. Kendi açtığınız dosyalarda ise her zaman O_CLOEXEC bayrağını kullanın; böylece ileride başlatacağınız bir alt sürece sızmazlar.

Adım 3 — Yeni dosyaların iznini daralt (Tarif 2.7)¶

#include <sys/stat.h>
umask(077);     /* new files open only to the owner: rw------- */

umask bir maskedir: open()'a verdiğiniz izinlerden maskedeki bitler çıkarılır. 077 ile grup ve diğerleri için hiçbir bit kalmaz. Yine de hassas dosyayı açarken izni açıkça yazın: open(path, O_WRONLY | O_CREAT | O_EXCL, 0600). O_EXCL, dosya zaten varsa (ör. saldırganın önceden oluşturduğu bir bağlantıysa) açmayı reddeder; 2. haftadaki TOCTOU demosunu hatırlayın.

Adım 4 — Çökme dökümünü kapat (Tarif 1.9)¶

Program çöktüğünde işletim sistemi, hata ayıklamaya yardım etsin diye sürecin bütün belleğini bir dosyaya yazabilir. O bellekte parola, anahtar ve çözülmüş veri varsa, hepsi diskte düz metin olarak kalır. Demo 2'deki parola tam olarak böyle bulunabilir.

#include <sys/resource.h>
#include <sys/prctl.h>

static void disable_core_dump(void)
{
    struct rlimit r = { 0, 0 };
    setrlimit(RLIMIT_CORE, &r);            /* core dump size 0 */
    prctl(PR_SET_DUMPABLE, 0, 0, 0, 0);    /* no dump; not even the same user can attach via ptrace */
}

#include <windows.h>

static void disable_core_dump(void)
{
    /* Close the crash dialog and critical-error dialogs */
    SetErrorMode(SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX);
}

Adım 5 — Gereksiz yetkiyi bırak (Tarif 1.2–1.4)¶

Programınız bir işi yapmak için geçici olarak yüksek yetki gerektiriyorsa (ör. 1024'ün altındaki bir portu açmak), o işi yaptıktan hemen sonra yetkiyi kalıcı olarak bırakmalıdır.

#include <unistd.h>
#include <stdlib.h>

static void drop_privileges(void)
{
    uid_t u = getuid();
    gid_t g = getgid();

    if (setresgid(g, g, g) != 0) abort();   /* group first: afterward we no longer have permission to change it */
    if (setresuid(u, u, u) != 0) abort();   /* all three: real, effective and saved identity */

    uid_t r, e, s;
    getresuid(&r, &e, &s);
    if (r != u || e != u || s != u) abort();  /* VERIFY that it was actually dropped */
}

Üç ayrıntı hayatidir: (1) önce grup, sonra kullanıcı bırakılır; kullanıcıyı önce bırakırsanız grubu değiştirecek yetkiniz kalmaz. (2) Yalnız etkin kimliği değiştiren seteuid() geçicidir; saklı kimlik yetkili kalır ve yetki geri alınabilir (2. hafta Demo 13). (3) Bırakma işleminin sonucu mutlaka doğrulanır; dönüş değeri denetlenmeyen bir setuid() çağrısı gerçek hatalara yol açmıştır.

Windows'ta aynı fikir kısıtlanmış belirteç (restricted token) ile uygulanır: CreateRestrictedToken ile yönetici gruplarını ve ayrıcalıkları çıkarılmış bir belirteç oluşturulur ve riskli iş o belirteçle çalışan bir alt süreçte yapılır (Tarif 1.2). Daha güçlü bir yaklaşım ayrıcalık ayrımıdır (Tarif 1.4): programı, yetki gerektiren küçük bir parça ile yetkisiz çalışan büyük bir parça olarak iki sürece bölmek. Bir tarayıcının her sekmeyi yetkisiz bir "kum havuzu" (sandbox) sürecinde çalıştırması bu fikrin bugünkü halidir.

Adım 6 — Başka program ve kütüphane yüklerken dikkat (Tarif 1.6–1.8)¶

Windows'taki DLL arama sırası sorunu, PATH sorununun ikizidir: program, istediği kütüphaneyi saldırganın bıraktığı bir klasörde bulursa o kütüphanenin kodu, programın yetkisiyle çalışır (CWE-427).

Hepsi bir arada: secure_startup()¶

int main(int argc, char **argv)
{
    sanitize_file_descriptors();   /* Step 2 — Windows: not needed, descriptors are not inherited by default */
    sanitize_environment();        /* Step 1 — Windows: SetDefaultDllDirectories + PATH validation */
    umask(077);                    /* Step 3 — Windows: create the file explicitly with a restricted DACL */
    disable_core_dump();           /* Step 4 — Windows: SetErrorMode */
    drop_privileges();             /* Step 5 — Windows: restricted token / separate process */

    /* ... the program's actual work ... */
    return 0;
}

Sıralama rastgele değildir: tanıtıcılar ve ortam, programın başka hiçbir şey yapmadan önce düzenlenmelidir; çünkü sonraki her adım (ör. bir hata iletisi yazmak) bunlara dayanır.

Aşağıdaki animasyon devralınan tehlikeli bir ortamı (12 değişken) ve tanıtıcı/umask/döküm/yetki durumunu alıp secure_startup()'ın beş adımını sırayla uygular; sonunda kaç değişkenin hayatta kaldığını gösterir.

Örnek seçiciden workstation, server ve iki uç durumu (hiçbiri tehlikeli değil / hepsi tehlikeli) deneyin; 🎲 ile kendi devraldığınız ortamı da temizleyebilirsiniz.

12. Bellekte kalan sırlar¶

Bir parolayı kullandıktan sonra ne olur? Değişken kapsam dışına çıkar ama bellek silinmez; o baytlar üzerine başka bir şey yazılana kadar orada durur. Bir saldırgan o belleği görebilirse sırrı okur. Belleğin görülebildiği durumlar sandığınızdan çoktur:

• Program çöktüğünde oluşan çökme dökümü (core dump) dosyası,
• İşletim sisteminin belleği diske yazdığı takas alanı (swap) ve uyku (hibernation) dosyası,
• Bir hata ayıklayıcının sürece bağlanması,
• Aynı belleği sonradan kullanan başka bir kod parçasının eski içeriği okuması.

Demo 2 — Bellekte kalan parola¶

unsigned long log_in(const char *file)
{
    char password[64];
    /* low-level read: the password lives only in this array */
    int fd = file_open(file);
    int n = (int)file_read(fd, password, sizeof(password) - 1);
    ...
    unsigned long key = derive_key(password, (size_t)n);

#if WIPE == 1
    memset(password, 0, sizeof(password));         /* "dead store" */
#elif WIPE == 2
  #ifdef _WIN32
    SecureZeroMemory(password, sizeof(password));  /* cannot be removed */
  #else
    explicit_bzero(password, sizeof(password));    /* cannot be removed */
  #endif
#endif
    return key;
}

cd code\week-01\02-password-in-memory
.\demo.ps1

cd code/week-01/02-password-in-memory
sh demo.sh

STEP 1 - Version that never wipes the password
  RESULT: password FOUND in the dump in 1 place(s)  ->  Secret-Password-2026

STEP 2 - Version that wipes with memset (-O2)
  RESULT: password FOUND in the dump in 1 place(s)  ->  Secret-Password-2026

STEP 3 - Version that wipes with explicit_bzero (-O2)
  RESULT: password not found in the dump

Why? machine code of the log_in() function:
  number of wipe instructions in the memset version    ->  0
  explicit_bzero calls in the explicit version         ->  1

İkinci adım şaşırtıcıdır: kodda açıkça memset yazıyor, ama parola hâlâ bellekte! Nedeni derleyicinin optimizasyonudur. Derleyici şöyle düşünür: "password dizisi bu satırdan sonra hiç okunmuyor; ona sıfır yazmanın programın sonucuna hiçbir etkisi yok. Öyleyse bu yazma gereksiz, silebilirim." Buna kullanılmayan yazmanın silinmesi (dead store elimination) (dead store elimination) denir. Normal programlarda hız kazandıran bu optimizasyon, güvenlik kodunda sırrın bellekte kalmasına yol açar. Bu yalnız GCC'ye özgü değildir: Windows'ta MSVC /O2 ile de aynı sonuç çıkar. Makine koduna kendiniz bakın: Linux'ta objdump -d bin/linux/password_memset | less ile log_in'i arayın; Visual Studio'da log_in'e kesme noktası koyup Hata Ayıkla > Pencereler > Ayrıştırılmış Kod (Disassembly) penceresini açın. memset'e ait tek bir komut bile yoktur.

Aşağıdaki animasyon aynı 64 baytlık password[] dizisini üç WIPE modunda da gösterir: bayt bayt yazılır, sonra silinmeye çalışılır (ya da çalışılmaz) — dökümde ne kalır?

Örnek seçiciden memset-surprise (WIPE=1, şaşırtıcı sonuç), never-wipes (WIPE=0) ve explicit-bzero-fix (WIPE=2, gerçek düzeltme) örneklerini deneyin.

13. Süreç belleği: verileriniz nerede duruyor?¶

Taşma hatalarını anlamak için önce bir programın belleğinin nasıl düzenlendiğini bilmemiz gerekir. Linux'ta çalışan bir sürecin sanal belleği kabaca şöyledir:

Bir fonksiyon çağrıldığında yığında ona bir çerçeve (stack frame) ayrılır. Yerel değişkenler, bu çerçevede yan yana durur. C, bir dizinin sonuna gelindiğini denetlemez: ad[16] dizisine 17. baytı yazarsanız, C bunu engellemez ve o bayt bellekte hemen arkada ne varsa onun üzerine yazılır.

Demo 3'teki yapıya bakalım:

struct session {
    char name[16];
    int  admin;          /* 0 = normal user, non-zero = admin */
};

x86-64 işlemciler az anlamlı bayt önce (little-endian) çalışır: bir tamsayının en düşük baytı en düşük adreste durur. Bu yüzden admin'in ilk baytına yazılan 'B' (0x42) tamsayıyı 66 yapar — sıfır olmayan her değer "yönetici" demektir.

struct session yalnız yığındaki bir örnek — genel resim daha büyük. Aşağıdaki animasyon 10-16 gerçekçi bildirimi (global, static, yerel, malloc, dize sabiti, fonksiyon) beş bölgeye (text/data/bss/heap/stack) dağıtır; bölgeyi belirleyenin tür değil bildirim biçimi olduğunu gösterir.

Örnek seçiciden core-ten, extended-sixteen (5 bölgenin hepsi) ve iki uç durumu (hepsi yığında / hepsi öbekte) deneyin.

14. Arabellek taşmaları: nasıl oluşur, nasıl önlenir?¶

Önceki bölümde sürecin belleğinin bölgelerini gördük. Şimdi bu belleğin en eski ve hâlâ en yaygın hatasını tanıyalım. Arabellek taşması (buffer overflow), bir programın bir diziye, o dizinin ayrılan boyutundan fazla veri yazmasıdır. Taşan baytlar yok olmaz; dizinin hemen yanındaki belleğe, yani başka değişkenlerin üzerine yazılır. CWE Top 25 listesinde "sınırlar dışına yazma" (CWE-787) yıllardır ilk sıralardadır.

C neden bu kadar kolay taşar?¶

Java, C#, Python gibi dillerde bir dizinin dışına yazmaya çalıştığınızda çalışma zamanı sizi durdurur (ArrayIndexOutOfBoundsException). C ve C++'ta ise:

1. Dizi, bellekte ardışık baytlardan başka bir şey değildir; boyutunu kendisi bilmez.
2. Bir diziyi fonksiyona verdiğinizde yalnız başlangıç adresi gider (char *); boyut bilgisi kaybolur.
3. Dizeler (string) ayrı bir tür değildir; sonu '\0' baytıyla işaretlenmiş bir char dizisidir. strcpy, strcat, sprintf gibi fonksiyonlar kaynağı sıfır baytını görene kadar kopyalar; hedefin ne kadar yer olduğunu hiç sormaz.
4. Derleyici, hızdan ödün vermemek için sınır denetimi eklemez.

Sonuç: sınırı denetlemek tamamen programcının sorumluluğundadır. Programcı bir kez unutursa, hata oradadır.

Yığında bir taşma adım adım¶

Aşağıdaki fonksiyon bir kullanıcı adını küçük bir yerel diziye kopyalıyor:

void greet_user(const char *name)
{
    int  authorized = 0;
    char buffer[16];

    strcpy(buffer, name);          /* what if name is longer than 16 bytes? */
    printf("Hello %s\n", buffer);
    if (authorized) { /* ... */ }
}

Fonksiyon çağrıldığında yığında ona ait bir çerçeve (stack frame) oluşur. Çerçevenin içinde yerel değişkenler, bir önceki çerçevenin adresi ve fonksiyon bitince nereye dönüleceğini gösteren dönüş adresi bulunur. Basitleştirilmiş bir görünüm (düşük adres yukarıda; gerçek yerleşim derleyiciye göre değişir):

Üç durum vardır:

Üçüncü satırın son kısmı, taşmayı bu kadar tehlikeli yapan şeydir: dönüş adresini kontrol eden, programın bir sonra hangi kodu çalıştıracağını kontrol eder. 1988'deki Morris solucanından 2003'teki Slammer'a kadar salgınların çoğunun giriş kapısı buydu (2. hafta). Bugünkü işletim sistemleri ve derleyiciler bu yolu çok zorlaştıran korumalar ekler (aşağıda), ama hatanın kendisi hâlâ kodunuzdadır ve korumalar her durumu kapatmaz. Bu derste sömürünün nasıl yapılacağıyla değil, hatanın nasıl oluştuğu, nasıl bulunduğu ve nasıl önlendiğiyle ilgileniyoruz.

Örnek seçiciden Uyar, authorized-flip, frame-corrupt ve return-corrupt örneklerini deneyin; 🎲 düğmesiyle rastgele bir isim üretip kendi taşmanızı da gözlemleyebilirsiniz.

Taşma türleri¶

Bir fazla hatası: en masum görünen taşma¶

char name[8];
for (int i = 0; i <= 8; i++)     /* runs 9 times: name[8] is out of bounds */
    name[i] = source[i];

char name[8];
strncpy(name, source, sizeof name);  /* if source >= 8, name does NOT end with '\0' */
printf("%s\n", name);                 /* printf keeps reading past the end of the array */

strncpy adı yanıltıcıdır: güvenli bir strcpy değildir. Kaynak hedeften uzunsa sonlandırıcı koymaz; kısaysa hedefin geri kalanını gereksiz yere sıfırlarla doldurur. Tek bir baytlık taşma bile bitişik bir değişkenin en düşük baytını ya da kaydedilmiş çerçeve adresini değiştirmeye yeter.

Tehlikeli fonksiyonlar ve yerlerine kullanılacaklar¶

Doğru kalıp: önce doğrula, sonra sınırlı kopyala¶

#include <stdio.h>
#include <string.h>

int greet_user(const char *name)
{
    char buffer[16];
    size_t n = strnlen(name, sizeof buffer);

    if (n == sizeof buffer)            /* longer than 15 characters: reject, do not silently truncate */
        return -1;

    memcpy(buffer, name, n);
    buffer[n] = '\0';
    printf("Hello %s\n", buffer);
    return 0;
}

Bu kalıpta üç karar var:

1. strnlen ile uzunluk, en fazla tampon boyutu kadar baytta ölçülür; kaynak hiç sonlanmıyorsa bile okuma sınırın ötesine geçmez.
2. Uzun girdi reddedilir. Sessizce kesmek bazen doğrudur (ör. ekrana yazılacak bir başlık), ama bir kimlik bilgisi, dosya yolu ya da komut kesildiğinde anlamı değişebilir: /home/ayse/gizli_rapor.txt kesilince /home/ayse/gizli olabilir. Güvenlik açısından belirsiz girdiyi reddetmek daha güvenlidir.
3. Sonlandırıcı her durumda açıkça yazılır.

C++'ta aynı işi dil yapar:

#include <string>
#include <iostream>

void greet_user(const std::string &name)
{
    if (name.size() > 15) throw std::invalid_argument("name too long");
    std::string buffer = name;                 /* manages its own memory */
    std::cout << "Hello " << buffer << '\n';
}

Taşmayı kim yakalar? Savunma katmanları¶

Taşmaya karşı savunma da katmanlıdır. En içteki katman doğru koddur; dıştaki katmanlar, bir hata kaçtığında zararı sınırlar:

Bu korumaların her birini 4. haftada ayrı ayrı açıp kapatarak inceleyeceğiz. Bu hafta şu fikri aklınızda tutun: koruma, sömürüyü zorlaştırır; hatayı gidermez. Kanarya bozulduğunda programı sonlandırır; yani saldırgan akışı ele geçiremese bile programı çökertebilir. Bu da bir hizmet engellemedir.

AddressSanitizer ile bir taşmayı yakalamak¶

Yukarıdaki hatalı greet_user fonksiyonunu sanitizer açık derleyip 20 karakterlik bir adla çağırdığınızda, taşma daha programın mantığı bozulmadan yakalanır. Çıktı şuna benzer (kısaltılmış; adresler her çalıştırmada değişir). Aynı türden bir raporu Demo 3'ün login_asan hedefiyle kendiniz üreteceksiniz:

==12345==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffd...
WRITE of size 21 at 0x7ffd... thread T0
    #0 in strcpy
    #1 in greet_user  example.c:7
    #2 in main         example.c:15
Address 0x7ffd... is located in stack of thread T0 at offset 48 in frame
    #0 in greet_user  example.c:3
  This frame has 1 object(s):
    [32, 48) 'buffer' <== Memory access at offset 48 overflows this variable

Okuma sırası: ne oldu (yığın taşması, 21 baytlık yazma), nerede oldu (example.c 7. satır, strcpy), hangi değişken (buffer, 16 bayt: 32–48 aralığı; erişim 48'de, yani tam sınırın bir ötesinde başlıyor). Sanitizer programı yaklaşık iki kat yavaşlatır ve bellek kullanımını artırır; bu yüzden test derlemelerinde kullanılır, sürüm derlemesinde kullanılmaz.

15. Demo 3 — Arabellek taşmasıyla yetki yükseltme¶

struct session s;
s.admin = 0;

strcpy(s.name, argv[1]);  /* BUG: the 16-byte destination size is never checked */

if (s.admin)
    printf(">>> Access granted to the ADMIN panel! <<<\n");

Demo aynı hatalı kodu dört farklı biçimde derler ve aynı saldırıyı dener:

cd code\week-01\03-overflow-input
.\demo.ps1

cd code/week-01/03-overflow-input
sh demo.sh

STEP 1 - Normal login
$ ./bin/linux/login alice
Welcome, alice
admin field = 0 (0x00000000)
Normal user session.

STEP 2 - Attack: a name 1 byte longer than the 16-byte field (17 characters)
$ ./bin/linux/login AAAAAAAAAAAAAAAAB
Welcome, AAAAAAAAAAAAAAAAB
admin field = 66 (0x00000042)
>>> Access granted to the ADMIN panel! <<<

STEP 3 - Same attack, in the AddressSanitizer build
$ ./bin/linux/login_asan AAAAAAAAAAAAAAAAB
Welcome, AAAAAAAAAAAAAAAAB
admin field = 66 (0x00000042)
>>> Access granted to the ADMIN panel! <<<
   ^ ASan stayed silent: the overflow stayed INSIDE the struct.

STEP 4 - A long name that overflows past the struct, ASan version
==1784==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffffffe864 ...
WRITE of size 41 at 0x7fffffffe864 thread T0

STEP 5 - Same short attack, in the build compiled with _FORTIFY_SOURCE=2
$ ./bin/linux/login_checked AAAAAAAAAAAAAAAAB
*** buffer overflow detected ***: terminated
   (the program was stopped by the check the compiler added)

STEP 6 - The fixed version
$ ./bin/linux/login_secure AAAAAAAAAAAAAAAAB
Rejected: the name must be 1-15 characters; only letters, digits, _ and - are allowed.

Windows'ta akış aynıdır. Yalnız 5. adımda strcpy_s, hedefin 16 bayt olduğunu bildiği için taşmayı görür ve programı durdurur:

> .\bin\windows\login_checked.exe AAAAAAAAAAAAAAAAB
*** Secure library function detected an overrun: program terminated ***
   (exit code: 3)

Bu demodan çıkan üç ders:

1. Tek bir baytlık taşma bile yeterlidir. Saldırganın programı çökertmesi gerekmez; bir bayrağı değiştirmesi yetki yükseltmek için yeterli olabilir.
2. Araçların sınırı vardır. AddressSanitizer bellekte her nesnenin etrafına "yasak bölge" koyar; ama taşma aynı yapının içinde kaldığı için (name → admin) bunu göremedi. Taşma yapının dışına çıkınca hemen yakaladı. _FORTIFY_SOURCE (Linux) ve strcpy_s (Windows) ise hedefin (s.name) 16 bayt olduğunu bildiği için kısa taşmayı da yakaladı. Tek bir araca güvenmeyin.
3. Asıl düzeltme koddadır. Araçlar hatayı bulur; hatayı gidermek programcının işidir.

Aşağıdaki animasyonda strcpy'nin argv[1]'i bayt bayt struct session'ın belleğine nasıl kopyaladığını, program sayacıyla birlikte adım adım izleyin.

Örnek seçiciden uyan bir kullanıcı adı (normal), 17 baytlık taşma: admin ayarlanıyor (zor) ve uç durumlar tam 16 bayt: sonlandırıcı NUL taşıyor, 40 bayt: struct'ın ötesine geçiyor (ASan) ve güvenli sürüm reddediyor'u deneyin — ya da 🎲 ile rastgele bir kullanıcı adı üretin, ya da kendi kullanıcı adınızı yazın (SECURE ile başlatırsanız güvenli sürüm çalışır).

/* Allow-list: 1-15 characters; letters, digits, '_' and '-' */
static int name_is_valid(const char *s)
{
    size_t n = strnlen(s, 16);
    if (n == 0 || n >= 16)
        return 0;
    for (size_t i = 0; i < n; i++) {
        unsigned char c = (unsigned char)s[i];
        if (!isalnum(c) && c != '_' && c != '-')
            return 0;
    }
    return 1;
}
...
if (!name_is_valid(argv[1])) { /* reject */ }
struct session s = { .admin = 0 };            /* secure default */
snprintf(s.name, sizeof(s.name), "%s", argv[1]);  /* a copy that knows the size */

16. Tamsayılar ve işaretli uzunluk hatası¶

C'de int işaretli, size_t ise işaretsiz bir tamsayıdır. Bilgisayar negatif sayıları ikiye tümleyen (two's complement) biçiminde saklar: -1'in 64 bitlik gösterimi 0xFFFFFFFFFFFFFFFF'tir. Aynı bit dizisi işaretsiz okunursa 18.446.744.073.709.551.615 olur. memcpy, malloc, read gibi fonksiyonların boyut parametresi size_t'dir; bu yüzden negatif bir int onlara geçtiği anda dev bir sayıya dönüşür.

Demo 4 — İşaretli uzunluk hatası¶

#define RECORD_SIZE 16

static int copy_record(char *dest, const char *source, int length)
{
    /* BUG: the lower bound (negative value) is never checked */
    if (length > RECORD_SIZE)
        return -1;
    memcpy(dest, source, length);   /* int -> size_t: -1 -> 2^64 - 1 */
    return 0;
}

cd code\week-01\04-signed-length
.\demo.ps1

cd code/week-01/04-signed-length
sh demo.sh

STEP 0 - Does the compiler see this bug?
$ gcc -Wall -Wextra -fsyntax-only -I../../common copy.c
   -> No warning: -Wall -Wextra never reports this conversion.
$ gcc -Wsign-conversion -fsyntax-only -I../../common copy.c
copy.c:21:26: warning: conversion to 'size_t' {aka 'long unsigned int'} from 'int'
              may change the sign of the result [-Wsign-conversion]

STEP 1 - Normal use
$ ./bin/linux/copy 8
Copied: SAMPLE-R

STEP 2 - A length that's too large: the check catches it
$ ./bin/linux/copy 100
Rejected: length is too large.

STEP 3 - Attack: a negative length slips past the check
$ ./bin/linux/copy -1
Segmentation fault
   (exit code: 139 -- 139 = memory error, SIGSEGV)

STEP 4 - Same attack, with AddressSanitizer
==1821==ERROR: AddressSanitizer: negative-size-param: (size=-1)

STEP 5 - The fixed version
$ ./bin/linux/copy_secure -1 ; ./bin/linux/copy_secure 12abc ; ./bin/linux/copy_secure 8
Rejected: length must be an integer between 0 and 16.
Rejected: length must be an integer between 0 and 16.
Copied (8 bytes): SAMPLE-R

Windows'ta iki fark görürsünüz. 3. adımda program 0xC0000409 koduyla biter: Windows yığının bozulduğunu fark edip süreci anında sonlandırır. 0. adımda ise MSVC'nin C derleyicisi /Wall ile bile hiç uyarmaz; aynı kod C++ olarak derlenince uyarı çıkar:

> cl /Zs /W4 copy.c                  (compile as C)
   -> No warning: MSVC's C compiler does not report this conversion even with /Wall.
> cl /Zs /W4 /w44365 /TP copy.c      (same code, as C++)
copy.c(21): warning C4365: 'argument': conversion from 'int' to 'size_t', signed/unsigned mismatch

Denetim uzunluk > 16 sorusunu soruyor; -1 bu soruya "hayır" dediği için geçiyor. Ağdan gelen bir paketteki uzunluk alanı, bir dosya başlığındaki kayıt boyutu — saldırganın kontrol ettiği her sayı bu hataya yol açabilir. Derleyici bizi uyarabilirdi, ama yalnız istersek: GCC'de -Wsign-conversion varsayılan uyarılarda yoktur, MSVC'nin C derleyicisinde hiç yoktur. Hangi uyarıların açık olduğunu bilmek ve onları okumak, bedava bir güvenlik aracıdır; araçların sessizliği ise kodun doğru olduğunu göstermez.

Aşağıdaki animasyon gerçek copy_record'u 10-16 farklı length değeriyle sırayla çağırır ve her negatif değerin size_t'ye dönüşünce hangi devasa sayıya döndüğünü gösterir.

Örnek seçiciden typical-sweep, wide-sweep, edge-all-negative (hepsi geçer!) ve edge-boundary örneklerini deneyin; 🎲 ile kendi uzunluk taramanızı da yapabilirsiniz.

static int read_length(const char *text, size_t *result)
{
    char *end;
    errno = 0;
    long value = strtol(text, &end, 10);
    if (errno != 0 || end == text || *end != '\0')
        return -1;                       /* not a number, or it overflowed */
    if (value < 0 || value > RECORD_SIZE)
        return -1;                       /* both the lower and the upper bound */
    *result = (size_t)value;
    return 0;
}

Bu tamsayı hatasının daha geniş ailesini — taşma, işaret dönüşümü, sınır değerleri — 4. haftada tanımsız davranış bölümünde derinlemesine işleyeceğiz.

17. Bellek yönetimi ve güvenlik¶

Arabellek taşması "ne kadar yazdığımızı" unuttuğumuzda ortaya çıkar. Bu bölümdeki hatalar ise "belleğin kime ait olduğunu ve ne zamana kadar geçerli olduğunu" unuttuğumuzda ortaya çıkar. C ve C++'ta öbekten (heap) ayrılan bellek, programcı serbest bırakana kadar yaşar; dil bu süreyi sizin yerinize takip etmez.

Belleğin dört ömrü¶

Dinamik belleğin yaşam döngüsü dört adımdır: ayır → doğrula → kullan → serbest bırak. Her adımda ayrı bir hata sınıfı yaşar.

Hata sınıfları¶

Serbest bıraktıktan sonra kullanma: neden bu kadar tehlikeli?¶

typedef struct { char name[32]; int privilege; } User;

User *active = malloc(sizeof *active);
User *cached = active;                /* a second owner */
/* ... */
free(active);                         /* session closed */
active = NULL;                        /* active is safe, but cached still holds the old address */

char *note = malloc(sizeof(User));    /* the allocator may hand back the very same block */
strcpy(note, "....");                 /* writing the note */

if (cached->privilege) { /* ... */ }  /* UAF: this now reads 'note's bytes */

free belleği işletim sistemine geri vermez; bellek yöneticisinin "boş" listesine koyar. Bir sonraki aynı boyutlu malloc büyük olasılıkla aynı bloğu geri verir. Eski işaretçi (cached) artık tamamen farklı bir nesneye bakıyordur. Programın mantığı, başka bir amaçla yazılmış baytları "kullanıcının yetkisi" diye okur. Bu yüzden UAF hataları tarayıcı ve işletim sistemi açıklarının en büyük sınıflarından biridir.

Örnekteki active = NULL; satırı iyi bir alışkanlıktır, ama yalnız o işaretçiyi korur. Asıl sorun aynı bloğa birden fazla işaretçinin sahip çıkmasıdır. Çözüm bir sahiplik kuralıdır:

UAF'i C/C++'ta adım adım sömürüp AddressSanitizer ile yakalamayı 4. haftada göreceğiz.

Aşağıdaki animasyon active/cached/note kalıbını 10 küçük oturuma uygular; her oturum temiz, sızıntı, çift serbest bırakma ya da UAF'tan biri olur — hangisinin hangisi olduğunu ayır edebilir misiniz?

Örnek seçiciden mixed-ten, mostly-broken ve iki uç durumu (hepsi UAF / hepsi temiz) deneyin.

Diğer hataların düzeltilmiş halleri¶

/* Wrong: if n is large, n * sizeof(Record) overflows and a too-small block is allocated */
Record *k = malloc(n * sizeof(Record));

/* Right 1: calloc checks the size multiplication for overflow and zeroes the memory */
Record *k = calloc(n, sizeof(Record));
if (k == NULL) return ERR_MEMORY;

/* Right 2: reallocarray for resizing (glibc 2.26+, BSD) */
Record *resized = reallocarray(k, n2, sizeof(Record));
if (resized == NULL) { free(k); return ERR_MEMORY; }   /* do not lose k */
k = resized;

/* Wrong: if realloc fails it returns NULL and the old block is still allocated;
   we just overwrote the only pointer to it -> leak */
buffer = realloc(buffer, new_size);

realloc'un ikinci bir gizli sorunu daha vardır: blok taşınırsa eski blok serbest bırakılır ama sıfırlanmaz. İçinde sır varsa, eski kopya belleğin bir köşesinde kalır. Sır tutan tamponlar için realloc kullanmayın; yeni bir blok ayırıp kopyalayın ve eskisini silip öyle serbest bırakın.

Sırları bellekten silmek (Tarif 13.2)¶

"Bellekte kalan sırlar" bölümündeki Demo 2, derleyicinin memset(parola, 0, ...) satırını "sonra hiç okunmayan bir yere yazma" (dead store) olarak görüp tamamen kaldırabildiğini gösterdi. Bunu önlemek için derleyicinin kaldırmayacağı fonksiyonlar kullanılır:

#include <string.h>
#ifdef _WIN32
#  include <windows.h>
#endif

static void secure_wipe(void *p, size_t n)
{
#if defined(_WIN32)
    SecureZeroMemory(p, n);
#elif defined(__GLIBC__) || defined(__OpenBSD__) || defined(__FreeBSD__)
    explicit_bzero(p, n);
#else
    volatile unsigned char *v = (volatile unsigned char *)p;
    while (n--) *v++ = 0;
#endif
}

Silme işleminin nerede yapılacağı da önemlidir. Sırrın kopyası sandığınızdan fazla yerde olabilir:

• Fonksiyona değerle geçirilen yapılar (her çağrıda bir kopya yığında kalır).
• realloc ile taşınan eski blok.
• std::string'in kısa dize iyileştirmesi (SSO) ve kopyaları; std::string yok edilirken içeriğini silmez.
• G/Ç tamponları (fgets'in okuduğu stdin tamponu).
• İşletim sisteminin takas dosyası ve hazırda bekletme dosyası (aşağıda).

Belleğin diske düşmesini önlemek (Tarif 13.3)¶

İşletim sistemi, bellek darlığında az kullanılan sayfaları takas alanına (Linux swap, Windows pagefile.sys) yazar. Bilgisayar hazırda bekletmeye geçtiğinde ise belleğin tamamı diske yazılır. Sırrınızı bellekte ne kadar iyi silerseniz silin, o arada diske yazılmış bir kopya kalabilir. Önlem, sır tutan sayfaları kilitlemektir:

#include <sys/mman.h>

unsigned char key[32];
if (mlock(key, sizeof key) != 0) {
    /* RLIMIT_MEMLOCK may have been exceeded; report the error but still wipe the secret */
}
/* ... use the key ... */
secure_wipe(key, sizeof key);
munlock(key, sizeof key);

#include <windows.h>

unsigned char key[32];
if (!VirtualLock(key, sizeof key)) {
    /* the working-set limit may have been exceeded */
}
/* ... use the key ... */
SecureZeroMemory(key, sizeof key);
VirtualUnlock(key, sizeof key);

Kilitleme sayfa düzeyinde çalışır (genellikle 4 KB). Küçük bir diziyi kilitlediğinizde, onu içeren sayfanın tamamı kilitlenir. Kilitlenebilecek bellek miktarı sınırlıdır; bu yüzden bütün programı değil, yalnız anahtarları tutan küçük ve ayrı bir bölgeyi kilitleyin.

Hepsi bir arada: güvenli tampon¶

Yukarıdaki kuralları tek bir küçük modülde toplamak, her yerde doğru yapmayı kolaylaştırır:

typedef struct {
    unsigned char *data;
    size_t         size;
} SecretBuffer;

/* Allocates, zeroes, locks the memory. -1 on failure. */
int  secret_alloc(SecretBuffer *t, size_t size);

/* Securely wipes, unlocks, releases; sets t->data = NULL. Safe to call twice. */
void secret_free(SecretBuffer *t);

#include <stdlib.h>
#include <sys/mman.h>
#include "secret_buffer.h"

int secret_alloc(SecretBuffer *t, size_t size)
{
    t->data = calloc(1, size);
    if (!t->data) return -1;
    t->size = size;
    (void)mlock(t->data, size);                 /* not fatal if this fails */
    return 0;
}

void secret_free(SecretBuffer *t)
{
    if (!t->data) return;                        /* guards against a double free */
    secure_wipe(t->data, t->size);
    munlock(t->data, t->size);
    free(t->data);
    t->data = NULL;
    t->size = 0;
}

C++'ta aynı fikir bir sınıfın yıkıcısına (destructor) konur; böylece nesne kapsam dışına çıktığında, bir istisna fırlasa bile silme otomatik olarak yapılır. Buna RAII (kaynak edinimi ilklendirmedir) denir:

class SecretKey {
public:
    explicit SecretKey(std::size_t n) : v_(n) { lock(v_.data(), n); }
    ~SecretKey() { secure_wipe(v_.data(), v_.size()); unlock(v_.data(), v_.size()); }
    SecretKey(const SecretKey&) = delete;              /* no copy: the secret must not multiply */
    SecretKey& operator=(const SecretKey&) = delete;
    unsigned char* data() { return v_.data(); }
private:
    std::vector<unsigned char> v_;
};

Kopya yapıcısının silinmesi bilinçli bir karardır: sır tutan bir nesnenin kopyalanması, belleğin başka bir yerinde silinmesi unutulabilecek ikinci bir kopya demektir.

Bellek hatalarını bulan araçlar¶

Kendini dene: bellek¶

1. char *p = malloc(10); free(p); free(p); programı her zaman çöker mi? Neden "çökmese bile tehlikeli"?
2. std::string parola; ile tutulan bir parolayı iş bitince nasıl silersiniz? parola.clear() yeter mi?
3. Bir sunucu her istekte 100 bayt sızdırıyor. Saniyede 1000 istek alıyorsa, 4 GB bellek ne kadar sürede tükenir? Bu hangi STRIDE harfidir?

18. Korunan kod bölümleme ve şifreleme ile güvenli işleme¶

Bir programın her satırı aynı derecede hassas değildir. Ekrana menü çizen kod ile anahtarla şifre çözen kod aynı özeni gerektirmez. Korunan kod bölümleme (protected code partitioning), programı hassasiyetine göre bölgelere ayırmak ve en hassas bölgeyi küçük, yalıtılmış ve en güçlü korumalarla donatılmış bir çekirdek haline getirmektir. Şifreleme ile güvenli işleme ise hassas verinin (hatta hassas kodun) bu çekirdeğin dışında hiçbir zaman açık halde bulunmamasını sağlamaktır.

Neden bölmeliyiz? Güvenilir hesaplama tabanı¶

Güvenlikte güvenilir hesaplama tabanı (TCB — trusted computing base), "bu parça hatalıysa güvenlik çöker" dediğimiz kodun tamamıdır. TCB ne kadar büyükse, içinde hata olma olasılığı o kadar yüksek, incelenmesi o kadar zordur. Saltzer ve Schroeder'in mekanizma ekonomisi ilkesinin (4. bölüm) pratik karşılığı şudur: TCB'yi küçült.

Örnek: 200.000 satırlık bir uygulamada anahtarla çalışan kod 2.000 satırsa ve bu kod ayrı bir modüle ayrılmışsa, sızma testi ve kod incelemesi bu 2.000 satıra yoğunlaşabilir. Gizleme ve bütünlük denetimi yalnız bu modüle uygulanır; performans maliyeti de yalnız burada ödenir (bkz. "Korumanın maliyeti").

Bölümleme seçenekleri¶

Korunan çekirdeği nereye koyacağınız, saldırgan modelinize ve platformunuza bağlıdır:

En güçlü koruma genellikle sırrı istemciden tamamen kaldırmaktır. Bu mümkün olmadığında (ör. telefon çevrimdışı ödeme yapabilmeli), donanım desteği aranır. O da yoksa (ya da her cihazda yoksa), sır yazılımla korunmak zorundadır ve dönem boyunca göreceğimiz gizleme, RASP ve whitebox teknikleri tam olarak bu durum içindir.

Bölümler arasındaki arayüz: dar, doğrulanmış, sırsız¶

Bölümlemenin değeri tamamen sınırdaki arayüzün kalitesine bağlıdır. Anahtarı ayrı bir modülde tutup sonra anahtar_al() diye bir fonksiyonla dışarı veriyorsanız, hiçbir şey kazanmadınız demektir. Arayüz için üç kural:

1. Sırrı dışarı verme, iş yaptır. Çekirdek anahtarı döndürmez; anahtarla işlem yapar ve yalnız sonucu döndürür. Dışarıya anahtar yerine bir tutamaç (handle, opak kimlik) verilir.
2. Sınırı geçen her şeyi doğrula. Çekirdek, dış bölgeden gelen her parametreye güvenilmez girdi gibi davranır (boyut, aralık, biçim).
3. Sınırdan açık veri geçirme. Sınırı geçmesi gereken hassas veri, şifreli ve bütünlüğü korunmuş halde geçer. Aksi halde saldırgan, arayüz fonksiyonuna kanca atarak veriyi yolda okur.

typedef struct VaultKey VaultKey;          /* opaque type: its insides are not visible from outside */

/* Derives the key from the master password and keeps it inside the core; wipes the password. */
int  vault_open(const char *password, size_t password_length,
             const unsigned char salt[16], VaultKey **out);

/* Encrypts / decrypts with the key; the key itself never leaves. */
int  vault_encrypt(VaultKey *a, const unsigned char *plain, size_t n,
                  unsigned char *cipher, size_t capacity, size_t *written);
int  vault_decrypt(VaultKey *a, const unsigned char *cipher, size_t n,
              unsigned char *plain, size_t capacity, size_t *written);

/* Securely wipes the key and releases it. */
void vault_close(VaultKey *a);

C'de opak tür (yalnız bildirilen, tanımı başlık dosyasında olmayan struct), çağıran kodun anahtarın baytlarına doğrudan erişmesini dil düzeyinde engeller. Tabii ki aynı süreçteki bir saldırgan belleği yine de okuyabilir; opak tür programlama hatalarını önler, saldırganı değil. Saldırgana karşı ek katmanlar gerekir.

Arayüzün kötüye kullanımı: şifre çözme kâhini ve kod sökme¶

Anahtarı iyi saklamak yetmez. Saldırgan anahtarı hiç bulmadan sizin fonksiyonunuzu kullanabilir:

• Şifre çözme kâhini (decryption oracle): Saldırgan vault_decrypt fonksiyonunu kendi seçtiği verilerle doğrudan çağırır. Anahtar gizli kalır ama saldırgan istediği her şeyi çözdürür.
• Kod sökme (code lifting): Saldırgan korunan fonksiyonu (hatta içine gömülü anahtarıyla birlikte) binary dosyadan olduğu gibi kopyalar ve kendi programında bir "kara kutu" gibi çalıştırır. Anahtarı hiç çıkarmasına gerek kalmaz.

Karşı önlemler bu nedenle "anahtarı sakla"nın ötesine geçer:

Şifreleme ile güvenli işleme: açıklık penceresini daraltmak¶

Hassas bir veri, yaşam döngüsü boyunca üç durumda bulunur: beklemede (disk), aktarımda (ağ) ve kullanımda (bellek, yazmaçlar). İlk ikisini şifrelemek standarttır; asıl zor olan üçüncüsüdür, çünkü işlem yapmak için verinin bir noktada açılması gerekir. (Beklemede ve aktarımda veriyi koruma yöntemlerini 3. haftada ayrıntılı işleyeceğiz.) Hedef, bu açıklık penceresini zaman ve yer olarak mümkün olduğunca daraltmaktır:

Bunu sağlayan teknikler:

1. Tam zamanında çözme: Veri, yalnız kullanılacağı fonksiyonun içinde çözülür ve fonksiyon dönmeden silinir.
2. Bellekte örtme (masking): Kullanılmadığı sürede anahtar, çalışma anında üretilen rastgele bir maskeyle XOR'lanmış halde tutulur. Bellekte tek bir yerde anahtarın kendisi değil, iki anlamsız parça bulunur.
3. Parçalama: Anahtar ya da bir değer, belleğin farklı yerlerinde (hatta farklı fonksiyonların içinde) duran parçalara bölünür; yalnız kullanım anında birleştirilir.
4. Kod şifreleme (dinamik şifreleme): Yalnız veri değil, en hassas fonksiyonların kodu da binary dosyada şifreli durur; çalışma anında belleğe çözülüp çalıştırılır, sonra yeniden şifrelenir. Ayrıntısı 4. ve 9. haftalarda.
5. Anahtarı hiç açmadan işlem: Whitebox kriptografide anahtar, hesaplama tablolarının içine öyle gömülür ki işlem boyunca bellekte hiçbir zaman açık halde bulunmaz (11. hafta).

#include <stdint.h>
#include <stddef.h>

typedef struct {
    uint8_t mask[32];      /* generated randomly at start-up */
    uint8_t masked[32];    /* key XOR mask */
} MaskedKey;

/* Only at the moment of use, combines into the caller's own temporary buffer. */
static void unmask_key(const MaskedKey *o, uint8_t temp[32])
{
    for (size_t i = 0; i < 32; i++)
        temp[i] = o->masked[i] ^ o->mask[i];
}

void sign(const MaskedKey *o, const uint8_t *data, size_t n, uint8_t tag[32])
{
    uint8_t k[32];
    unmask_key(o, k);
    crypto_hmac_sha256(k, sizeof k, data, n, tag);   /* operation: code/common/cen429_crypto.h */
    crypto_wipe(k, sizeof k);                    /* the exposure window closes here */
}

Bölümlemenin sınırları¶

• Aynı süreç içindeki bir modül, aynı süreçte çalışan bir saldırgana (ör. programa kanca atan bir araç) karşı gerçek bir yalıtım sağlamaz. Bu durumda asıl koruma RASP ve gizlemedir.
• Süreçler arası ya da istemci–sunucu sınırında, iletişim kanalının kendisi yeni bir saldırı yüzeyidir; karşılıklı kimlik doğrulama ve bütünlük gerekir (3. hafta).
• Donanım yalıtımı (TEE, güvenli eleman) güçlüdür ama içinde çalışan kodun da hatasız olması gerekir; TEE uygulamalarında da arabellek taşmaları bulunmuştur.

19. Güvenli geliştirme süreci: planı yaşatmak¶

Bir koruma planı, yazıldığı gün değil, ürün değiştiğinde sınanır. Yeni bir özellik, bir hata düzeltmesi ya da bir kütüphane güncellemesi, dikkatle kurulmuş bir önlemi farkında olmadan etkisiz bırakabilir. Bu bölüm, planın ürünle birlikte yaşamasını sağlayan süreçleri anlatır. Sertifikasyondan geçen ürünlerde bu süreçler, en az kodun kendisi kadar incelenir.

Güvenli yazılım geliştirme yaşam döngüsü¶

Microsoft'un Güvenli Geliştirme Yaşam Döngüsü (SDL) ve NIST'in Güvenli Yazılım Geliştirme Çerçevesi (SSDF, SP 800-218), güvenliğin yazılımın her aşamasına dağıtılması gerektiğini söyler:

Benzersiz sürüm kimliği: "incelenen ile dağıtılan aynı mı?"¶

Bir değerlendirici bir ürünü incelediğinde, raporu tam olarak o binary dosya için geçerlidir. Aynı sürüm numarasıyla dağıtılan ama tek bir satırı farklı olan bir dosya, incelenmemiş bir üründür. Bu yüzden her derleme benzersiz ve doğrulanabilir bir kimlik taşımalıdır:

1. Anlamsal sürüm (ör. 1.4.2): insanlar için.
2. Kaynak kod kimliği: derlemenin yapıldığı git işlemesinin (commit) özeti.
3. Binary dosyanın özeti: dağıtılan dosyanın SHA-256 değeri; kullanıcı ya da değerlendirici indirdiği dosyanın bu değerle eşleştiğini kendisi doğrulayabilir.

execute_process(COMMAND git rev-parse --short=12 HEAD
                WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
                OUTPUT_VARIABLE GIT_COMMIT OUTPUT_STRIP_TRAILING_WHITESPACE)
target_compile_definitions(kasa PRIVATE VERSION="1.4.2" GIT_COMMIT="${GIT_COMMIT}")

if (argc > 1 && strcmp(argv[1], "--version") == 0) {
    printf("kasa %s (%s)\n", VERSION, GIT_COMMIT);
    return 0;
}

Get-FileHash .\kasa.exe -Algorithm SHA256

sha256sum ./kasa

Aynı disiplin dönemin sonunda yeniden karşımıza çıkar: 14. haftada kod gizleme derleme hattına girdiğinde, hangi sürümün hangi dönüşüm ve tohumla üretildiği yine bu kimlik ve özet değerleriyle izlenir.

Değişiklik yönetimi: yedi adım¶

Olgun bir geliştirme ekibinde hiçbir değişiklik "doğrudan ana dala" gitmez. BT hizmet yönetiminden uyarlanan tipik süreç yedi adımdır:

Güvenlik açısından en önemli adım 3 ve 4 arasında yapılan güvenlik etki analizidir: "Bu değişiklik hangi varlığa, hangi arayüze, hangi tehdide ve hangi önleme dokunuyor?" Cevap "hiçbirine" ise değişiklik hızlı ilerleyebilir; bir önleme dokunuyorsa, o önlemin testleri yeniden çalıştırılır ve gerekirse değerlendiriciye bildirilir. Sertifikalı ürünlerde bu analize dayanarak yalnız değişen kısmın yeniden incelendiği değerlendirmeye delta değerlendirme denir (13. hafta).

Kaynak kod deposunda da aynı disiplin uygulanır:

• Ana dallar korumalıdır; yalnız yetkili kişiler birleştirme yapabilir.
• Her değişiklik en az bir başka geliştirici tarafından incelenir.
• Sürümler etiketlenir (tercihen imzalı etiket).
• Depoya dışarıdan erişim çok faktörlü kimlik doğrulamayla yapılır.
• Derleme ortamı da korunur: 2. haftada gördüğümüz tedarik zinciri saldırıları, derleme sunucusuna giren kodu hedef alır.

Ödünleşim kaydı: bilinçli kararların belgesi¶

Güvenlik neredeyse her zaman bir şeyle ödünleşimdir: performans, kullanılabilirlik, bakım kolaylığı. Olgun bir ekip bu kararları yazılı tutar. Kayıt tutulmayan bir ödünleşim, altı ay sonra "burası neden böyle?" sorusuna cevap veremez ve bir değerlendiricinin gözünde bir hata gibi görünür.

Tablodaki üçüncü satır özellikle öğreticidir: bir güvenlik önlemi (bütünlük denetimi), başka bir güvenlik ayarını (hata ayıklanamazlık) gevşetmeyi gerektirmiştir. Böyle bir karar, gerekçesi ve telafi edici önlemiyle yazıldığında savunulabilir; yazılmadığında bir bulgudur.

Korumaların derleme hattına etkisi¶

Bütünlük denetimi gibi önlemler, derleme sürecini de değiştirir. Programın kendi kodunun özetini denetleyebilmesi için doğru özet değerinin programa gömülmesi gerekir; ama özeti gömmek programı değiştirir, bu da özeti değiştirir. Bu döngü, birkaç turlu bir derlemeyle çözülür: önce derlenir, özet ölçülür, gizlenerek koda gömülür, yeniden derlenir; ölçülen bölge gömülen değeri içermeyecek şekilde tasarlanır. Sahada imza sertifikasının özeti, paket özeti ve kod özeti gibi değerlerin art arda gömüldüğü beş turlu imzalı derlemeler kullanılır. Bu tür adımlar elle yapılırsa hata yapılır; bu yüzden derleme betiğine dönüştürülür ve belgelenir. 6. haftada bu döngüyü küçük bir örnekle kuracağız.

Korumaların maliyetini ölçmek¶

Koruma planının son parçası ölçümdür. "Gizleme ekledik" demek yetmez; ürünün hâlâ kabul edilebilir hızda çalıştığını göstermek gerekir. Basit bir yöntem: kritik işlemi (ör. bir ödeme, bir kasa açılışı) korumalı ve korumasız sürümde 20'şer kez çalıştırıp en kısa, en uzun ve ortalama süreyi raporlamak. Temassız bir ödemede toplam sürenin yarım saniyenin altında kalması gibi somut bir hedef, hangi korumanın nereye konabileceğini belirler.

20. Bu haftanın araç kutusu¶

21. Dönem projesi: bu hafta¶

Dönem projesinde bir C/C++ uygulamasını "bir güvenlik sertifikasyonundan geçecekmiş gibi" geliştirip bir güvenlik kılavuzu yazacaksınız (20–30 sayfa). Bu hafta yapılacaklar:

• Takımınızı kurun (bireysel ya da en fazla 4 kişi) ve konunuzu seçin (konu listesi proje rehberinde).
• GitHub'da proje deposunu ve proje planını (iş paketleri, takvim, görev dağılımı) oluşturun; planı onaylatın.
• Güvenlik kılavuzunun ilk bölümlerinin taslağını yazın:
  • S0 Kapak ve sürüm geçmişi
  • S2 Ürün genel bakışı — uygulamanız ne yapıyor?
  • S3 Mimari ve arayüz tablosu (6. bölümdeki tablo biçimiyle)
  • S4 Saldırgan modeli, STRIDE tablosu ve bir saldırı ağacı
  • S5 Varlık listesi (taslak): her varlık için konum, oluşma → silinme ve C/I/I+ sınıfı
• "Uygulamalı örnek" bölümündeki yedi adımlı şablonun 0–4. adımlarını kendi projeniz için doldurun.

| ID | Uç A | Uç B | Kimlik doğrulama | Gizlilik / bütünlük | Açıklama |
| -- | ---- | ---- | ---------------- | ------------------- | -------- |
| A  | Konsol uyg. | Güvenlik DLL'i | ... | ... | ... |

22. Kendi başına çalış¶

Bu alıştırmalar not verilmez; dersi pekiştirmeniz içindir. Hepsi code/week-01 klasöründeki demoların üzerinde, yalnız kendi bilgisayarınızda yapılır.

Get-ChildItem -Recurse -Filter *.c code\week-01 |
  Select-String -Pattern 'strcpy|strcat|sprintf|gets\(|scanf'

grep -rnE 'strcpy|strcat|sprintf|gets\(|scanf' code/week-01 --include=*.c

23. Kendini sınama¶

24. Kaynaklar ve ileri okuma¶

Ders kitabı — J. Viega, M. Messier, Secure Programming Cookbook for C and C++, O'Reilly, 2003:

• Tarif 1.1 (ortamı temizleme), 1.2–1.4 (ayrıcalıkları kısıtlama ve ayırma), 1.5 (dosya tanıtıcıları), 1.9 (çökme dökümünü engelleme)
• Tarif 3.3 (arabellek taşmasını önleme), 3.5 (tamsayı dönüşümü ve taşması)
• Tarif 13.2 (bellekten güvenli silme), 13.3 (belleğin diske yazılmasını önleme)
• Tarif 12.1 (yazılım korumasını anlamak)

Açık kaynaklar

• J. H. Saltzer, M. D. Schroeder, "The Protection of Information in Computer Systems", 1975.
• OWASP Threat Modeling; Microsoft STRIDE.
• MITRE CWE: CWE-14, CWE-121, CWE-122, CWE-125, CWE-193, CWE-195, CWE-226, CWE-316, CWE-401, CWE-415, CWE-416, CWE-426, CWE-427, CWE-476, CWE-787.
• SEI CERT C Coding Standard: STR31-C (dize kopyalarken yer ayırma), INT31-C (tamsayı dönüşümleri), MSC06-C (derleyici optimizasyonlarına dikkat), ENV33-C (system() çağırmama), MEM30-C (serbest bırakılmış belleğe erişmeme), MEM31-C (dinamik belleği serbest bırakma), MEM35-C (yeterli bellek ayırma), POS36-C (yetki bırakma sırası), POS37-C (yetki bırakmanın başarısını doğrulama).
• Microsoft Security Development Lifecycle (SDL); NIST SP 800-218 Secure Software Development Framework (SSDF).
• A. Shostack, Threat Modeling: Designing for Security, Wiley, 2014 (veri akış diyagramı ve öğe başına STRIDE).