Secondo questo bug report , la prima vulnerabilità può far trapelare informazioni sensibili.
Ma dal momento che non menziona quali informazioni perdere, suppongo che sarebbe lo stack? E come potrebbe questo aiuto nello sviluppo degli exploit?
Secondo questo bug report , la prima vulnerabilità può far trapelare informazioni sensibili.
Ma dal momento che non menziona quali informazioni perdere, suppongo che sarebbe lo stack? E come potrebbe questo aiuto nello sviluppo degli exploit?
Di solito, quel tipo di perdita (leggendo una stringa che non era terminata con NULL) risulta nella lettura di ciò che accade risiedere nella RAM subito dopo la stringa. Quindi questo dipende da dove si trova la stringa. Se la stringa è allocata allo stack, questo rivela una parte dello stack (poiché gli stack "scendono", esploreranno le variabili locali dei chiamanti della funzione corrente). Se la stringa è allocata all'heap, la lettura verrà sovrascritta in blocchi adiacenti, che possono essere qualsiasi cosa, a seconda di tutte le allocazioni precedenti dall'ultimo avvio, quindi è piuttosto imprevedibile.
Ci sono alcuni obiettivi di alto valore nel kernel (ad esempio chiavi di crittografia per operazioni crittografiche nel kernel). Questi obiettivi possono essere in variabili locali, oggetti allocati a blocchi ... in realtà dipende dal contesto. La semplice lettura dello stack locale può essere di grande aiuto nella messa a punto di un exploit di buffer overflow (un overflow del buffer non regolato causa un arresto anomalo, un overflow del buffer ottimizzato può portare all'esecuzione di codice arbitrario).
La maggior parte delle sbirciatine nella memoria del kernel non rivelerà nulla di valore, perché il 99,9% (almeno) della memoria usata da qualche codice (sia esso il kernel o qualche applicazione) non è veramente confidenziale e potrebbe essere rivelato senza alcun effetto negativo. Tuttavia, è molto difficile individuare con precisione il rimanente 0,1%: garantire che un dato dato sia non sensibile è praticamente impossibile nel caso generale. Quindi è più sicuro considerare tali vulnerabilità come "potenzialmente gravi" e correggerle.
Nel kernel land, la capacità di leggere gli indirizzi di memoria può minare ASLR. La randomizzazione riguarda i segreti e se puoi leggere questi segreti, allora ASLR non è molto utile.
Un semplice esempio nel mondo delle app Web sta utilizzando la divulgazione di informazioni sugli errori per ottenere un percorso completo. Con il percorso completo puoi usare directory traversal per accedere alla web root, oppure usare% mys_co into outfile o load_file() per accedere ai file nella web root.
Leggi altre domande sui tag exploit