Bugünün planı (3 saat)

Öğrenme çıktısı: ÖÇ.3 (binary uygulama korumaları)

Önceki haftalardan gelenler

• Süreç belleği: yığın ve öbek — yığın (stack) fonksiyon çağrılarının yerel değişkenlerini otomatik yönetir, öbek (heap) malloc/free ile elle yönetilir (Hafta 1)
• Arabellek taşması — bir diziye ayrılan boyuttan fazla veri yazmak; taşan baytlar komşu belleğe yazılır (Hafta 1)
• Yığın çerçevesi ve dönüş adresi — bir fonksiyon çağrısının yerel değişkenlerini ve dönüş adresini tuttuğu bölüm (Hafta 1)
• Beyaz kutu saldırgan modeli — cihazın sahibi aynı zamanda olası saldırgandır; belleği okuyabilir, hata ayıklayıcı bağlayabilir (Hafta 1)
• CWE — yazılım zayıflıklarının numaralı kataloğu (Hafta 2)

Bu hafta: 1–3. haftanın ilke/tehdit modeli/kripto temeli üzerine SEI CERT kuralları, sanitizer'lar ve derleyici/OS korumalarını kuruyoruz.

İşaretçi (pointer)

• İşaretçi: bir bellek adresini tutan değişken.
• p bir adres; *p o adresteki değer.
• Yanlış adres → çökme ya da yanlış veri.

Derleyici bayrağı (flag)

• Bayrak: derleyiciye verilen seçenek.
• Örnek: -O2 (optimizasyon), -Wall (uyarılar), -fsanitize=address.
• Doğru bayraklar birçok hatayı derleme anında yakalar.

Uyarı (warning) vs hata (error)

• Hata: derleme durur.
• Uyarı: derleme sürer ama bir sorun bildirilir.
• Kural: uyarıları hataya çevir (-Werror) — görmezden gelinen uyarı, gelecekteki açıktır.

Demolar nasıl çalışıyor?

• Demolar code/week-04 altında; Windows (Visual Studio 2022) ve WSL/Linux'ta çalışır.
• Derle: Windows .\build.ps1 · WSL/Linux ./build.sh
• Çalıştır: her demo klasöründe Windows .\demo.ps1 · WSL/Linux sh demo.sh
• Fuzzing (Demo 4) Linux/WSL'de clang ister (sudo apt install -y clang); Windows'ta VS'nin "C++ AddressSanitizer" bileşeni gerekir.

⚠️ Etik: demolar yalnız kendi küçük programlarımızda; başka bir programa/sisteme dokunmaz.

Üç katman, doğru sıra

Kod sağlamlaştırma üç katmandır. Sıra önemli:

1. Önce hatasız kod (güvenli kodlama)
2. Sonra zararı sınırla (derleyici/OS korumaları)
3. En son okumayı zorlaştır (gizleme)

⚠️ Gizleme, hatayı düzeltmez.

Neden bu sıra?

• Hatalı koda koruma eklemek, çürük temele boya çekmek gibidir.
• Önce hatayı kaldır; sonra kaçanı yakala; en son tersine mühendisliği yavaşlat.
• Bu hafta üçünü de göreceğiz, bu sırayla.

CERT kuralının anatomisi — şema

SEI CERT C/C++: gerçek zafiyetlerden çıkarılan, güvenli kodlamanın kural kitabı.

Üç katman — şema

Katman 2 · Güvenli kodlama

• Soru: kodumda hata var mı?
• Araçlar: CERT kuralları, sanitizer, fuzzing.
• Amaç: hatayı en baştan yazmamak.

Katman 3 · Derleyici/OS

• Soru: hata kaçarsa sömürü zor mu?
• Araçlar: kanarya, FORTIFY, ASLR, NX, RELRO, CFI.
• Amaç: kalan hatanın istismarını pahalı kılmak.

Katman 4 · Gizleme

• Soru: kodu okuyan anlıyor mu?
• Araçlar: sembol/dize gizleme, günlük kaldırma, düzleştirme.
• Amaç: tersine mühendisliği yavaşlatmak.

Sahadan: şema gereksinimleri

Sertifikalı bir üründe:

• "Yaygın zafiyetler ele alınmalı: hassas veri, enjeksiyon, taşma, dile özgü zayıflıklar"
• "Savunmacı programlama kodun tamamında tutarlı"
• "Statik ve dinamik tersine mühendisliğe karşı koruma"

➡️ Yalnız native tarafta 18 sağlamlaştırma önlemi.

SEI CERT: bir kural neye benzer?

Her CERT kuralının parçaları:

• Kimlik: STR31-C, MEM50-CPP
• Başlık: tek cümle
• Hatalı örnek ve uyumlu çözüm
• Risk düzeyi (L1/L2/L3) ve CWE bağı

Kural mı, öneri mi?

• Kural (rule): ihlali bir zafiyettir, denetlenebilir.
• Öneri (recommendation): iyi uygulama.
• İncelemeye L1 (en yüksek risk) kurallarından başla.

Risk düzeyi nasıl belirlenir?

Risk = önem × olasılık × düzeltme maliyeti.

• L1: yüksek risk, önce bunlar.
• L2 / L3: giderek düşer.

Otomatik CERT denetimi

• Uyarılar: -Wall -Wextra -Wformat=2 -Wconversion
• clang-tidy cert-*
• cppcheck --addon=cert
• MSVC /analyze

Değerlendirici önce bu taramayı çalıştırır, sonra elle okur.

Girdi doğrulama — şema

Girdi nereden gelir?

Sandığınızdan çok yerden. Ve hepsi güvenilmez:

• Komut satırı, ortam değişkenleri
• Dosya, ağ
• IPC (aynı makinedeki başka süreç)
• Veritabanı, kütüphane arayüzü (JNI)

Sık unutulan girdiler

• argv[0] bile saldırganın olabilir; PATH, LANG.
• Dosya biçimindeki uzunluk alanları.
• Ağ: "16 bayt" der, 1 bayt gönderir.
• "Kendi verimiz" sonradan değişmiş olabilir.

Girdi doğrulamanın beş ilkesi

1. Beyaz liste (izin verilenleri say), kara liste değil.
2. Önce kanonikleştir, sonra doğrula.
3. Uzunluk → tür → aralık → biçim sırasıyla.
4. Güven sınırında, en erken noktada.
5. Reddet, "temizleyip" kullanma.

İlke 1 · Beyaz liste

• Kara liste: "şunlar yasak" — hep bir şey unutulur.
• Beyaz liste: "yalnız şunlar serbest" — güvenli varsayılan.

Örnek: kullanıcı adı yalnız [a-z0-9_] olsun.

İlke 2 · Kanonikleştir

• Aynı şeyin farklı yazımları: /tmp/../etc, %2e%2e/.
• Önce tek biçime indir (kanonikleştir), sonra denetle.
• Yoksa denetim atlatılır.

İlke 3 · atoi değil strtol

errno = 0;
long value = strtol(s, &end, 10);
if (end == s)         return -1;  /* no digits */
if (*end != '\0')     return -1;  /* "12abc" */
if (errno == ERANGE)  return -1;  /* overflowed */
if (value < min_val || value > max_val) return -1;  /* business rule */

Neden atoi tehlikeli?

• atoi("abc") = 0 (hata sessiz)
• atoi("99999999999") = tanımsız (taşma)
• atoi("12abc") = 12 (fazlalık yok sayılır)

strtol her hatayı size bildirir; atoi bildirmez.

İlke 3 · uzunluk önekli kayıt

if (remaining < 3) return -1;                    /* no header */
uint16_t length = buffer[1] << 8 | buffer[2];
if (length > remaining - 3)       return -1;      /* SOURCE: declared > received */
if (length > sizeof rec->data)    return -1;      /* DEST: doesn't fit */
memcpy(rec->data, buffer + 3, length);

İki ayrı denetim, doğru sıra

• Kaynak denetimi: bildirilen uzunluk, gelen veriden büyük mü?
• Hedef denetimi: hedef tampona sığıyor mu?
• Sıra: remaining - 3 sarmasın diye önce remaining < 3.
• Sahada: JNI'den gelen her dizi native tarafta yeniden doğrulanır.

CERT çifti · STR31-C

strcpy(copy, name);                               /* WRONG */
int n = snprintf(copy, sizeof copy, "%s", name);  /* COMPLIANT */
if (n < 0 || (size_t)n >= sizeof copy) { /* kesildi */ }

strcpy sınır bilmez; snprintf boyutu bilir ve kesilmeyi bildirir.

CERT çifti · INT30-C

size_t remaining = total - read_count;   /* WRONG: read_count>total -> gigantic number */
if (read_count > total) return ERROR;    /* COMPLIANT: order checked first */
size_t remaining = total - read_count;

İşaretsiz çıkarma sarar; önce mantığı denetle.

CERT çifti · MEM30-C

for (n = head; n; n = n->next) free(n);              /* WRONG */
while (n) { Node *s = n->next; free(n); n = s; }      /* COMPLIANT */

free(n)'den sonra n->next okumak = bırakılmış belleğe erişim.

CERT çifti · ERR33-C

FILE *f = fopen(path,"rb"); fread(t,1,n,f);        /* WRONG */
if (!f) return ERROR;
if (fread(t,1,n,f) < n && ferror(f)) return ERROR; /* COMPLIANT */

Her dönüş değerini denetle; fopen NULL dönebilir.

Kural: bulguyu kimliğe bağla

Her bulguyu bir CERT kimliğiyle eşleştir:

"Bu satır MEM30-C ihlali (CWE-416)."

Böylece bulgu nesnel ve aranabilir olur.

Bölüm 1 — kısa sınama

1. Üç katman ve doğru sıra?
2. Kural ile öneri farkı?
3. atoi neden strtol'a göre tehlikeli?

Bölüm 1 — cevaplar

1. Sıra: güvenli kod (kaynak) → derleyici/araç korumaları → OS/çalışma zamanı korumaları. Önce doğru yaz, sonra sertleştir, sonra çalışma anında savun.
2. Kural her zaman uygulanır, ihlali kusurdur; öneri bağlama göre iyi uygulamadır.
3. atoi hatayı bildirmez (taşma/geçersiz girdide tanımsız/0); strtol endptr+ERANGE ile hatayı ve sınırı kontrol ettirir.

Biçim dizesi açığı — şema

Sorun · printf(girdi)

printf(user_input);        /* WRONG */
printf("%s", user_input);  /* CORRECT */

İlkinde kullanıcı girdisi bir biçim dizesi olarak yorumlanır.

Neden tehlikeli?

printf biçim dizesindeki % belirteçlerini komut sayar.

Kullanıcı %x, %s, %n gönderirse programa iş yaptırır.

Kısa tarihçe · biçim dizesi açıkları

• 1999–2000 — wu-ftpd gibi yaygın FTP sunucularında gerçek zafiyetler açığı geniş çapta tanıttı.
• Saldırganlar günlükleme çağrılarına sızan kullanıcı verisini biçim dizesi olarak kullanıp bilgi sızdırdı, hatta uzaktan kod çalıştırdı.
• Ders: %n gibi "zararsız görünen" bir belirteç aslında bir yazma astarıdır (write primitive).
• Karşılık: derleyicide -Wformat-security, çalışma anında _FORTIFY_SOURCE.

Belirteç · %x, %p

• Yığındaki değerleri okur ve yazdırır.
• → bilgi sızıntısı (adresler, gizli değerler).
• ASLR'yi zayıflatır (adres sızarsa).

Belirteç · %s

• Yığındaki bir değeri işaretçi sanar ve o adresteki dizeyi okur.
• Rastgele adres → çökme ya da bellek okuma.

Belirteç · %n

• Şimdiye kadar yazılan karakter sayısını bir adrese yazar.
• → belleğe yazma → bozulma, denetim ele geçirme.
• En tehlikelisi.

Aynı hata başka yerlerde

Sadece printf değil:

syslog, fprintf, snprintf, err/warn — hepsi biçim dizesi alır.

Kural: biçim dizesi her zaman sabit (FIO30-C).

Animasyon — %x yığını tarar

Animasyon — uç durum: %n bir sonraki adımda

Düzeltme · katman katman

1. Biçim dizesi hep sabit (FIO30-C).
2. Uyarı: -Wformat -Wformat-security -Werror=format-security.
3. Kendi fonksiyonunuzu derleyiciye denetlettirin:

void gunluk_yaz(int duzey, const char *bicim, ...)
    __attribute__((format(printf, 2, 3)));

4. Çalışma anı: _FORTIFY_SOURCE=2; MS CRT %n kapalı.

Yığın ve öbek — şema

Use-after-free — şema

UAF nedir? · adım 1

• Bir nesne öbekte.
• İki işaretçi aynı nesneyi gösteriyor.

UAF · adım 2

• Biri free ediyor.
• Diğeri hâlâ o adresi tutuyor → askıda (dangling) işaretçi.

UAF · adım 3

• Ayırıcı aynı bloğu başka nesneye veriyor.
• Askıdaki işaretçi artık yabancı veriyi okur/yazar.
• Nesnede fonksiyon işaretçisi varsa (C++ sanal tablo) risk büyür.

UAF neden çok yaygın?

Tarayıcı/OS güncellemelerindeki "bellek bozulması düzeltildi" notlarının büyük kısmı bu sınıftır.

Karmaşık sahiplik → askıda işaretçi.

Animasyon — küçük bir öbek

Animasyon — uç durum: çift serbest bırakma

ASan raporu · üç yığın izi

ERROR: heap-use-after-free
  #0 mode_uaf uaf.c:49   <- 1. KULLANIM
freed here:
  #1 mode_uaf  uaf.c:38   <- 2. SERBEST BIRAKMA
allocated here:
  #1 mode_uaf     uaf.c:32   <- 3. AYIRMA

Düzeltme çoğunlukla 2. konumda: sahiplik kararı orada yanlış.

Çözüm · C tarafı

• free'den sonra işaretçiyi NULL yap.
• Tek sahip, tek bırakma noktası belirle.
• Sahiplik kuralını yaz: "bu belleği kim bırakır?"

Tamsayı taşması — şema

Dört tamsayı hatası

Neden önemli? · çarpım taşması

uint32_t size = count * 4;   /* count = 0x40000001 → size = 4 */
array = malloc(size);        /* small block */
/* loop writes `count` times → heap overflow */

Küçük ayrılan bloğa çok yazmak = taşma.

UB · derleyici denetimi silebilir

Tanımsız davranış (UB): C/C++ standardının sonucunu tanımlamadığı işlem (ör. işaretli tamsayı taşması).

if (x + 100 < x)   /* assumes "if it overflows, it gets smaller" */
    return -1;     /* signed overflow is UB → the compiler MAY DELETE this branch */

• -O0'da "çalışır", -O2'de denetim yok olur.
• UB'ye güvenilmez.

Doğru: önce denetle

if ((b > 0 && a > INT_MAX - b) ||
    (b < 0 && a < INT_MIN - b)) return false;   /* before the overflow */
if (__builtin_mul_overflow(a, b, &result)) return false;  /* GCC/Clang */
/* C23: <stdckdint.h> ckd_add/ckd_mul · MSVC: <intsafe.h> */

Taşmayı olmadan önce yakala.

Animasyon — INT_MAX + add

Animasyon — uç durum: güvenli sürüm aynı girdiyi reddediyor

Sinyal işleyici — şema

Denetlenmeyen dönüş değeri

Hata işleme kuralları

1. Her dönüşü denetle (ERR33-C); [[nodiscard]].
2. Hatada güvenli duruma dön (goto temizle) — fail-closed.
3. İleti ipucu vermesin: "kullanıcı yok" ≠ "parola yanlış".

Sahadan: opak dönüş değerleri

• Native fonksiyonlar ayrıntılı hata kodu döndürmez.
• Yalnız başarılı/başarısız, üstelik opak (9. hafta).
• Ayrıntılı kod = saldırgana "hangi denetimde takıldın" haritası.
• Tanı için ayrı, güvenli kanal → ödünleşim kaydı.

Sinyal işleyici · kural

static volatile sig_atomic_t stop = 0;
static void handler(int s){ (void)s; stop = 1; }  /* ONLY a flag */

• İşleyicide printf, malloc, free yok (SIG30-C).
• Eşzamansız-güvenli olmayan fonksiyon çağırma.
• signal() yerine sigaction().

Gerçek olay: regreSSHion

• 2024 CVE-2024-6387: zaman aşımı sinyal işleyicisi güvensiz bir günlük fonksiyonu çağırıyordu.
• Sonuç: uzaktan kod çalıştırma riski.
• Ders: işleyicide yalnız bayrak set et.

Bölüm 2–3 — kısa sınama

1. %n neden en tehlikelisi?
2. UAF raporundaki üç iz? Düzeltme hangisinde?
3. if (x+100 < x) neden silinebilir?
4. Sinyal işleyicide neden printf yok?

Bölüm 2–3 — cevaplar

1. %n biçim belirtecinin yazdığı bayt sayısını belleğe YAZAR → saldırgan seçtiği adrese yazıp akışı ele geçirebilir.
2. allocated-by · freed-by · use-here. Düzeltme freed↔use arasında: free sonrası işaretçiyi NULL yap / yaşam süresini düzelt.
3. İmzalı taşma tanımsız davranıştır; derleyici "taşma olmaz" varsayar → koşul hep false → siler. Kontrolü __builtin_add_overflow ile yapın.
4. printf async-signal-safe değil; işleyicide yeniden girişte kilit/durum bozulur → kilitlenme/çökme. Yalnız write gibi güvenli çağrılar.

ASan redzone — şema

Statik ↔ dinamik — şema

Statik analiz nedir?

Kodu çalıştırmadan inceleyip hata arama.

Avantaj: çalışmayan yolları da görür.
Dezavantaj: yanlış alarm üretir.

Kirli veri: kaynak → hedef

Araç, doğrulanmamış verinin tehlikeli bir yere aktığını görür.

Yanlış alarmla yaşamak

1. Önce yüksek güvenilirlikli kurallar.
2. Her bastırma gerekçeli: // NOLINT(cert-err33-c): neden.
3. Yeni kodda sıfır uyarı (CI zorlar).

Değerlendirici geliştiricinin kendi tarama raporunu ister.

Sanitizer nedir?

Programı çalıştırırken bellek/UB hatalarını yakalayan araç.

Yanlış alarm neredeyse yok; ama yalnız çalışan yoldaki hatayı bulur.

→ test + fuzzing ile birlikte.

Kısa tarihçe · AddressSanitizer

• 2012 — Google, AddressSanitizer'ı (ASan) yayımladı: derleme anında enstrümantasyon + gölge bellek ile taşma/UAF'ı anında yakalıyor.
• Öncesinde bu sınıf hata genelde sessizce çöküyor ya da hiç fark edilmiyordu.
• ASan + fuzzing birlikte kullanılınca, çökmeyen ama belleği bozan girdi de yakalanır (bu haftanın Bölüm 4/11'i).

ASan nasıl çalışır? · gölge bellek

• Her 8 bayt için 1 gölge bayt: ne kadarı geçerli?
• Dizilerin önüne/arkasına koruma bölgesi (redzone).
• Serbest bloklar karantinada bekler.
• Her erişimden önce gölge denetimi.

ASan'ın kör noktası

struct { char name[8]; long role; } k;
strcpy(k.name, long_input);   /* name → role overflows */

Aynı yapının içinde alandan alana taşma → arada koruma bölgesi yok → ASan görmez (1. hafta Demo 3).

Sanitizer sürüme gitmez

gcc -g -O1 -fno-omit-frame-pointer \
    -fsanitize=address,undefined p.c -o p_test

• Yavaşlatır (~2×), bellek kullanır.
• Yalnız test/CI'da; sürümde kapalı.

Fuzzing nedir? · kapsam güdümlü

Fuzzing: bir programı çok sayıda otomatik üretilmiş, çoğu bozuk girdiyle çalıştırıp çökme arama tekniği.

Yeni kod yolu açan girdi saklanır ve üzerinde çalışılır.

Fuzzing ne bulur?

• Sihirli baytları, doğru uzunluk alanını kendiliğinden bulur.
• İnsanın düşünmediği girdileri.
• Araçlar: libFuzzer, AFL++, honggfuzz, OSS-Fuzz (on binlerce hata).

Kısa tarihçe · fuzzing

• 1990 — Barton Miller'ın "Fuzz" çalışması: rastgele girdiyle Unix araçlarının %25-33'ünü çökertti; fuzzing'in akademik başlangıcı.
• 2013 — AFL (american fuzzy lop): kapsam geri beslemesini pratik ve yaygın hâle getirdi.
• Ardından libFuzzer (derlemeye gömülü, hızlı) ve OSS-Fuzz (büyük açık kaynak projelerini sürekli fuzzlayan servis).

Fuzz hedefi yazmak

int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) {
    parse_document((const unsigned char *)data, size);
    return 0;
}

clang -g -O1 -fsanitize=fuzzer,address fuzz.c parser.c -o f
./f corpus/ -max_total_time=10

İyi fuzz hedefi

Dört özellik:

• Hızlı (ağ/disk yok)
• Deterministik (aynı girdi → aynı sonuç)
• Durumsuz (önceki çağrıdan etkilenmez)
• Tek iş (bir fonksiyonu sınar)

Animasyon — izin listesi ayrıştırıcı

Animasyon — uç durum: hepsi bozuk kayıt

Animasyon — kapsam güdümlü fuzzing

Animasyon — uç durum: ilk adayda hemen çökme

Bölüm 4 — kısa sınama

1. Statik ve dinamik analizin farkı?
2. ASan hangi taşmayı göremez?
3. İyi fuzz hedefinin dört özelliği?

Bölüm 4 — cevaplar

1. Statik: kodu çalıştırmadan tüm yolları inceler (yanlış pozitif olabilir). Dinamik: çalıştırırken yalnız yürütülen yolda gerçek hatayı gözler.
2. ASan redzone koyduğu yerleri görür; bir nesnenin içindeki alanlar arası taşmayı ve hiç çalışmayan yolları göremez.
3. Hızlı, deterministik, kendine yeterli (dış duruma bağlı değil), dar bir girdi yüzeyi işleyen; çökmede net başarısızlık veren hedef.

Derleyici/OS korumaları — şema

Katman 3 · fikir

Hata kaçtı diyelim.

• Sömürüyü pahalı kılan otomatik korumalar var.
• Çoğu bir derleme bayrağıyla açılır.
• Bedava değil ama ucuz.

Yığın kanaryası

• Dönüş adresinden önce bir nöbetçi değer konur.
• Taşma bu değeri bozarsa, dönüşten önce fark edilir ve program durur.
• -fstack-protector-strong / MSVC /GS.

Kısa tarihçe · derleyici/OS korumaları

• 1998 — StackGuard: yığın kanaryası fikrini derleyiciye ilk kez otomatik olarak ekledi.
• 2001 — PaX projesi, Linux çekirdeğine ASLR'ı (adres uzayı düzeni rastgeleleştirme) getirdi.
• 2003–2004 — W^X / NX / DEP: bellek sayfaları aynı anda hem yazılabilir hem çalıştırılabilir olamaz.
• Bu üçü birlikte, günümüz derleyici/OS korumalarının temelini oluşturur.

Yığın taşması ve kanarya — şema

_FORTIFY_SOURCE

• Boyutu bilinen tampona fazla yazan kütüphane çağrılarını yakalar.
• -D_FORTIFY_SOURCE=2 (+ en az -O1).
• Kendi döngülerinizi korumaz.

PIE + ASLR

• ASLR: adresleri rastgeleleştirir.
• PIE: programın da rastgele yüklenmesini sağlar.
• -fPIE -pie / /DYNAMICBASE /HIGHENTROPYVA.

DEP/NX ve RELRO

• DEP/NX: veri bölgesini çalıştırılamaz yapar (varsayılan).
• RELRO: GOT gibi tabloları salt-okunur yapar → -Wl,-z,relro,-z,now.

CFI / CFG ve gölge yığın

• CFI/CFG: dolaylı çağrıların yalnız geçerli hedeflere gitmesini denetler.
• -fcf-protection, -fsanitize=cfi / /guard:cf.
• Gölge yığın: dönüş adreslerinin ikinci kopyası (CET).

⚠️ Her koruma sınırlıdır

Ana kural

Her koruma bir tekniği zorlaştırır, bir hata sınıfını kaldırmaz.

Mantık hatasına hiçbiri yetmez → önce güvenli kodlama.

Animasyon — yığın kanaryası

Animasyon — uç durum: aynı taşma, ZAYIF sürümde kanarya yok

Önerilen sürüm bayrakları

GCC/Clang:

-O2 -D_FORTIFY_SOURCE=2 -fstack-protector-strong -fPIE -pie -Wl,-z,relro,-z,now -fcf-protection -Wall -Wextra -Wformat=2 -Werror=format-security

MSVC:

/O2 /GS /sdl /guard:cf /DYNAMICBASE /HIGHENTROPYVA /NXCOMPAT /CETCOMPAT /W4

Koruma tablosu = kanıt

• Değerlendirici her binary ve .so için koruma tablosu çıkarır.
• Kapalı koruma bir bulgudur; gerekçesi ödünleşim kaydında olmalı.
• Şema: uygulama, korumaların açık olduğunu kendisi de denetleyebilir.

Güvenli derleme hattı (CI)

CI (Continuous Integration): her kod değişikliğinde otomatik derleme + test çalıştıran sistem.

Her hatalı adım birleştirmeyi durdurur.

Derleme ortamı da hedeftir

• Erişim kaydı; bağımlılık sabitleme (5. hafta SBOM).
• İmzalı sürüm; yeniden üretilebilir derleme.
• Derleme makinesi ele geçerse tüm ürün etkilenir.

Bölüm 5 — kısa sınama

1. Kanarya neyi durdurur, neyi durdurmaz?
2. ASLR neden bir bilgi sızıntısıyla zayıflar?
3. Neden "hiçbir koruma mantık hatasına yetmez"?

Bölüm 5 — cevaplar

1. Durdurur: dönüş adresini ezen ardışık yığın taşmasını (kanarya bozulur). Durdurmaz: hedefli yazma, heap taşması, bilgi sızıntısı.
2. Tek bir sızan adres modülün taban adresini açığa çıkarır (offset sabit) → tüm rastgelelik çöker.
3. Korumalar bellek ihlalini yakalar; yanlış yetkilendirme/iş kuralı geçerli bellek erişimidir → hiçbir koruma tetiklenmez. Doğru tasarım + inceleme gerekir.

Katman 4 · neden?

• Beyaz kutu saldırgan: dizeleri okur, fonksiyonları adıyla bulur, denetimi atlar.
• Gizleme: davranış aynı, anlaşılması zor.

İki saldırgan modeli — şema

Gizlemenin amacı

İmkânsız kılmak değil, pahalı kılmak (Cookbook 12.1):

• maliyet > korunan değer
• otomasyonu zorlaştır (çeşitlendirme, 14. hafta)
• diğer katmanlara zaman kazandır

Tek gelişmiş teknik yerine birkaç basit teknik + veri gizleme.

Kısa tarihçe · kod gizleme taksonomisi

• 1997 — Collberg, Thomborson ve Low, gizleme (obfuscation) tekniklerini sistematik bir taksonomiye ayıran çalışmalarını yayımladı: yerleşim (layout), veri (data), kontrol (control) ve önleme (preventive) dönüşümleri.
• Bu hafta gördüğümüz dize/sembol gizleme = veri dönüşümü; kontrol akışı düzleştirme ve opak yüklem = kontrol dönüşümü.
• Taksonomi hâlâ akademik ve endüstriyel gizleme literatürünün ortak dilidir.

Sahadan: native tarafta 18 önlem

Sembol görünürlüğü kapalı · ad anlamsızlaştırma · sabit aritmetik gizleme · dize şifreleme (kullanınca çöz, hemen sil) · opak boolean · kendi kütüphane fonksiyonları · sahte işlem/ölü dal · düzleştirme + rastgele çıkış · sürümde günlük yok.

➡️ Güç birliktelikten ve RASP'tan.

Üç ucuz önlem

Günlük makrosu

#ifdef LOG_ENABLED
#  define LOG(...) fprintf(stderr, __VA_ARGS__)
#else
#  define LOG(...) ((void)0)   /* neither the string nor the call end up in the binary */
#endif

Sürümde LOG_ENABLED tanımlı değil → günlük hiç derlenmez.

⚠️ Çalışma anı bayrağı yetmez

if (debug_flag) printf("...");  /* BAD */

• Dize binary dosyada kalır.
• Saldırgan bayrağı değiştirip günlüğü yeniden açar.
• Doğrusu: derleme anında çıkar.

⚠️ Dize gizleme ≠ anahtar saklama

• Çözülen dize kullanım anında bellekte açık.
• Çözme anahtarı programın içinde.
• Durdurduğu: strings gibi statik taramalar.
• Çalışırken inceleyene → RASP (6). Gerçek anahtar → whitebox (11).

Animasyon — dize + sembol gizleme

Animasyon — uç durum: kötü anahtar seçimi (0x00)

Sembol ve dize gizleme — şema

Kontrol akışı düzleştirme

int state = 1;
for (;;) switch (state) {
  case 1: state = 2; break;
  case 2: state = (condition ? 3 : 4); break;
  case 3: state = 5; break;
  case 4: return FAILURE;
  case 5: return SUCCESS;
}

Blokların doğal komşuluğu kaybolur; sıra yalnız durum değişkeninde.

Düzleştirme: önce/sonra — şema

Düzleştirmeyi güçlendirenler

• Durum değerlerini gizle (aritmetik dönüşüm)
• Sahte/ölü bloklar (hangisi gerçek?)
• Rastgele çıkış (hata nerede yakalandı, okunmaz)
• Opak değerler (tek bayt çeviremez)

Tek başına şablon kısa sürede çözülür → 9. hafta derinlik.

Animasyon — dağıtıcı durum makinesi

Animasyon — uç durum: hepsi yanlış uzunlukta, anında ret

Animasyon — opak yüklem

Animasyon — uç durum: INT sınırlarına yakın değerler

Kavram: 9. haftaya bağlanan üç teknik

• Fonksiyon adı gizleme: dışa açık adlar anlamsız; okunabilirlik makroyla.
• Bellek ayırma gizleme: "32 bayt = anahtar" izini bulanıklaştır.
• Dinamik şifreleme: hassas kod binary'de şifreli; DEP/NX ile çatışır, seçici.

Bölüm 6 — kısa sınama

1. Gizleme hatayı düzeltir mi?
2. Günlüğü çalışma anı bayrağıyla susturmak neden yetmez?
3. Düzleştirmeyi güçlendiren üç teknik?

Bölüm 6 — cevaplar

1. Hayır. Gizleme yalnız tersine mühendisliği zorlaştırır; açık yerinde durur. Önce düzelt, sonra gizle.
2. Dize/kod binary dosyada kalır; saldırgan bayrağı çevirir/dizeleri okur. Sürümde log'u derleme zamanında çıkarın (makro/ölü kod eleme).
3. Opak yüklemler + sahte bloklar/ölü dallar + durum değişkeni şifreleme & rastgele çıkış (ayrıca ad/dize gizleme).

Hatalı kod

void greet(const char *name) {
    char buffer[16];
    strcpy(buffer, name);          /* no bound */
    printf("Hello %s\n", buffer);
}

name 16 bayttan uzunsa ne olur?

Ne oluyor? · adım adım

• buffer yığında 16 bayt.
• strcpy name'ı sonuna kadar kopyalar, sınıra bakmaz.
• 16'dan uzun name → komşu bellek (dönüş adresi dahil) bozulur.

Saldırı · sonuç

• Kısa taşma: komşu değişken bozulur (mantık hatası).
• Uzun taşma: dönüş adresi bozulur → çökme ya da denetim ele geçirme.
• Korumasızsa: ciddi açık (CWE-121).

Düzeltme 1 · sınırlı kopyalama

int n = snprintf(buffer, sizeof buffer, "%s", name);
if (n < 0 || (size_t)n >= sizeof buffer) {
    /* truncated: reject or flag it */
}

snprintf boyutu bilir ve kesilmeyi bildirir.

Düzeltme 2 · katmanlar

• Kodlama: snprintf (STR31-C).
• Derleyici: -fstack-protector-strong (kanarya).
• FORTIFY: -D_FORTIFY_SOURCE=2 kütüphane çağrısını denetler.
• Test: ASan uzun girdiyle taşmayı yakalar.

Ders: tek satır, çok katman

• Bir hata: strcpy.
• Savunma: doğru fonksiyon + derleyici koruması + sanitizer testi.
• Ama asıl çözüm ilk satırda: sınırlı kopyalama.

Proje · S9 "Kod sağlamlaştırma" — 1

• [ ] Önerilen sürüm bayraklarıyla derle; koruma tablosunu ekle (checksec/dumpbin).
• [ ] clang-tidy/cppcheck ile CERT taraması; ≥ 5 bulguyu düzelt (kural kimliğiyle).

Proje · S9 — 2

• [ ] Testleri ASan + UBSan ile çalıştır.
• [ ] En az bir fuzz hedefi, ≥ 10 dk.
• [ ] Sürümde günlük yok; hassas dize strings çıktısında yok.
• [ ] Her dönüş değeri denetli (ERR33-C); -Werror ile derleniyor.

Önlem kartı: Açıklama → Uygulama → Doğrulama → Kalan risk.

Soru 1

Üç katmandan hangisi hatayı gerçekten kaldırır?

Cevap: Yalnız güvenli kodlama (katman 2). Derleyici/OS korumaları istismarı zorlaştırır; gizleme okumayı yavaşlatır — ikisi de hatayı kaldırmaz.

Soru 2

printf(girdi)'nin en hafif sonucu nedir?

Cevap: Bilgi sızıntısı (%x/%p ile yığın okuma). En ağırı %n ile belleğe yazma.

Soru 3

UAF raporundaki üç yığın izi? Düzeltme hangisinde?

Cevap: Kullanım, serbest bırakma, ayırma. Düzeltme çoğunlukla serbest bırakma noktasında (sahiplik kararı).

Soru 4

if (x + 100 < x) neden silinebilir?

Cevap: İşaretli tamsayı taşması tanımsız davranıştır; derleyici "taşma olmaz" varsayıp denetimi optimize edip silebilir.

Soru 5

Sinyal işleyicide neden printf yok?

Cevap: printf/malloc eşzamansız-güvenli değildir; işleyici bunları kesintiye uğramış bir durumda çağırırsa bozulma olur. Yalnız bir bayrak set edilir (SIG30-C).

Soru 6

ASan hangi taşmayı göremez?

Cevap: Aynı yapının içinde alandan alana taşmayı (aralarında koruma bölgesi yoktur).

Soru 7

İyi bir fuzz hedefinin dört özelliği?

Cevap: Hızlı, deterministik, durumsuz, tek iş.

Soru 8

Kanarya neyi durdurur, neyi durdurmaz?

Cevap: Durdurur: dönüş adresine ulaşan yığın taşması. Durdurmaz: öbek taşması, önceki değişkenlerin bozulması, sızan kanarya.

Soru 9

ASLR neden bir bilgi sızıntısıyla zayıflar?

Cevap: Bir adres sızarsa, saldırgan diğer adresleri ona göre hesaplayabilir; rastgelelik avantajı kaybolur.

Soru 10

Günlüğü çalışma anı bayrağıyla susturmak neden yetmez?

Cevap: Dize binary dosyada kalır ve saldırgan bayrağı değiştirip günlüğü yeniden açabilir. Derleme anında çıkarılmalı.

Soru 11

Düzleştirmeyi güçlendiren üç teknik?

Cevap: Durum değerlerini gizleme, sahte/ölü bloklar, rastgele çıkış noktası (ve opak değerler).

Soru 12

Dize gizleme neden anahtar saklama değildir?

Cevap: Çözülen dize kullanımda bellekte açıktır ve çözme anahtarı programın içindedir; yalnız statik taramayı durdurur.

Özet: bu haftanın tek cümlesi

Önce hatasız kod (CERT + sanitizer + fuzzing), sonra zararı sınırla (derleyici/OS korumaları), en son okumayı zorlaştır (gizleme) — ve hiçbir koruma güvenli kodlamanın yerini tutmaz.

Güvenli kod bir kez yazılmaz; her derlemede araçlarla denetlenir.