Sicurezza software V.S Sicurezza hardware

Moduli di sicurezza hardware

L'esecuzione di codice in un chip protetto fisicamente come un HSM o una smartcard non riguarda la protezione dai bug del software. Se c'è un bug del software in un HSM, può essere sfruttato proprio come qualsiasi server web, laptop, smartphone, qualunque cosa. La differenza tra un HSM e un PC è che con l'accesso fisico a un PC, puoi semplicemente avviare da una chiavetta USB o sostituire il disco. Con l'accesso fisico all'esterno di un HSM, devi ancora entrare in gioco e gli HSM sono progettati per autodistruggersi quando fai un serio tentativo di aprirli.

Esecuzione di un browser su un Raspberry Pi

Un PC è un "sistema basato su chip" tanto quanto un Raspberry Pi. Non c'è alcuna differenza fondamentale tra loro: un Raspberry Pi non è in qualche modo "più sicuro" di un PC.

Più persone usano i PC, quindi i PC sono un obiettivo più prezioso da sfruttare, quindi più persone cercano di sfruttare i PC. I PC hanno anche un pesante fardello di compatibilità storica e una grande varietà di software, che li mette un po 'più a rischio. Ma se la gente usava abitualmente i browser su Pis invece che su Pentium, ci sarebbero stati altri exploit per Pis.

Lo spostamento del browser su una macchina diversa lo isola. Ma cosa ottieni? Un sacco di exploit sono forniti attraverso il browser. Spesso il browser stesso è l'obiettivo. Ha accesso alla rete, quindi è un obiettivo prezioso per diffondere l'infezione ad altre macchine. È come l'utente interagisce con un sacco di cose, quindi è un obiettivo primario per ladri e truffatori. Indipendentemente da dove hai messo il browser, se è infetto, hai perso.

Codice casuale

Randomizzare il codice in qualche modo è una tecnica di difesa, ma rende gli exploit solo più difficili, non li rende impossibili.

Ad esempio, alcuni sistemi operativi moderni praticano la randomizzazione del layout dello spazio degli indirizzi : ogni volta che viene avviato un programma, viene caricato in un diverso indirizzo casuale. Ciò significa che ci sono cose che non puoi fare in un exploit, come ad esempio fare riferimento direttamente all'indirizzo di un pezzo di codice nel programma originale. Non rende impossibili gli exploit: ci deve essere un modo in cui il programma può trovare i propri pezzi (per esempio, un breve salto relativo continuerà a funzionare bene), e se qualche pezzo è difficile da trovare, l'exploit può cercarlo (È un problema comune anche senza ASLR perché spesso il codice di exploit stesso viene caricato in un indirizzo imprevedibile).

Randomizzare il codice nel compilatore non ti comprerebbe molto ed è costoso. Tutte queste forme di randomizzazione rendono più difficile il debugging. Se si randomizza prima di distribuire il programma, è necessario gestire la distribuzione e la manutenzione (aggiornamenti) di tutte queste diverse versioni. E per quanto riguarda la sicurezza, il vantaggio è minimo perché alla fine il programma deve ancora fare la stessa cosa.

Come l'hardware aiuta con la sicurezza

Per i sistemi run-of-the-mill (non HSM e simili), il ruolo dell'hardware è quello di rafforzare l'isolamento tra i componenti. È un componente hardware, la MMU , che rende impossibile per un programma accedere direttamente alla memoria di un altro programma. Il design della CPU rende inoltre impossibile ai programmi ordinari accedere direttamente alle periferiche hardware, per cui devono passare attraverso le interfacce dei sistemi operativi. L'hardware deve essere utilizzato correttamente: è compito del sistema operativo configurare correttamente le tabelle MMU e così via.

Non puoi mettere troppa intelligenza nell'hardware. Più fai, più c'è il rischio che ci sia un bug nel tuo progetto. I bug dell'hardware sono piuttosto difficili da risolvere. Quindi l'hardware fornisce alcune funzionalità di base e la complessità è gestita nel software il più possibile.

@vulner, penso che tu stia indirettamente cercando di chiedere se un'architettura di Harvard è intrinsecamente più sicura di un'architettura di Von Neuman. (Un'architettura di Harvard ha memoria separata per istruzioni e dati, mentre una macchina Von Neuman utilizza la memoria condivisa per entrambi gli scopi.)

Un attacco in cui una macchina di Harvard potrebbe essere più sicura si trova in un sovraccarico del buffer. Anche se l'applicazione commette un errore e sovrascrive la memoria dell'applicazione a causa di un sovraccarico del buffer, i puntatori dell'app potrebbero non disporre dell'accesso fisico allo stack di memoria e pertanto non sarebbe possibile eseguire un classico attacco stack-smashing.

Ma non è l'unico problema di sicurezza che troverai sul web. Il problema con la sicurezza di un browser non è solo nell'architettura della macchina. I problemi sono che l'applicazione di navigazione elabora informazioni non affidabili che sono interpretate sia come dati sia come istruzioni e che il browser è in grado di mantenere stato .

Considera uno script (fonte non attendibile ) che potrei postare qui in stackexchange che colloca quello che sembra un annuncio falso per la tua banca nella colonna di destra. Il tuo browser non ha idea se questi siano dati legittimi, ma se inserisci il nome utente e la password della banca, lo scoprirai rapidamente.

Oppure prendi in considerazione le istruzioni javascript ( interpretate ) che rubano le informazioni sui cookie. Se gestisco un access point WiFi dannoso, potrei inserire un javascript nella parte inferiore della home page www.google.com che mi invia tutti i dati che pubblichi e tutti i cookie che ricevi. Potrei modificare il tempo di cache per dire "mantenere questa pagina e lo script nella cache per un anno". (memorizzato stato ) E lo script potrebbe aggiungersi alla fine di ogni nuova pagina visitata tramite la pagina di Google memorizzata nella cache. Solo svuotare la cache del browser si sbarazzerebbe di esso.

Il tuo browser basato su chip potrebbe fermare un tipo specifico di attacco, ma forniresti un falso senso di sicurezza a causa di tutti gli altri attacchi là fuori.