Stack Canaries

Reading time: 5 minutes

StackGuard ve StackShield

StackGuard, EIP (Extended Instruction Pointer)'dan önce, özellikle 0x000aff0d (null, yeni satır, EOF, taşıma dönüşü temsil eder) olarak bilinen özel bir değeri canary olarak ekleyerek buffer overflow'lara karşı koruma sağlar. Ancak, recv(), memcpy(), read() ve bcopy() gibi fonksiyonlar hala savunmasızdır ve EBP (Base Pointer)'yi korumaz.

StackShield, tüm dönüş adreslerini (EIPs) saklayan bir Global Return Stack tutarak StackGuard'dan daha sofistike bir yaklaşım benimser. Bu yapı, herhangi bir taşmanın zarar vermemesini sağlar, çünkü saklanan ve gerçek dönüş adresleri arasında bir karşılaştırma yapılmasına olanak tanır. Ayrıca, StackShield, EIP'nin beklenen veri alanının dışına işaret edip etmediğini tespit etmek için dönüş adresini bir sınır değeri ile kontrol edebilir. Ancak, bu koruma Return-to-libc, ROP (Return-Oriented Programming) veya ret2ret gibi tekniklerle aşılabilir, bu da StackShield'in yerel değişkenleri de korumadığı anlamına gelir.

Stack Smash Protector (ProPolice) -fstack-protector:

Bu mekanizma, EBP'den önce bir canary yerleştirir ve yerel değişkenleri daha yüksek bellek adreslerinde konumlandıracak şekilde yeniden düzenler, böylece diğer değişkenleri yazmalarını engeller. Ayrıca, yerel değişkenlerin üzerinde yığılan argümanları güvenli bir şekilde kopyalar ve bu kopyaları argüman olarak kullanır. Ancak, 8'den az eleman içeren dizileri veya bir kullanıcının yapısı içindeki tamponları korumaz.

Canary, /dev/urandom'dan türetilen rastgele bir sayıdır veya varsayılan değeri 0xff0a0000'dır. TLS (Thread Local Storage) içinde saklanır, bu da iş parçacıkları arasında paylaşılan bellek alanlarının iş parçacığına özgü global veya statik değişkenlere sahip olmasına olanak tanır. Bu değişkenler başlangıçta ana süreçten kopyalanır ve çocuk süreçler, ana veya kardeşleri etkilemeden verilerini değiştirebilir. Ancak, eğer bir fork() yeni bir canary oluşturmadan kullanılırsa, tüm süreçler (ana ve çocuklar) aynı canary'i paylaşır, bu da onu savunmasız hale getirir. i386 mimarisinde, canary gs:0x14'te, x86_64'de ise fs:0x28'de saklanır.

Bu yerel koruma, saldırılara karşı savunmasız tamponlara sahip fonksiyonları tanımlar ve bu fonksiyonların başına canary yerleştirmek için kod enjekte eder ve sonunda bütünlüğünü doğrulamak için kontrol eder.

Bir web sunucusu fork() kullandığında, canary'yi byte byte tahmin etmek için bir brute-force saldırısını etkinleştirir. Ancak, fork()'tan sonra execve() kullanmak bellek alanını yazdığı için saldırıyı geçersiz kılar. vfork(), çocuk sürecin yazma girişiminde bulunana kadar kopyalamadan çalışmasına izin verir; bu noktada bir kopya oluşturulur ve süreç oluşturma ve bellek yönetimi için farklı bir yaklaşım sunar.

Uzunluklar

x64 ikili dosyalarında, canary çerezi bir 0x8 byte qword'dur. İlk yedi byte rastgeledir ve son byte bir null byte'dır.

x86 ikili dosyalarında, canary çerezi bir 0x4 byte dword'dur. İlk üç byte rastgeledir ve son byte bir null byte'dır.

Bypass'ler

Canary'yi sızdırmak ve ardından kendi değeriyle (örneğin, buffer overflow) üzerine yazmak.

• Eğer canary çocuk süreçlerde fork edilirse, bir byte bir seferde brute-force yapmak mümkün olabilir:

BF Forked & Threaded Stack Canaries

• Eğer ikili dosyada ilginç bir sızıntı veya keyfi okuma açığı varsa, onu sızdırmak mümkün olabilir:

Print Stack Canary

• Yığın üzerinde saklanan işaretçileri üzerine yazmak

Yığın, bir yığın taşmasına karşı savunmasızsa, string'lere veya üzerine yazılabilecek fonksiyonlara ait adresleri içerebilir; bu da açığı istismar etmek için canary'e ulaşmadan yapılabilir. Kontrol et:

Pointer Redirecting

• Hem ana hem de iş parçacığı canary'sini değiştirmek

Canary ile korunan bir iş parçacıklı fonksiyonda bir buffer overflow, iş parçacığının ana canary'sini değiştirmek için kullanılabilir. Sonuç olarak, bu önlem işe yaramaz çünkü kontrol, aynı (değiştirilmiş) iki canary ile kullanılır.

Ayrıca, canary ile korunan bir iş parçacıklı fonksiyonda bir buffer overflow, TLS'de saklanan ana canary'yi değiştirmek için kullanılabilir. Bunun nedeni, bir iş parçacığının yığında bir bof aracılığıyla TLS'nin saklandığı bellek konumuna ulaşmanın mümkün olabileceğidir.
Sonuç olarak, bu önlem işe yaramaz çünkü kontrol, aynı (değiştirilmiş) iki canary ile kullanılır.
Bu saldırı, yazıda gerçekleştirilmiştir: http://7rocky.github.io/en/ctf/htb-challenges/pwn/robot-factory/#canaries-and-threads

Ayrıca, https://www.slideshare.net/codeblue_jp/master-canary-forging-by-yuki-koike-code-blue-2015 sunumunu kontrol edin; bu sunumda genellikle TLS'nin mmap ile saklandığı ve bir iş parçacığı yığını oluşturulduğunda bunun da mmap ile oluşturulduğu belirtilmektedir; bu da önceki yazıda gösterildiği gibi taşmayı mümkün kılabilir.

• __stack_chk_fail GOT girişini değiştirmek

Eğer ikili dosya Partial RELRO'ya sahipse, o zaman __stack_chk_fail'in GOT girişini değiştirmek için keyfi bir yazma kullanarak sahte bir fonksiyon haline getirebilirsiniz; bu, canary değiştiğinde programı engellemez.

Bu saldırı, yazıda gerçekleştirilmiştir: https://7rocky.github.io/en/ctf/other/securinets-ctf/scrambler/

Referanslar

• https://guyinatuxedo.github.io/7.1-mitigation_canary/index.html
• http://7rocky.github.io/en/ctf/htb-challenges/pwn/robot-factory/#canaries-and-threads
• https://7rocky.github.io/en/ctf/other/securinets-ctf/scrambler/