Silicon Secured Memory può evitare sovraccarichi del buffer?

6

Oracle ha recentemente annunciato il nuovo chip SPARC M7. Ha una caratteristica interessante chiamata Silicon Secured Memory che pretende di prevenire bug di corruzione della memoria come Heartbleed e Venom.

L'idea è di aggiungere un "colore" a ciascun puntatore e un blocco di memoria di 64 byte. Su ogni accesso alla memoria, il colore viene controllato e, se non corrispondono, il programma viene interrotto. C'è un'immagine e alcuni informazioni più dettagliate online.

L'idea sembra promettente. Tuttavia, i tentativi precedenti di risolvere i sovraccarichi del buffer (ad esempio DEP) si sono rivelati meno efficaci di quanto sperato. SSM può prevenire in modo affidabile sovraccarichi del buffer? Quali sono potenziali attacchi contro la funzione?

    
posta paj28 28.10.2015 - 05:48
fonte

2 risposte

6

Can SSM reliably prevent buffer overruns?

Non pretende di offrire una prevenzione al 100% ma offre sicuramente una protezione più granulare rispetto alla precedente soluzione basata su hardware (che di solito presentava granularità della pagina) e prestazioni molto migliori rispetto alle protezioni basate su software con una granularità simile. Ci sono alcune limitazioni come

  • Il tuo codice deve effettivamente farne uso. Questo può essere semplice come utilizzare il malloc fornito, ma è necessario modificare le allocazioni personalizzate della memoria come quelle eseguite in OpenSSL. E non so se il compilatore aggiungerà anche tale protezione allo stack o se questo è possibile solo per i dati allocati nell'heap.
  • La memoria deve essere allineata a 64 byte. In questo modo non rileverà quando si trabocca un'allocazione di soli 32 byte.
  • Sono disponibili solo 16 colori (4 bit) per ciascuna regione a 64 byte. Quindi la probabilità che un puntatore casuale abbia lo stesso colore dell'area di memoria protetta è ancora del 6%.

Quindi non è perfetto ma la possibilità di individuare i problemi in anticipo e quindi prevenire gli attacchi è molto più alta rispetto alle soluzioni esistenti, almeno con soluzioni nella stessa classe di prestazioni.

earlier attempts to solve buffer overruns (e.g. DEP)

A mio parere, DEP non protegge affatto dal sovraccarico del buffer, ma fa in modo che non si possa semplicemente eseguire codice che è stato scritto nello stack o nell'heap. Pertanto, tratta solo alcuni dei possibili modi per utilizzare un buffer overflow con successo, mentre SSM può aiutare a prevenire l'overflow stesso.

    
risposta data 28.10.2015 - 07:18
fonte
1

Come supplemento ai punti che l'altra risposta qui ha già fatto, sottolineerò due ulteriori preoccupazioni, segnalate in questo elemento di Il registro :

Primo: Anche se il codice di un utente malintenzionato indovina in modo errato il "colore" che deve utilizzare nel suo puntatore dannoso (e che 1 su 16 possibilità di ottenerlo correttamente non è abbastanza banale, almeno in questo contesto) e l'eccezione dal il processore causa l'arresto dell'applicazione in questione che probabilmente non sarà abbastanza buono in molti casi. L'obiettivo avrà bisogno di un software di sicurezza o di monitoraggio dei log in atto per (a) vedere che il crash si è verificato e amp; riconoscere la causa speciale di esso e (b) almeno avvisare gli amministratori dell'attacco. (Naturalmente, preferibilmente un IDPS basato su host sofisticato sarebbe installato sui server della destinazione, in grado sia di riconoscere il codice di exploit che ha attivato l'eccezione, sia di prendere contromisure automatiche contro la sua esecuzione in ulteriori attacchi. / p>

Se, d'altra parte, l'arresto anomalo dell'applicazione passa inosservato e le istanze bloccate si riattualizzano automaticamente abbastanza volte, il codice dell'attaccante colpirà la probabilità 1 su 16 di corrispondere al colore del blocco di memoria a 64 bit vuole caricare. Bypassare questa linea di difesa. In altre parole, se non stai prestando attenzione a ciò che stanno facendo le tue applicazioni e i tuoi server, potresti comunque bruciarti. (Sì, duh.)

In secondo luogo: Se un utente malintenzionato può capire in qualche modo quale sia il colore del blocco di memoria specifico che desidera caricare o sarà, l'autore dell'attacco può ( può ) essere in grado di imposta semplicemente il puntatore su quel colore . Quanto è vulnerabile agli attacchi lungo queste linee è probabile che sia la nuova protezione? Bene, per iniziare a rispondere, è probabile che richieda più specifiche tecniche di quelle che sembrano essere là fuori finora su come funzionerà tutto questo. (Più un rispondente che conosce modo, modo, modo più su SPARC di me.)

Anche se le preoccupazioni / limitazioni di cui sopra sono là fuori, però, è una misura di sicurezza basata sull'hardware davvero interessante che sembra più ambiziosa di quella che i produttori di silicio hanno altre architetture (tosse ... Intel ... ARM ... tosse ) stanno cercando di fare per migliorare la protezione della memoria in questo momento. (Anche se il concetto generale di avere le chiavi di protezione / check-info per i blocchi di memoria è appena nuovo.) Sarà davvero interessante vedere quanta differenza reale e positiva nella protezione da exploit (se ce ne sarà) per i negozi Oracle .

    
risposta data 29.10.2015 - 22:32
fonte

Leggi altre domande sui tag