Solo i file locali (come ntfs o btrfs) sono costituiti da molte strutture di dati che richiedono un codice molto complesso per analizzarle.
Quindi, tali filesystem se implementati nello spazio utente possono soffrire di vulnerabilità di buffer overflow come molti parser.

In questo caso, l'attaccante lascia una scheda SD ad alta capacità con i dati predisposti sul parcheggio che prenderà il controllo del portatile del membro dello staff non appena tenta di montarlo.

Il punto è che penso che non ci sia niente da temere dall'usare più 512 Gb SD card a terra a causa di aslr:

• L'unico modo che conosco per bypassare aslr su 64 bit Linux è sfruttare gli accessi di rete ripetuti normalmente eseguiti dall'eseguibile (che consente all'autore dell'attacco di selezionare l'indirizzo di ritorno corretto da inviare all'interno del proprio exploit) .
• Le principali distribuzioni Linux di oggi come Red Hat e Chrome os o android ora compilano e collegano tutti i loro file eseguibili con -fPIE , quindi i programmi di spazio utente non usano più indirizzi statici.
I filesystem
• implementati con il fusibile che gestiscono solo i file di dispositivo non contengono alcun codice che acceda alle reti. Inoltre, dopo aver cercato precedenti vulnerabilità nei filesystem dello spazio utente, non ho trovato alcun exploit che escludesse aslr . Gli unici exploit di filesystem funzionanti che ho trovato funzionano dal codice del kernel o dipendono dall'eseguibile principale che non è indipendente dall'indirizzo. (anche se potrei cercare male e potrebbe esistere un esempio di contre)

Domanda:

Quindi fintanto che il filesystem non è nfs o serial scsi collegato e non viene eseguito nello spazio del kernel, né il sistema contiene gli eseguibili dipendenti dalla posizione, né usa lo stack eseguibile, aslr non solo attenua, ma impedisce completamente gli attacchi di buffer overflow , vero?
Oppure può essere bypassato eseguendo un singolo overflow del buffer che prende il controllo di tutte le variabili allocate nell'heap anche se il programma non utilizza alcuna rete? (Ho notato anche con il file system che l'intera struttura dell'heap può essere resa prevedibile)

dettagli:

Nel caso dei filesystem, la cosa tipica che succede è questa:

struct boot_sector ef=malloc(sizeof(struct boot_sector));
ef->dev=open("/dev/sdb1");
ef->sb=malloc(sizeof(struct super_block));
pread(ef->dev, ef->sb, sizeof(struct super_block), 0);
ef->first_extend =malloc (user_controlled_value * CLUSTER_SIZE); // get allocated at the begging of the heap.
pread(ef->dev, ef->first_extend, second_controlled_value << CLUSTER_SIZE, 1024); // overwrite every struct * that follow, including ef. Notice since we control file system data we know the value the varying struct * should have.

Anche se in questo tipo di casi, nessuna struttura contiene informazioni sul puntatore, quindi richiede di corrompere i dati dlmalloc di glibc.