Quote:
Originariamente inviato da imayoda
è solo una grande parabola per dire ai produttori che servono più chip dal funzionamento oscuro che blindino (security through obscurity) il hw di una macchina e magari lo facciano funzionare solo su un determinato os
 |
Complimenti: hai capito perfettamente l'argomento dell'articolo.
Quote:
Originariamente inviato da AaLl86
Ciao!
Guardate che la recensione su CET non e' del tutto esatta:
1. Non gira nessun codice ne nello stack e ne nello shadow stack. Lo stack contiene i dati di una funzione (come le variabili locali) e gli indirizzi di ritorno (che identificano da dove una certa funzione e' stata chiamata).
2. Questo: "protezione per il codice dei software presente all'interno della cache delle CPU " e' assolutamente falso. La "Hardware-enforced Stack Protection" e' stata sviluppata da noi per combattere l'ultima tecnica disponibile dagli attacker per bucare il sistema operativo: ROP (Return Oriented Programming).
3. ROP in estrema sintesi prevede che un attaccante riesca in qualche modo a sostituire un indirizzo di ritorno memorizzato nello stack e a cosi' deviare il flusso di esecuzione su pezzi di codice (cosidetti gadget) scelti ad hoc per eseguire un payload esterno.
4. Lo sviluppatore principale di questa tecnologia e' Jason (Lin), e non Hari. Hari e' il capo dei PM, e non ha nulla a che fare con lo sviluppo.
Hope that this will help.
Andrea
|
Rimane però un dubbio, Andrea: cambiare l'indirizzo di ritorno nello stack è anche un'operazione lecita in alcuni casi, peraltro anche piuttosto comuni ormai.
Basti pensare all'unrolling dello stack nel caso di eccezioni in linguaggi come C++, Java, C++, Delphi, etc.. In questo caso sostituire l'indirizzo di ritorno puntando al giusto entry-point consente di riprendere l'esecuzione da un punto completamente diverso da quello in cui la CPU era arrivata (nella "catch").
Inoltre, da programmatore, mi vengono in mente alcuni scenari in cui vorrei poter spostare manualmente l'indirizzo di ritorno e/o aggiustare lo stack. Più che altro lavorando in assembly o dentro codice generato da un compilatore JIT. Quindi non esattamente scenari comuni, ma comunque leciti (sono io a controllare la mia stessa applicazione).
In questi casi mi sembra di capire che la tecnologia di protezione che verrà impiegata non funzionerà, e bloccherà l'esecuzione pensando che si tratti di codice compresso da un malware.
Nell'articolo sul vostro sito sono elencate anche le nuove istruzioni introdotte da Intel allo scopo per manipolare il nuovo stack "Shadow", ma probabilmente non basteranno a coprire i casi che ho elencato. Per lo meno non in maniera efficiente (richiamare l'istruzione di manipolazione dello stack shadow n volte se vuoi tornare su di n livelli può essere oneroso).
Che ne pensi?