ASLR in Linux non randomizza le librerie separatamente

Question

ASLR in Linux non randomizza le librerie separatamente

#1 da (3 voti)

5

Stavo provando come funziona ASLR in Centos 7.2.1115 x86_64 in particolare.

Ecco i miei /proc/$pid/maps dump da due esecuzioni di Firefox (su Pastebin): # 1 # 2

Fondamentalmente, ASLR funziona. Rende casuali gli offset .data e .text

Tuttavia, racchiude tutte le librerie e gli eseguibili nello stesso ordine e senza spazi vuoti. (Per lo più. Ci sono varianti di coppia, ma sembrano puramente accidentali.)

Quindi, non appena il singolo indirizzo viene compromesso, tutta questa parte dell'ASLR esce dalla finestra.

La mia domanda è , è il caso comune fin d'ora? Quali sistemi risolvono questo problema e in che modo?

Voglio dire, lo spazio degli indirizzi a 64 bit è enorme , puoi semplicemente gettare casualmente ogni libreria e poi verificare se si sovrappone a qualcosa e posizionarlo correttamente dopo un paio di tentativi al massimo. Tuttavia, la migliore soluzione già implementata che ho trovato su Google è la randomizzazione di ordine di caricamento della libreria su Android.

linux aslr

posta EvgEnZh 22.11.2016 - 11:58

fonte

1 risposta

Leggi altre domande sui tag linux aslr

Come evitare l'attacco cross-frame scripting sull'applicazione core php we Raccoglie informazioni online in modo anonimo

score 3 · Answer 1

However, it packs all libraries and executable in the same order and without gaps. So, as soon as single address gets compromised, this whole part of ASLR goes out of the window.

Non proprio. ASLR funziona ancora per ridurre le possibilità di uno sfruttamento cieco, aiutando a impedire a un attaccante di saltare in modo affidabile a un punto di esecuzione. Se non si conosce un particolare punto da sovrascrivere, la tua prossima tattica sarà comunque quella relativa alla slitta NOP vicina. Accoppiato con l'indirizzo di partenza che viene randomizzato, è altrettanto probabile che tu scelga qualcosa nel non-terreno come codice utile indipendentemente dalla frammentazione.

I mean, 64-bit address space is huge, you could just randomly throw each library at it and then check if it overlaps with anything, and successfully place it after a couple retries at most.

È vero, ma ciò comporta un problema di prestazioni. Ogni voce di randomizzazione richiederà una voce nel TLB , con conseguente maggiore utilizzo delle risorse e più memoria sprecata / inutilizzata a causa di blocco allineamento.

My question is, is it the common case as of now? What systems address this issue and how?

Per i motivi di cui sopra, è davvero il caso comune. Comprendere i limiti dell'attacco aiuta a capire perché l'uso dei "bit di memoria" più costosi in ogni luogo ha un beneficio limitato.

Un punto bonus: lo sfruttamento più comune è scrivere troppi dati in un blocco dati, quindi eseguirlo. Anche il NX bit è una contromisura sostanziale.