View Full Version : TEST: verifichiamo il supporto alle tecnologie DEP e ASLR
Con un semplice test è possibile verificare se gli eseguibili dei nostri programmi preferiti sono stati correttamente compilati per supportare 2 tecnologie fondamentali per la sicurezza:
DEP e ASLR.
http://i49.tinypic.com/34qkc9h.jpg
Come si vede anche dall'immagine postata, è sufficiente trascinare l'oggetto della nostra analisi (che può essere anche un'intera cartella) sopra la scritta "Drop files and folders here" e attendere il verdetto.
ANALIZZATORE (http://icebuddha.com/slopfinder.htm)
L'assenza del supporto a queste tecnologie è indice sicuramente di scarsa attenzione verso il problema "sicurezza" e potrebbe creare qualche problema là dove se ne forzasse l'uso istruendo in tal senso il sistema operativo (mi viene in mente EMET come strumento sfruttabile per operare la forzatura in oggetto).
Non necessariamente comunque un programma "trascurato" sotto il profilo della "sicurezza" è indicatore di pericolo reale per l'utente specie se questo è scarsamente diffuso o non svolge il ruolo di interfaccia per altri servizi.
Parlando però di programmi di sicurezza, se si scoprisse che proprio loro falliscono sarebbe indiscutibilmente una bella figura meschina oltre che un rischio reale per l'utente dato che questi strumenti hanno un installato di milioni di unità.
Confido nei vostri report,
ciao :)
il link sarebbe questo?
http://icebuddha.com/slopfinder.htm
si, l'ho scritto a dimensione 4, "ANALIZZATORE"...:stordita:
Romagnolo1973
12-12-2012, 14:22
non c'è verso di farlo andare su 8, non riconosce l'explorer di 8 almeno a me su chrome dev
comunque si può usare processexplorer o processhacker mettendo le colonne relative
?
8 Pro + Google Chrome permette di fare regolarmente lo spostamento dei file nell'analizzatore...
si, l'ho scritto a dimensione 4, "ANALIZZATORE"...:stordita:
:D :D :D :D
era davanti algi occhi e non lo vedevo,
Romagnolo1973
12-12-2012, 14:48
allora la colpa sarà di chrome dev o qualche settaggio restrittivo che ho messo, ma qua non mi funziona proprio
;38701425']
Se il metodo (analizzatore) di test è attendibile ...
Lo è.
Per confondere un pò le acque, vi faccio vedere una cosa.
[DA PRENDERE CON LE MOLLE!!]
http://i47.tinypic.com/148mdqc.jpg
Allora:
OS = 8 X64
Programma testato = uTorrent
Come da immagine, il file risulta correttamente con le proprietà DEP + ASLR (vedi 1 che è proprio l'esito del nostro servizio on line e 2 che è la sintesi di ProcessExplorer).
Analizzando cmq più a fondo il processo (3), si vede xò che in realtà l'ASLR non è attivo!
Grazie cmq all'apposita forzatura per-processo di EMET, questo risulta rilocato (4). ***EDIT*** Questo punto è sicuramente sbagliato ma non lo modifico di proposito nella speranza di un intervento di eraser.
A questo punto mi vengono in mente una serie di riflessioni ma temo che senza il contributo di eraser sarà alquanto difficile venirne a capo.
Chi vuole cmq riflettere o osservare qualcosa, rifletta che domani si bombardano gli amici di eraser...:D
vedo che le riflessioni si sono sprecate ..cosi' come si sono sprecati i contributi di chi, ad es, ha un qualsiasi programma di sicurezza :D ...
Riallacciandomi cmq all'esempio portato poc'anzi, una riflessione che faccio è questa:
ma se a livello di sistema l'ASLR tanto su 7 che su 8 è impostato su opt-in (vedi anche QUI! (http://www.hwupgrade.it/forum/showpost.php?p=37834242&postcount=4046)), dunque non è abilitato a meno che un processo non lo richieda espressamente (è il caso di tutti i processi di sistema), perchè allora utorrent che è compilato per supportare l'ASLR deve raffidarsi ad EMET per veder rilocata la sua immagine in memoria? :mbe:
E' evidente che mi scontro con una materia che mi risulta troppo difficile....
che infatti l'ASLR a livello di sistema sia settato di default su opt-in lo ricavo ad es. anche da questo post proprio di ieri, cliccami (http://www.hwupgrade.it/forum/showpost.php?p=38700901&postcount=4348).
io pure non riesco ad usare l'analizzatore.
8 pro + chrome dev
per una volta, ie no? :stordita:
sono di fronte al portatile e non sto proprio facendo niente :muro: ....
Fronte ASUS (portatile):
analizzati n-programmi "embedded" (ASUS AI Recovery/Splendid/ Wireless Console/ATK Package/...) ---> andrebbero ammazzati :read:
nVidia driver (in verità, un pò vecchiotti)--> anche qui, da disperazione...
driver audio Realtek--> senza parole...
La situazione, dunque, è disperata...:muro:
Lato positivo?
Chi fa exploit colpisce gira e rigira i soliti nomi altrimenti bisognerebbe emetizzare proprio tutto... :sofico:
Chill-Out
13-12-2012, 19:51
EMSI = NO DEP - NO ASLR
in effetti, si fa prima a dire CHI è in regola...
Parto io:
oltre ai processi MS, abbiamo DefenseWall da un bel pò, Sandboxie da qualche mese...poi? :mbe:
Poi fondamentalmente il vuoto...:D
Perchè gira e rigira, qualche .dll compilata col pennato ci sarà sicuramente in tutti gli altri programmi...
@ chill-out:
dov'è l'errore nel mio ragionamento su utorrent?
Opt-in/opt-out è interpretato bene?
Dove sbaglio, insomma?
***ATTENZIONE***
il post n°9 contiene sicuramente un errore ma ho scelto di proposito di non modificarlo per dar modo ad eraser di poterlo correggere.
Chill-Out
13-12-2012, 21:03
Load <<< >>> Layout
?
.............
è che ci capisco poco o nulla, cmq da una ricerca su google per "image base address 0x400000" sembra che quel particolare indirizzo di memoria sia uno degli indirizzi "preferiti" cui forzare un file .EXE, che "some EXE's might not have reloc tables....as EXE's aren't supposed to need them" ma, al contempo, che sia possibile compilare un file .exe "with /FIXED:NO option in visual studio, which will generate executable with relocation information".
Non ci capisco nulla ma mi pongo ugualmente il problema perchè sul mio PC, ad es., sia l'eseguibile di Winamp che quello di utorrent sono sempre caricati all'indirizzo di cui sopra (0x400000) indipendentemente da reboot e compagnia...
Bah, :confused:
grazie :)
---------------------------------------------
Nel frattempo, confesso di essere entrato in una fase di confusione tale da farmi preferibile il silenzio piuttosto che continuare con esternazioni su questo tema.
Ho superato infatti il mio limite e tutto quello che credevo consolidato è di nuovo in discussione.
Voci da Perugia dicono cmq che con l'anno nuovo eraser dovrebbe ritrovare i suoi tradizionali 5 minuti per portare avanti l'opera di "volontariato" :D :
ecco, per quanto mi riguarda è meglio rimandare tutto a quella data...
Ciao
sto indagando ma ci sono sviluppi...
Al massimo in giornata esterno le novità, perchè a questo punto ho elementi per dire che non fossi fesso io fermo restando tutti i miei limiti sulla materia.
ok, molto semplice:
c'è voluta un pò di testardaggine e circa 10 reboot per capire il mistero ma alla fine ho risolto quello che si è rivelato essere solo un mio problema (spero).
Credo, peraltro, nato tutto da EMET.
In sostanza, mi sono accorto che sul mio PC non veniva riallocata nessuna dll tra un reboot e l'altro.
ZERO.
Ogni dll era mappata sempre al solito indirizzo (di memoria, verificato su quelle "critiche" come user32/kernel32/gdi32).
Il problema, e importante, esisteva.
La "lampadina":
resettato EMET lato protezioni di sistema da massimo @ default.
"Magia":
le 3 dll vengono rimappate correttamente tra un riavvio e l'altro.
Provato di nuovo a riportare le protezioni di sistema su massimo:
la riallocazione degli indirizzi di memoria permane.
Morale:
non chiedetemi cosa fosse successo ma era come sparito il supporto ASLR dal mio PC...:mbe:
Per la cronaca, le protezioni di sistema continuo ad averle impostate sul loro settaggio massimo (Always on/Always on/Opt-in).
Questi misteri dell'informatica, cmq, proprio non li capisco...
ATTENZIONE (chi vuole, cmq, verifichi da solo visto che non pretendo di essere portatore di nessuna verità assoluta):
EMET 3.5 TP settato al massimo in termini di protezione di sistema "rompe l'ASLR" segno evidente che, a dispetto di quello che dicono gli stessi sviluppatori MS, non è perfettamente compatibile con 8.
Sono dovuto necessariamente ritornare alla configurazione di default (DEP: opt-in, SEHOP: opt-in, ASLR: opt-in)
-------EDIT------
giusto a titolo di cronaca, neppure i settaggi di default risolvevano il problema lamentato pertanto sono dovuto ricorrere alla strada più radicare:
la disinstallazione completa di EMET...
mi chiedevo se con emet questa procedura per velocizzare il boot (http://www.msfn.org/board/topic/140262-how-to-speed-up-boot-process-under-windows-vista-or-windows-7/) sia ancora funzionante ....
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.