[ Texas Instruments @ 16.02.2011. 19:32 ] @
Code:

#include <stdio.h>
#include <memory.h>
#include <stdlib.h>

int (*dyncode) (int);

unsigned char code [] = { 0x8b, 0x44, 0x24, 0x04,  /* mov eax, [esp+4] */
                          0x40,                   /* inc eax          */
                          0xc3 };                /* ret              */
 
int main()
{
    dyncode = (int (*)(int)) malloc(sizeof(code));
    
    memcpy(dyncode, code, sizeof(code));
    printf("retval = %d\n", (*dyncode)(41));
    return 0;
}


Ovaj kod, preveden na windowsu 7, majkrosoftovim kompajlerom izvrši se bez problema i ispiše rezultat 42, dok isti ovaj kod peveden na ubuntu 10.10, gcc kompajlerom generiše segmentation fault prilikom izvršavanja. Dakle u windowsu je moguće poturiti dinamički kroz podatke neki kod koji može da se izvrši bez problema, dok je to u linuxu zabranjeno. Da li mislite da ovako nešto može da se zloupotrebi na neki način na windowsu, ovde je primer banalan, samo inkrementira tu vrednost koja se prosledi preko steka, ali da li bi ovako mogao da se poturi i neki maliciozan kod koji bi se bez problema izvršio?
[ maksvel @ 16.02.2011. 20:51 ] @
Hm, kontam da ima veze sa ASLR-om, koji je proradio pod Linuksom, a pod Windowsom ignoriše.
(Ovo možda može i u Security Coding, miriše na shellcode )
[ mmix @ 16.02.2011. 20:59 ] @
He, lepo je to kad iskljucis DEP pa kazes kako Windows ne valja. Naughty.

[ Texas Instruments @ 16.02.2011. 21:08 ] @
Windows 7 je 32b, uključen je DEP. Nemam ja nameru da pokrećem tu večitu temu šta je bolji/lošiji sistem widnows/linux, pošto koristim i jedan i drugi, a windows verovatno i više. Čisto me zanima da li je ovo neki mogući put za zloupotrebu.
[ mmix @ 16.02.2011. 21:12 ] @
Nije ti ukljucen DEP, ukljucen je samo za core windowsa i kriticne servise (ono sto moze da uradi eskalaciju privilegija). Ostalima je DE dozvoljen, ako hoces da ga blokiras prebacis na "Block for all applications" i kod nece proci (narocito ako je DEP hardverski a na vecini novijih procesa jeste).
[ maksvel @ 16.02.2011. 21:29 ] @
U stvari, pitanje bi se moglo preformulisati - da li je potencijalno opasno što DEP nije uključen po defaultu za sve aplikacije pod Windozom?
Mada, jezgro je zaštićeno svakako, a uključivanje za sve aplikacije bi verovatno smorilo korisnike, ne?
[ Goran Arandjelovic @ 16.02.2011. 21:43 ] @
Ne bi smorilo korisnike ni malo, jer aplikacije koje se oslanjaju na DE su ili pisane nogama ili namerno tako pisane, tj. uglavnom maliciozne, a u oba slučaja takve aplikacije korisniku nisu potrebne. Na Win2k8 je DEP po defaultu uključen, ali čak ni na Win7 64bit nije uključen za sve procese.
[ Texas Instruments @ 16.02.2011. 21:50 ] @
Citat:
maksvel: U stvari, pitanje bi se moglo preformulisati - da li je potencijalno opasno što DEP nije uključen po defaultu za sve aplikacije pod Windozom?
Mada, jezgro je zaštićeno svakako, a uključivanje za sve aplikacije bi verovatno smorilo korisnike, ne?

I meni je sad to palo na pamet, zašto nije po defaultu uključeno za sve aplikacije.

A ja opet nisam siguran da li sam dobro uključio, pošto i nakon čekiranja ovoga kao na slici i nakon restartovanja, ovaj programčić se izvrši bez problema.



edit: Za pismene lepo piše da procesor ne podržava DEP. :) I pošto očigledno nemam hardversku podršku za ovo, koje je rešenje u mom slučaju?
[ maksvel @ 16.02.2011. 21:56 ] @
Nije ti podržan hw DEP, pa ne radi "u fullu".
Kod mene bogme puca program samo tako.
A to za default i korisnike: očito postoji dovoljno starijih aplikacija koje muku muče sa DEP-om (a nisu maliciozne, bar ne namerno ), te je MS odlučio izostaviti ovu postavku kao podrazumevanu.
[ mmix @ 16.02.2011. 22:53 ] @
DE prica je malo preduvana, da bi se izvrsio kod iz data segmetna mora prvo da postoji kod koji generise kod u data segmentu a ako postoji takav kod on je od pocetkao mogao da izvrsi sta je vec hteo. Ako imas rupu da pokupis maliciozni kod njemu DE ni ne treba, overflow u browseru je ionako jos od viste fiksiran sa ASLR i EMETom. Ovo je sad vise "better safe than sorry" vrsta price. Sto se tice softverskog DEPa on ne sprecava DE, samo sprecava da exception odleti u DS.
[ EArthquake @ 19.02.2011. 11:00 ] @
resenje bi bilo da eksplicitno mapiras neki deo memorije kao izvrsni
mmap na linuxu
[ Nedeljko @ 11.03.2011. 09:37 ] @
Upravo isprobah program na openSUSE-u 11.3 pod virtuelnom mašinom i radi, tj. ne puca. Kod je doduše morao da pretrpi izvesne izmene

Code:
#include <stdio.h>
#include <memory.h>
#include <stdlib.h>

typedef int (*fun)(int);

fun dyncode;

unsigned char code [] = { 0x8b, 0x44, 0x24, 0x04,  /* mov eax, [esp+4] */
                          0x40,                   /* inc eax          */
                          0xc3 };                /* ret              */

int main()
{
    unsigned char *p = malloc(sizeof(code));

    dyncode = (fun) p;
    memcpy(p, code, sizeof(code));
    printf("retval = %d\n", (*dyncode)(41));

    return EXIT_SUCCESS;
}


Ima li načina da se pod njim uključi neki njegov DEP?
[ maksvel @ 11.03.2011. 10:29 ] @
Meni bogme na 11.3 (32bit), u vmware javlja segmentation fault.
Kompajlirano bez ikakvih dodatnih opcija.
[ Nedeljko @ 11.03.2011. 11:03 ] @
Ja imam VirtualBox.
[ mmix @ 11.03.2011. 11:14 ] @
Odakle potice greska? To je zanimljivo pitanje, ko reaguje na NX fault u virtuelizaciji?
[ maksvel @ 11.03.2011. 11:21 ] @
Evo ga segfault i na Mintu, nevirtualnom.
Ko ne reaguje kod Nedeljka??
Da ti nije neko custom jezgro?
Nagađam, verovatno je nešto trivijalno
[ Nedeljko @ 12.03.2011. 21:31 ] @
Evo, na nevirtuelnoj mašini na openSUSE-u javlja Segmentation fault.
[ maksvel @ 12.03.2011. 22:00 ] @
To je definitivno nešto do vbox-a.
Kad od istog vmware-ovog virtual-diska napravim vm u vbox-u, onaj isti program koji je pre bacao fault (znači već kompajliran pre), sada uredno daje retval=42...
weird.
[ mmix @ 12.03.2011. 22:47 ] @
Ne omora da znaci da je weird, sve zavisi od toga kako Type2 hipervisor handluje NX segfault.