Sviluppo degli exploit: dispositivi diversi con lo stesso sistema operativo / architettura avranno la stessa memoria di processo esatta (ad esempio indirizzi) per un dato binario?

3

A volte, quando sviluppo un exploit che funziona perfettamente su una determinata macchina, fallirà su uno diverso, nonostante abbia lo stesso OS / Architettura e configurazioni (come il linguaggio, che nella mia esperienza può avere alcuni effetti sul memoria di processo, almeno su Windows).

Sono consapevole del fatto che esistono tecniche per ottenere maggiore affidabilità in alcuni casi. Tuttavia, mi chiedo se un exploit sviluppato e testato su un dato dispositivo (diciamo un Google Pixel), con o senza l'utilizzo di queste tecniche, debba funzionare su un altro (come un Samsung Galaxy S8).

Se no, perché? Non dovrebbe lo stesso binario avere la stessa memoria di processo? Posso pensare a diversi casi in cui ciò non dovrebbe essere vero, ad esempio se il programma carica dati specifici del dispositivo. Ma quando non è il caso, lo stesso binario, alimentato con lo stesso input, si comporterebbe diversamente quando funzionava su dispositivi diversi?

Questa domanda presuppone che ASLR sia disabilitato.

EDIT: sto chiedendo di sfruttare le vulnerabilità della corruzione della memoria, come ad esempio use-after-free e OOB read.

    
posta Not Now 31.03.2018 - 01:19
fonte

1 risposta

2

Il layout dell'heap è una cosa volubile. Esempi di vita reale dal mondo di Windows:

  • Le versioni non inglesi del programma caricano DLL di internazionalizzazione aggiuntive a indirizzo fisso nel mezzo dell'heap.

  • diversi schemi di allocazione tra il programma iniziale su riga di comando (come fa il tuo fuzzer / debugger) e l'utente apre il documento con "file" - "aperto".

  • Caricamenti del prodotto di sicurezza% $ § # -ton delle DLL in tutti i processi che iniziano tutti i thread & allocare cose nell'heap. Immagino che impediscano gli exploit non lasciando loro alcuna memoria gratuita.

  • Windows XP ha portato tutta la nuova strategia di allocazione dell'heap con un service pack. Era SP2?

  • I browser hanno un'euristica complessa per quando precompilano & jit, quanto jit, quando liberano il codice jitted, ecc. Queste euristiche guardano anche alla memoria del sistema disponibile totale. Lo stesso vale per la garbage collection.

Non assumere mai troppo il layout del tuo heap.

    
risposta data 31.03.2018 - 12:47
fonte

Leggi altre domande sui tag