Sistema di Scansione Bayesiana/Euristica

Moderators: forart, Davy Bartoloni, gabrielilardi

PUOjACKz
Posts: 116
Joined: Tue Jan 03, 2006 3:52 pm

Post by PUOjACKz »

folle_invasato wrote:Personalmente, un addetto coder, della sicurezza dell'OS, che non sà cos'è un Behavior Blocker.

Onestamente neanche io so cos'è un behavior blocker. Il termine non l'avevo mai sentito prima di questa discussione. Mi sono fatto una piccola idea però...
Ok, ma se uno è addetto alla sicurezza di un OS, vulnerabile in quanto il più possibile compatibile con Windows, certe cose, IMHO, dovrebbe saperle.
Esistono 2 tipi di RootKit: i Kernel-Rootkit e gli User-Rootkit

Per le rootkit hai dimenticato un piccolo particolare. Una user-rootkit gira in modalità utente. Quindi non ha nessun modo di intaccare il kernel di un sistema NT. Altera solo i risultati delle API Windows per nascondere il proprio operato. Una rootkit a livello kernel ha a disposizione tutta la memoria kernel (correggimi se dico una cavolata ma mi sembra che la memoria del kernel è condivisa tra tutto il codice che gira in modalità kernel...è per questo che driver difettosi per esempio sono la maggiore fonte di problemi..).
Il fatto è questo: con un priviledge escalation, un code injection nel programma giusto o un buffer overflow, poi il resto vien da sè. Ma affermare che, con un utente blindato, sei al sicuro al 100%, è una cazzata e chiunque, che ne sappia un briciolo di sicurezza, te lo può confermare.
Personalmente, un qualsiasi tecnico di sicurezza informatica, deve proteggere il sistema, il più possibile. La perdita di dati, di per sè, non è tollerata.

Secondo me dovresti anche differenziare l'ambiente home dall'ambiente business. In un ambiente business i dati (che effettivamente hanno un valore) sono protetti da varie soluzioni di ridondanza/backup quindi il problema dei di perdita di dati è molto ridotto (anche perchè l'eventualità che un malware si installi nei sistemi è *molto* ridotta).
Ok, ma non per questo, un utente dev'essere sprotetto. Molti dei problemi, legati alla rete, son stati risolti quando Windows XP ha implementato il firewall, altrimenti, prima c'era chi proprio non si curava di cosa succedeva nel suo computer.
Inoltre, son stati sollevati dei lamenti riguardo lo stupro di performance che questi programmi causerebbero. IMHO, non sarà mai uguale a qualche malware particolarmente sofisticato. Inoltre, ho parlato con dei programmatori e questi mi han sottolineato alcuni fattori:

1) Anche il codice più assurdo, può diventare leggero (se non leggerissimo) quando ottimizzato. Non è il numero di opzioni che determina le performance necessarie per il programma.

2) L'hardware del computer diventa obsoleto nel giro di pochissimo tempo. Già Intel ha dichiarato di mettere in campo, nei prossimi 2 anni, i quadra-core, i quali svilupperanno velocità molto alte, rispetto ad ora, mentre AMD, se non erro, riuscirà nell'impresa, ancora prima. Uno dei programmatori m'ha detto che, di per sè, le velocità di un dual o quadra-core, per un utente normale, sono irrilevanti.
Mi son stati portati esempi di considerazioni, effettuate da certi utenti, che dicevano "Mah, son passato da un 450 ad un 3,4 Ghz, ma non l'ho mica notata la differenza. Andavo via bene prima, come vò bene ora.". Questo non è un elogio nel programmare da culo i software, tanto, c'è la CPU che fà il tutto, ma semplicemente, che se si aggiunge qualche tool, il sistema diventa più sicuro e le performance non ne risentono.

3) Linux è un Kernel, ideato per essere eseguito anche in sistemi dedicati. Pertanto, tale OS dev'essere snellissimo ed ottimizzato al massimo, in quanto, potrebbe trovar impiego in ambienti ove la capacità di calcolo è ancora ridotta.
Tuttavia, la programmazione di un OS, deve rapportarsi ad esigenze effettive dell'utente. Ottimizzare ROS, è una buona cosa, ma arrivare a togliergli tutto, per vantarsi perchè l'OS funziona su un 80286, è ridicolo. In ambienti mission-critical, è male trovare dei computers obsoleti, in quanto, se qualcosa si rompe, poi son dolori. Non parlo di un computer usato per scrivere 2 fogli in Excel, bensì, di un server.
Ciò non vuol dir nulla. Non è che perchè un software è opensource, è esente da bugs e, di per sè, il Priviledge Escalation è un problema non da poco.

Per quanto riguarda il problema dei bugs ti faccio notare una cosa: neanche il tuo behavior blocker non è esente da bugs ;)
Ovvio, ma di certo, aumenta il grado di protezione a livello utente, cosa non da poco.
La famosa funzione "RunAs", può essere utilizzata per ottenere lo stesso scopo

Per la funzione RunAs faccio le seguenti considerazioni. Se lanci un programma tramite RunAs il sistema assegna le dovute credenziali a quel processo. E' molto diverso che girare come amministratore. se il processo poi è a 16 bit entra in gioco anche il fatto dell'esecuzione del tuo processo sotto WOW. Io seguo la mentalità di w3seek che sostiene che se tu lanci un processo come sysadmin è perchè ti FIDI e CONOSCI quel processo (inoltre come dici tu ti serve per compatibilità con win9x..che per me implica che l'hai come minimo già usato su win9x e NON ti ha creato danni!).
Eh, grazie, ma io il computer lo sò usare ;)
Il problema è quando ti trovi nei casi, in cui, devi usare parecchi programmi con RunAs e questi son uno più capriccioso dell'altro.
Ti dirò, ora, su XP, non ho malware on the wild. Sono un firewall e un AV. Basta.
ReactOS non credo sia nato per agevolare l'esecuzione di programmi per Win9x in quanto c'è scritto che nasce per ottenere la compatibilità con NT4...mai provato a far andare un programma per 9x su NT4? :P
Qua, il discorso, è un altro. Su ROS, vogliono creare un sistema operativo uguale ad XP, il quale, implementa una funzione di compatibilità con OS Win9x.
Ok, son d'accordo. La compatibilità, però, in questo modo, và a farsi friggere. Se poi, riescono a far funzionare i programmi di Win98 (cosa che vedo molto ardua), in ambiente NT, via compatibilità, il codice da introdurre verrà triplicato. Questo, in quanto, in Win9x, erano i programmi a gestire parte del colloquio con l'OS. Cosa che spiega, tra l'altro, perchè spesso capitassero dei casini assurdi. Nella tecnologia NT, tutto questo è cambiato radicalmente, in quanto, effettivamente, si è su un vero OS e non su una macchina virtuale che imita il DosShell e l'MS-DOS, come lo era, ad esempio, Win98 (particolare scoperto in seguito ad una ricerca approfondita sull'OS, presso documentazione targata Microsoft).


Allora...piano con gli scavi!

Il fatto che in win9x se si piantava un programma era un casino è dovuto al fatto che la memoria era tutta condivisa. Kernel, drivers e programmi condividevano uno spazio di memoria unico, senza restrizioni d'uso. Sotto l'architettura NT ogni processo ha uno spazio di memoria separato. L'unica eccezione sono i programmi che tu fai girare con NTVDM per provare a far funzionare software a 16 bit. A meno che tu non lo richieda esplicitamente tutti i programmi che vengono eseguiti con NTVDM hanno uno spazio di memoria comune (che torna utile in certe situazioni). Altro caso di memoria condivisa in NT dovrebbe essere lo spazio del kernel.

(OT: la storia di WIN98-macchina virtuale-MS/DOS mi incuriosisce...sapevo si che non era totalmente a 32 bit ma da quello che so io è un OS vero e proprio..)
Son rimasto sbalordito quanto te, eppure, o quelli che han raccolto le informazioni avevano bevuto, oppure, effettivamente è così. Di per sè, ora che ci penso meglio, Microsoft ha sempre tenuto molte cose nascoste. Pare che, effettivamente, il problema dei crash fosse stato ereditato da MS-DOS.
WinXP, ora come ora, ci son 3 profili predefiniti: Amministratore (che può far tutto), Utente Limitato (che già causerebbe problemi a chi non è esperto d'informatica) ed utente Blindato al massimo.

Non vorrei ancora sbagliarmi..ma mi sa che XP pprò ha gli stessi gruppi di utenti del 2000.
Sì, ci sono. Occorrerà, pertanto, nel pannello di controllo, alla voce "Account Utente", modularizzare meglio tutto il discorso. Nella guida che compare, quando si entra in tale funzione, è MS stessa che afferma dell'esistenza di 2 tipi di account: "Amministratore del Computer" ed "Utente limitato".
Qua, l'addetto, sta affermando che Windows è sicuro e che un applicazione, che necessiti di essere eseguita con privilegi amministrativi, è pericolosa e non dovrebbe essere avviata.

E' vero..punto!
Esistono software che richiedono il privilegio di amministratore, per poter essere eseguiti e son completamente innocui (se non addirittura software per la sicurezza).
Qui, l'addetto alla sicurezza, sta dicendo che non vi è necessità di tutti i programmi presenti oggi giorno, per tenere il sistema sicuro, definendo tali provvedimenti come "Stupid Security" (sicurezza stupida o da stupidi).
Ogni commento, per chi legge, è libero.

Anche qui è vero. L'unica cosa utile può essere un minimo di firewall per non beccarsi i virus "in the wild" dalla rete e un antivirus aggiornato.
Con un minimo di conoscenze riesci a debellare un virus in meno di 10 minuti, bastardo che sia. X le rootkit mi astengo. Non ho ancora provato a giocarci.
Calma, calma. Con delle conoscenze, devi saper cercare su mezzo sistema e ti occorre dai 30 minuti in sù, sempre se non fai danni. Per non parlare di tutti i sistemi impiegati dai malware per far casino (es. Injection nelle DLL, Register Climbing, RootKit ecc..). I tali di ROS, però, in questo punto, dissero di voler introdurre un firewall vero e proprio, e qualche altra particolarità presente su Vista.
Per l'ennesima volta, sono contrario a quanto da lui affermato, e cioè che la sicurezza non riguarda l'OS. Inoltre, afferma che nei sistemi Unix-Like (Linux), non vi è il bisogno di AV ecc., non tenendo in considerazione dei molteplici aspetti che separano il mondo Windows da quello Unix e Unix-Like. Semplicemente, siccome, su Linux, basta usare un utente non privilegiato, che tutto và a posto (e non è completamente vero questo, ma solo Security By Obscurity), così, anche su Windows, secondo il parere dell'addetto, è la stessa cosa. Lasciatemi, però, diffidare da tale affermazione.

Io credo che ci siano *parecchi* esperti di sicurezza al mondo. Ma mi manca ancora un OS che implementi trucchi di sicurezza diversi dalle (uso il termine win) ACL.
Linux usa le capabilities, oltre delle ACL. Ed è solamente una delle tante cose.
La reale differenza tra un sistema windows e uno linux o unix o che sia è l'UTENTE. Chi installa linux lo fa perchè ne capisce. La maggior parte delle persone che installa windows lo fa perchè necessita di usare un PC e a malapena sa cos'è un file e una cartella.

Just my 2 cents ;)
D'accordo. Sta di fatto, però, che non si può pretendere di fare un copia-incolla dei metodi di sicurezza, usati su un OS, per adattarli ad un altro.

User avatar
Davy Bartoloni
Posts: 1483
Joined: Wed Jan 04, 2006 11:31 pm
Location: Cuneo
Contact:

Post by Davy Bartoloni »

Diamo per sicuro, che qualunque cosa il So effettui per la protezioen del sistema, o che sia parte del SO in fase di installazione, sara' la prima parte che varra' colpita da chi vuole cmq "rovinare il SO"...

... io sono daccordo che installare office, corel --- . ., . o altre applicazioni , che ne so Adobe, o altro... che richiedono un numero molto alto di modifiche al sistema, la cosa di chiedere le conferme per ogni voce diventa improponibile... ..

ma considferiamo che la maggiorparte dei programmi di uso comunue, dal giochino al programma per rippare un mp3. in genere non effettuano modifiche particolari al registro e non sparpagliano file per tutto l'hard disk.. quindi avvertire in ogni caso l'utente con il numero di files istallati, e dove.. equante chivi di registro vengono modificate, serve in qualche modo a far capire se un "presunto file innocuo" invece stia' decisamente facendo un casino a livello di registro... in questo caso, un backup all'indietro , dopo la sua installazione sarebbe un opzione decisamente comoda...

cazz ora devo tornare a lavoro.. continuo stsera

ciaoa e tutti

PUOjACKz
Posts: 116
Joined: Tue Jan 03, 2006 3:52 pm

Post by PUOjACKz »

Davy Bartoloni wrote:Diamo per sicuro, che qualunque cosa il So effettui per la protezioen del sistema, o che sia parte del SO in fase di installazione, sara' la prima parte che varra' colpita da chi vuole cmq "rovinare il SO"...
Qualsiasi programma è vulnerabile. Di certo, se il software è integrato nell'OS, quest'ultimo può gestirlo in modo più sicuro (es. evitare che venga crashato, permetterne la auto-riaccensione ecc., senza codice mobile vulnerabile a modifiche).
Inoltre, oltre ad una maggior compatibilità col sistema stesso (e quindi minori problemi di DoS indiretti, causati da un 3rd party software che và a crashare a caso tutto il resto), tale funzione aumenta la sicurezza di tutto l'ambiente, in quanto, sensibilizza l'utente.
... io sono daccordo che installare office, corel --- . ., . o altre applicazioni , che ne so Adobe, o altro...
Ecco, qua, invece, non ci siamo proprio. Questo tipo di software non dovrebbero essere installati in un OS. ROS eredita, da XP, già un piccolo set, alquanto semplice, di utilità per la modifica d'immagini e testi, cosa alquanto sufficiente. Per il resto, poi, sarà l'utente a decidere cos'installare e cosa no. Se ora iniziamo ad infilarci dentro di tutto, che proprio non ha una minima cognizione con i propri scopi di funzionamento, non ne usciamo più. Chi vuol giocare, non necessita di Office o OpenOffice e viceversa.
Non si può comparare una feature di sicurezza, con un programma specializzato su un particolare ambito. Non è che se installi openoffice, allora il sistema non si becca più malware e non ti occorre più il firewall. Sia che tu usi il computer per giocare, che per lavorare, devi essere al sicuro.
che richiedono un numero molto alto di modifiche al sistema, la cosa di chiedere le conferme per ogni voce diventa improponibile... ..
Il funzionamento del behavior blocker e la sua comodità, dipendono dalla furbizia di chi lo implementa. Non è che un behavior blocker, ogni volta che accendi Word, ti chiede se vuoi accenderlo. Semplicemente, la prima volta, quando il suo DB è vuoto, ti chiede se è un programma che consideri sicuro (e se hai controllato), permettendoti di avviarlo solo in caso di sicurezza. All'avvio successivo, il Behavior blocker sà già che tale programma è sicuro e non ti chiede più nulla. Inoltre, non è che per ogni file scritto, il Behavior blocker ti chiami. No. Solo in caso di avvio di un programma, di sostituzione di un programma che hai considerato sicuro e quando quest'ultimo và a richiamare altri software, cioè le azioni più sospette e a rischio. Tutto il resto non viene analizzato, nè monitorato, nè richiede prompting da parte dell'utente.

In soldoni, non è che il Behavior blocker, se tu crei un file, lui ti chieda se desideri sul serio crearlo. Quelli sono affari tuoi. Di per sè, inoltre, creare un file non significa nulla. Può occupare spazio, ma non è che danneggi il sistema.
ma considferiamo che la maggiorparte dei programmi di uso comunue, dal giochino al programma per rippare un mp3. in genere non effettuano modifiche particolari al registro e non sparpagliano file per tutto l'hard disk..


Questo, di per sè, se non si tiene in considerazione alcuni aspetti. Le proposte inerenti ad un registro blindato ed ad una specie di jail che crei un finto registro, sono state introdotte per vari motivi. Nel primo caso, per evitare che certi malware sfruttino dei fattori dell'OS (es. Il Windows Script Host) per autoavviarsi e quindi effettuare un injection nel registro, permettendosi l'autoesecuzione ad ogni avvio, ad insaputa dell'utente. Nel secondo caso, invece, è per una questione di comodità: certi programmi li si infilano su un registro finto, il quale può essere cestinato alla fine dell'utilizzo del programma, lasciando intonso il registro principale di sistema. Nella speranza che i programmi opensource creati per ROS, non usino proprio i registri di sistema (come avviene su Linux).
quindi avvertire in ogni caso l'utente con il numero di files istallati, e dove.. equante chivi di registro vengono modificate, serve in qualche modo a far capire se un "presunto file innocuo" invece stia' decisamente facendo un casino a livello di registro... in questo caso, un backup all'indietro , dopo la sua installazione sarebbe un opzione decisamente comoda...
Era una proposta di monitoraggio, limitata ad una sandbox/jail ipotetica. Di per sè, si và a controllare solo cosa fà un programma sospetto. Monitorare tutto il sistema non ha senso, ma non si può bocciare un idea, solo perchè qualcuno, in modo capraiolo, accende tutto e chi s'è visto s'è visto. Più che altro, tu prima hai affermato " in genere non effettuano modifiche particolari al registro e non sparpagliano file per tutto l'hard disk..". Se però, nel sistema, sfruttando un buffer overflow, riescono ad eseguire un malware che effettua, in vie traverse e alquanto oscure, un code injection, ecco che anche il giochino stile araknoid, se eseguito, può rappresentare un rischio per l'OS. Il Behavior Blocker ferma anche questo tipo di comportamento, non gestito dal DEP.

folle_invasato
Posts: 134
Joined: Thu Jan 13, 2005 9:11 pm
Location: Pordenone, Italy

Post by folle_invasato »

Di certo, se il software è integrato nell'OS, quest'ultimo può gestirlo in modo più sicuro (es. evitare che venga crashato, permetterne la auto-riaccensione ecc., senza codice mobile vulnerabile a modifiche).
Inoltre, oltre ad una maggior compatibilità col sistema stesso (e quindi minori problemi di DoS indiretti, causati da un 3rd party software che và a crashare a caso tutto il resto), tale funzione aumenta la sicurezza di tutto l'ambiente, in quanto, sensibilizza l'utente.
Secondo me è l'esatto contrario..se il sw è integrato nell'OS (che poi è un'affermazione fumosa) rende il tutto più instabile..
Il funzionamento del behavior blocker e la sua comodità, dipendono dalla furbizia di chi lo implementa. Non è che un behavior blocker, ogni volta che accendi Word, ti chiede se vuoi accenderlo. Semplicemente, la prima volta, quando il suo DB è vuoto, ti chiede se è un programma che consideri sicuro (e se hai controllato), permettendoti di avviarlo solo in caso di sicurezza. All'avvio successivo, il Behavior blocker sà già che tale programma è sicuro e non ti chiede più nulla. Inoltre, non è che per ogni file scritto, il Behavior blocker ti chiami. No. Solo in caso di avvio di un programma, di sostituzione di un programma che hai considerato sicuro e quando quest'ultimo và a richiamare altri software, cioè le azioni più sospette e a rischio. Tutto il resto non viene analizzato, nè monitorato, nè richiede prompting da parte dell'utente.
Ecco..prendiamo un esempio completo: Word.

All'avvio il SO carica l'immagine di winword.exe, il tuo behavior blocker parte e ti chiede se il programma è valido. Fino a qui tutto ok...

Il sistema poi carica tutte le dll linkate direttamente all'eseguibile. ovviamente ognuna di queste librerie è eseguibile quindi (da quello che dici tu) va controllata almeno una volta. Queste DLL sono più o meno una cinquantina. (io se arrivo alla decima è tanto..se il behavior blocker arriva alla ventesima è un miracolo)..anche perchè come fa un utente a sapere che una dll è buona o cattiva? Lo stesso discorso vale per le DLL caricate con LoadLibrary.

Il tuo behavior blocker poi protegge eventuali oggetti di sistema da uso improprio da parte del software? Non so..utilizzate di frequente sono x esempio pipes e sezioni...qui le domande si moltiplicano, anche perchè dubito che si possa sapere che il processo X era stato autorizzato all'oggetto Y dopo un riavvio del sistema.

Un'altro piccolo problema è cosa succede al behavio blocker dopo che installo (per esempio) un service pack? Tutte le immagini sono tutte da ricontrollare? E durante l'installazione mi riempie di domande del tipo "La dll ABC considerata sicura sta per essere sostituita dal processo XYZ, continuare?"


Secondo me la cosa del behavior blocker è semplicemente troppo complessa..
Nella speranza che i programmi opensource creati per ROS, non usino proprio i registri di sistema
Dehehe..purtroppo nelle specifiche Microsoft x di Windows consigliano di usare il registro di sistema per memorizzare le impostazioni del software.

PUOjACKz
Posts: 116
Joined: Tue Jan 03, 2006 3:52 pm

Post by PUOjACKz »

Secondo me è l'esatto contrario..se il sw è integrato nell'OS (che poi è un'affermazione fumosa) rende il tutto più instabile..
Se l'implementazione, nell'OS, viene fatta in modo adeguato, non lo è.
Ecco..prendiamo un esempio completo: Word.

All'avvio il SO carica l'immagine di winword.exe, il tuo behavior blocker parte e ti chiede se il programma è valido. Fino a qui tutto ok...

Il sistema poi carica tutte le dll linkate direttamente all'eseguibile. ovviamente ognuna di queste librerie è eseguibile quindi (da quello che dici tu) va controllata almeno una volta.
Il Behavior Blocker, almeno per quanto è stato deciso finora, non controlla le DLL. Questo è un problema di sicurezza abbastanza importante, in quanto, alcuni attacchi DoS tendono a manipolare o riscrivere il contenuto delle librerie, trasformando dei file innocui in bombe ad orologeria.
Queste DLL sono più o meno una cinquantina. (io se arrivo alla decima è tanto..se il behavior blocker arriva alla ventesima è un miracolo)..anche perchè come fa un utente a sapere che una dll è buona o cattiva? Lo stesso discorso vale per le DLL caricate con LoadLibrary.
Infatti, esiste una funzione, sul Sygate, che controllava questa cosa, ma di per sè, era poco usata e disattiva predefinitamente. IMHO, è un controllo inapplicabile, sia in termini di risorse da impiegare, che di tedio legato all'utente. IMHO, è buona cosa che il Behavior Blocker tenti di identificare i code injection effettuati da programmi attivi, verso altri programmi e basta. Il resto, esula dalle sue funzioni.
Il Behavior Blocker non dev'essere inteso come una panacea per tutti i mali, bensì, uno strato di sicurezza, che crei un certo grado di ridondanza, contro vari problemi.
Da tener in considerazione che: col Behavior Blocker, i rootkit autoinstallanti non s'installano. Gli spyware o comunque un qualsiasi programma, che effettui un tentativo di comunicazione con l'esterno, non desiderato dall'utente, viene segato (e quindi, un Anti-Spyware, di per sè, è inutile, in alcune sue parti). Il BB, però, non può far tutto.
Tornando al discorso di prima, IMHO, ritengo il controllo effettuato sulle librerie, impossibile da gestire, per un BB, in termini di performance. E' un rischio che l'utente deve correre, nel fidarsi delle DLL di certi programmi. Se, però, avvengono dei controlli, preventivi, sul programma installato, in questione, via software AV o Engine Euristico, direi che si può già sentirsi più sicuri. Ma controllare ogni cosa, è assurdo.
Il tuo behavior blocker poi protegge eventuali oggetti di sistema da uso improprio da parte del software? Non so..utilizzate di frequente sono x esempio pipes e sezioni...qui le domande si moltiplicano, anche perchè dubito che si possa sapere che il processo X era stato autorizzato all'oggetto Y dopo un riavvio del sistema.
La funzione del behavior blocker è, ora come ora:

- Bloccare l'autoesecuzione di un programma, senza che l'utente lo sappia (qualsiasi tipo di eseguibile esso sia, cosa comune in tutti i BB)
- Evitare le sostituzioni senza che l'utente lo sappia. Questo evita il tentativo di trojanizzazione di certi programmi, es specie dai rootkit, oppure, evita, all'utente, la sostituzione di un programma di una certa versione, con una, ad esempio, di versione più obsoleta. Ovviamente, questo genere di controlli, dev'essere fatto da parte dell'utente, controllando le informazioni fornite dal BB.
- Identificare quando un programma avvia un altro programma, questo, in quanto, certi malware depositano dei programmi, nel sistema, per poi avviarli, all'insaputa dell'utente. Addirittura, il processguard, notifica, all'utente, la stringa passata al secondo programma, in modo da poter permettere cosa sta avvenendo (se un attività pericolosa o no, ovviamente, queste info, implicano delle conoscenze a priori, ma è sbagliato rimuovere tale possibilità)
- E' stata proposta un idea, da parte del behavior blocker, di controllare l'attività di pianificazione, ma penso sia possibile rimuoverla, blindando, ulteriormente, tale funzionalità dell'OS, così come Injection di shortcut ecc. nelle cartelle di autoavvio (Es. quella di esecuzione automatica), esentando, diminuendo, quindi, il carico di lavoro del BB e agendo, direttamente, via Kernel
- Controllare i programmi attivi, qualora tentino di effettuare un Code Injection, in quanto, s'è preferito rimuovere il controllo dei Buffer Overflow, optando per una totale implementazione del DEP, cosa, secondo me, di una bontà inimmaginabile, per la sicurezza
- Controllare riguardo le Application Hijacking, cioè quando un programma maligno tenta di intercettare e manipolare i dati e i comandi in comunicazione tra DLL e Windows Hooks, nelle applicazione avviate in Windows. In questo modo, i Keylogger vengono completamente segati e la privacy, di sistema, aumenta a dismisura
- Riguardo il controllo del traffico sospetto UPnP, direi, IMHO, di rimuovere tale funzionalità dal Behavior Blocker e gestire il tutto, in modo differente, direttamente su kernel, con configurazioni, stile Gestione delle Periferiche Hardware ecc. Ciò manterrebbe il sistema sicuro e rimuoverebbe un carico dal BB

Queste sono solo alcune proposte, in fase di discussione, sebbene sia meglio gestire, come ho già appena specificato, certi problemi, direttamente, via Kernel, con altri tipi di configurazione che non via un programma di filtering. Riguardo il BB, esiste una versione remota di Behavior Blocker anche sull'SP2. Non sò se avete notato, quando c'è il firewall acceso, che vi appare un popup ove si richiede, all'utente, se si vuol sbloccare il programma oppure no. Bene, quello è una versione molto rudimentale del BB. Ahimè, purtroppo, la sua implementazione è scadente, in quanto, dopo varie analisi, mi son accorto che il programma viene eseguito ugualmente, cosa che un BB non deve permettere.

Da notare che tutta questa attività, e molte altre, il processguard le fà, alloccando, in memoria, 1 processo da circa quasi 300 Kbyte.
Un'altro piccolo problema è cosa succede al behavio blocker dopo che installo (per esempio) un service pack? Tutte le immagini sono tutte da ricontrollare? E durante l'installazione mi riempie di domande del tipo "La dll ABC considerata sicura sta per essere sostituita dal processo XYZ, continuare?"
IMHO, se viene implementato in una distro, direi che parte del DB del BB, può essere già completata con i vari applicativi presenti già nel sistema e considerati sicuri. Riguardo il prompting delle sostituzioni, in realtà, il BB mantiene, in memoria, la versione del programma, considerata affidabile. Nell'esecuzione, il BB controlla la versione che ha in memoria, con quella del programma. Se queste risultano differenti, avviene un prompt. Qualora vi sia un programma che cambia versione, di frequente, basta mettersi d'accordo, nella discussione del BB ed elaborare delle opzioni in modo da considerare, certi files, anche se sostituiti, sicuri (sebbene sia pericoloso).
Secondo me la cosa del behavior blocker è semplicemente troppo complessa..
No, è semplicemente che non hai le idee ben chiare, in quanto, non è un programma molto diffuso. Non avvengono controlli così massicci, da parte del BB. Son, più semplici e indirizzati a ciò che, effettivamente, risulta sospetto, non coprendo, tutti i buchi, ma è anche ovvio. Non esiste una soluzione definitiva per la sicurezza ed è proprio per questo che tali programmi devono avere una certa lieve ridondanza ed essere fault tollerant. Ad esempio, io ho proposto pure le capabilities, che volevo ufficialmente, introdurre come privilegi riferiti ai programmi eseguibili. Anche quelli generano una certa ridondanza, ma dove fallisce uno, c'è l'altro sotto a tener botta. E' così che funziona, in sicurezza, dappertutto.
Dehehe..purtroppo nelle specifiche Microsoft x di Windows consigliano di usare il registro di sistema per memorizzare le impostazioni del software.
Lo sò, ma questo ci costringe a riprogettare alcune parti inerenti la sicurezza. Anzi, qualcuno parlò di ACL sui registri. Potrebbe spiegare più dettagliatamente cos'intendeva dire?

folle_invasato
Posts: 134
Joined: Thu Jan 13, 2005 9:11 pm
Location: Pordenone, Italy

Post by folle_invasato »

Infatti, esiste una funzione, sul Sygate, che controllava questa cosa, ma di per sè, era poco usata e disattiva predefinitamente. IMHO, è un controllo inapplicabile, sia in termini di risorse da impiegare, che di tedio legato all'utente. IMHO, è buona cosa che il Behavior Blocker tenti di identificare i code injection effettuati da programmi attivi, verso altri programmi e basta. Il resto, esula dalle sue funzioni.
Il Behavior Blocker non dev'essere inteso come una panacea per tutti i mali, bensì, uno strato di sicurezza, che crei un certo grado di ridondanza, contro vari problemi.
Da tener in considerazione che: col Behavior Blocker, i rootkit autoinstallanti non s'installano. Gli spyware o comunque un qualsiasi programma, che effettui un tentativo di comunicazione con l'esterno, non desiderato dall'utente, viene segato (e quindi, un Anti-Spyware, di per sè, è inutile, in alcune sue parti). Il BB, però, non può far tutto.
Tornando al discorso di prima, IMHO, ritengo il controllo effettuato sulle librerie, impossibile da gestire, per un BB, in termini di performance. E' un rischio che l'utente deve correre, nel fidarsi delle DLL di certi programmi. Se, però, avvengono dei controlli, preventivi, sul programma installato, in questione, via software AV o Engine Euristico, direi che si può già sentirsi più sicuri. Ma controllare ogni cosa, è assurdo.
Il sistema così descritto è addirittura fuorviante. Tu installi word e se viene in qualche modo modificato l'utente pensa addirittura di lanciare un programma lecito al posto del malware... Col fatto di fidarsi allora rientri anche tu nell'idea. Lanci un prog come amministratore solo se ti fidi! Tutto il discorso lo vedo un po' confuso..
Lo sò, ma questo ci costringe a riprogettare alcune parti inerenti la sicurezza. Anzi, qualcuno parlò di ACL sui registri. Potrebbe spiegare più dettagliatamente cos'intendeva dire?
Allora hai mancato in pieno lo scopo di ReactOS..compatibilità con windows. O forse l'ho mancato io..ditemi voi!

Per ACL sui registri intendevo che tutti gli oggetti in windows hanno le ACL. Le chiavi di registro non sono un'eccezione. Prova da regedit a fare click destro su una chiave (chiave, non valore) e seleziona la voce "Autorizzazioni..." Ti apre la pagina dei permessi per quella chiave..

PUOjACKz
Posts: 116
Joined: Tue Jan 03, 2006 3:52 pm

Post by PUOjACKz »

Infatti, esiste una funzione, sul Sygate, che controllava questa cosa, ma di per sè, era poco usata e disattiva predefinitamente. IMHO, è un controllo inapplicabile, sia in termini di risorse da impiegare, che di tedio legato all'utente. IMHO, è buona cosa che il Behavior Blocker tenti di identificare i code injection effettuati da programmi attivi, verso altri programmi e basta. Il resto, esula dalle sue funzioni.
Il Behavior Blocker non dev'essere inteso come una panacea per tutti i mali, bensì, uno strato di sicurezza, che crei un certo grado di ridondanza, contro vari problemi.
Da tener in considerazione che: col Behavior Blocker, i rootkit autoinstallanti non s'installano. Gli spyware o comunque un qualsiasi programma, che effettui un tentativo di comunicazione con l'esterno, non desiderato dall'utente, viene segato (e quindi, un Anti-Spyware, di per sè, è inutile, in alcune sue parti). Il BB, però, non può far tutto.
Tornando al discorso di prima, IMHO, ritengo il controllo effettuato sulle librerie, impossibile da gestire, per un BB, in termini di performance. E' un rischio che l'utente deve correre, nel fidarsi delle DLL di certi programmi. Se, però, avvengono dei controlli, preventivi, sul programma installato, in questione, via software AV o Engine Euristico, direi che si può già sentirsi più sicuri. Ma controllare ogni cosa, è assurdo.
Il sistema così descritto è addirittura fuorviante. Tu installi word e se viene in qualche modo modificato l'utente pensa addirittura di lanciare un programma lecito al posto del malware... Col fatto di fidarsi allora rientri anche tu nell'idea. Lanci un prog come amministratore solo se ti fidi! Tutto il discorso lo vedo un po' confuso..
No, non lo è invece. Semplicemente, un Behavior Blocker non controlla tutti i files, ma solo quelli eseguibili. Un file di testo, normalmente, se .txt, non fà danni. Poi, se qualcuno, tramite i bug dell'OS, combina pasticciate con le estensioni, quello non è un problema del Behavior Blocker.
Allora, l'attacco DoS Code Injection, si basa, sullo sfruttate la possibilità, di accesso arbitrario in memoria, per modificare le funzioni di un altro programma attivo. E' bene tener in considerazione, in questi casi, l'evento peggiore, ossia, in qualche modo, l'attaccante o il malware, ha accesso arbitrario alla memoria, in quanto, è riuscito, in qualche modo, a diventare administrator (es. Priviledge Escalation). Il behavior blocker non fà altro che controllare se vi è un attività di sovrascrittura della memoria, tra le varie funzioni che ha, da parte di un processo attivo, nei confronti di un altro processo, agendo di conseguenza. Niente di confuso in questo.
Inoltre, un malware, o chi per lui, può sostituire un eseguibile, con una versione trojanizzata. Nei sistemi operativi, oggi giorno, questo genere di problema viene identificato dal Behavior Blocker, proprio a pelo di patata, in quanto, il BB è un sistema poco usato (ahimè). Ovviamente, nessuno blocca il BlackHat nel creare un sostituto, che riporti una versione del file uguale a quella implementata nell'ambiente attaccato. Ci son solo alcuni punti da tener in considerazione:

1) L'attaccante non sà quale ipotetica versione può essere installata nel sistema
2) L'attaccante non sà se il Behavior Blocker presente, ha anche funzioni di Integrity Checker.

Riguardo la storia delle DLL, qua è da fare una distinzione:

1) Il Behavior Blocker, non può controllare ogni DLL eseguita ed ogni programma che và ad eseguire una DLL. Quello, semmai, lo fà un Antivirus
2) Il Behavior Blocker della distro parallela di ROS, in caso, non andrebbe comunque a controllare questo fattore, in quanto, oggi giorno, esistono moltissimi metodi per sostituire una libreria (es. cambiare le stringhe delle DLL registrate nel sistema, sovrascrivere o sostituire fisicamente le librerie ecc..)

Fin qua, tutto chiaro. Ti esorterei a leggere TUTTO l'intervento e non solo qualche pezzo, oppure, ovviamente, è difficile cogliere il sugo del discorso.
Allora hai mancato in pieno lo scopo di ReactOS..compatibilità con windows. O forse l'ho mancato io..ditemi voi!
Se non erro, mi pare fosse Speekix a dire che c'erano delle ipotetiche ACL sui registri. Io non lo sò, non le ho mai viste. Riguardo la compatibilità, nella distro parallela di ROS, occorrerà assolutamente guardare anche l'aspetto della sicurezza.
Una cosa, però, io noto: qua, l'attimo prima si dice che i programmi per win98, che richiedono i privilegi di admin, è sbagliato eseguirli, di per sè, affondando parte della compatibilità dell'OS, il momento dopo, invece, si grida alla compatibilità. La domanda è la seguente: volete un sistema con un utente blindato, che vi seghi la compatibilità e che, si supponga, sia protetto, oppure volete un OS con qualche sistema di sicurezza e configurazione kernel in più, ma che permetta, a chiunque, di eseguire tutto con una compatibilità massima? Occorre soltanto capirsi, in modo tale che chi desidera una media compatibilità, solo con software NT, può usare ROS e basta.

folle_invasato
Posts: 134
Joined: Thu Jan 13, 2005 9:11 pm
Location: Pordenone, Italy

Post by folle_invasato »

Bho..continuo a pensare che sia una cosa confusa.

Ci tengo a precisare comunque che *nessuno* si sognerebbe mai di verificare che un file sia invariato tramite il suo numero di versione. X quello ci sono gli hash.

Mi stupisce anche che una persona che mi dice che in windows l'uso delle ACL non va bene NON SAPPIA dove stanno ste benedette ACL.

Con compatibilità ho sbagliato io a dire "windows"...intendevo NT.

PUOjACKz
Posts: 116
Joined: Tue Jan 03, 2006 3:52 pm

Post by PUOjACKz »

folle_invasato wrote:Bho..continuo a pensare che sia una cosa confusa.

Ci tengo a precisare comunque che *nessuno* si sognerebbe mai di verificare che un file sia invariato tramite il suo numero di versione. X quello ci sono gli hash.
Sì, è stata una sparata mia, senza pensarci sopra. Effettivamente, semmai, vengono usati hash.
Mi stupisce anche che una persona che mi dice che in windows l'uso delle ACL non va bene NON SAPPIA dove stanno ste benedette ACL.

Con compatibilità ho sbagliato io a dire "windows"...intendevo NT.
Che io sappia, le ACL non son riferite anche ai registri, ma solo ai files, cartelle e condivisioni.

folle_invasato
Posts: 134
Joined: Thu Jan 13, 2005 9:11 pm
Location: Pordenone, Italy

Post by folle_invasato »

Da Inside Windows 2000

"Object protection and access accounting is the essence of discretionary access control and auditing. The objects that can be protected on Windows 2000 include files, devices, mailslots, pipes (named and anonymous), jobs, processes, threads, events, mutexes, semaphores, shared memory sections, I/O completion ports, LPC ports, waitable timers, access tokens, window stations, desktops, network shares, services, registry keys, and printers."

Ogni oggetto windows è protetto da ACL..

PUOjACKz
Posts: 116
Joined: Tue Jan 03, 2006 3:52 pm

Post by PUOjACKz »

Ok, l'area ove configurar le ACL delle chiavi di registro dov'è?

folle_invasato
Posts: 134
Joined: Thu Jan 13, 2005 9:11 pm
Location: Pordenone, Italy

Post by folle_invasato »

L'avevo scritto sopra:

Prova da regedit a fare click destro su una chiave (chiave, non valore) e seleziona la voce "Autorizzazioni..." Ti apre la pagina dei permessi per quella chiave..

PUOjACKz
Posts: 116
Joined: Tue Jan 03, 2006 3:52 pm

Post by PUOjACKz »

Caspita... non c'avevo mai nemmeno fatto neppure caso.
Senti na roba, sai, per caso, ove siano dislocati gli utenti "CREATOR OWNER, RESTRIZIONI, SYSTEM" ecc? In modo da vedere chi, come perchè son stati creati quegli utenti ed altre info varie.

folle_invasato
Posts: 134
Joined: Thu Jan 13, 2005 9:11 pm
Location: Pordenone, Italy

Post by folle_invasato »

Quegli utenti dovrebbero essere dei SID particolari...sono hard-coded nel sistema credo..

Siamo andati OT penso..

PUOjACKz
Posts: 116
Joined: Tue Jan 03, 2006 3:52 pm

Post by PUOjACKz »

Sì, cmq, c'è ancora un post inerente alla terza rivisitazione del Behavior Blocker. Consiglio a tutti di darci un occhiata, anche perchè, alla fine del post, ci son delle domande che andrebbero trattate, anche aprendo thread appositi. Per il resto, la versione di Behavior Blocker "Process Guard", ha più funzioni di quella da me postata ed il tutto riesce a farlo in 250 kbyte di RAM alloccata, in modo snello e assolutamente trasparente al computer, oltre ad avere un sistema di pilotaggio semplificato per l'utente.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest