Glibc usa il canary check per prevenire l'overflow del buffer heap?

0

Poiché canary è usato da gcc per prevenire l'overflow dello stack (ad esempio -fstack-protector), mi chiedo se glibc usi un approccio basato su canarini per difendere l'overflow del buffer heap? Ad esempio, questo documento propone il rilevamento basato su canary contro l'overflow del buffer heap. E i sistemi Windows utilizzano già i cookie di heap per mitigare gli overflow del buffer dell'heap.

Qualsiasi riferimento relativo a glibc sarà molto apprezzato. Grazie!

    
posta ZillGate 29.07.2014 - 05:30
fonte

1 risposta

1

Glibc ha alcune capacità intrinseche nel rilevare i superamenti e possono essere attivati con la variabile di ambiente MALLOC_CHECK_ . Vedi mcheck e mallopt per i dettagli.

Provando su un sistema Ubuntu 14.04 a 64 bit, sembra che quando si allocano molti blocchi di memoria, malloc() arrotonda la dimensione richiesta al successivo multiplo di 8 e utilizza 8 byte extra. Ad esempio, se hai assegnato 1000000 blocchi di 50 byte, il processo richiede effettivamente 64000000 byte dal kernel, non 50000000. Questo lascia spazio per un "separatore canarino" di 8 byte tra due blocchi allocati.

Queste funzionalità sembrano intese a rilevare bug di implementazione, non a sfruttare maliziosamente. Non è chiaro se saranno davvero bravi a rilevare effettivamente i sovraccarichi del buffer e farlo abbastanza presto; infatti, per definizione, i controlli di consistenza dell'heap di quel tipo possono essere applicati solo quando vengono richiamate le routine di allocazione dell'heap. Ciò significa che se hai un buffer overflow, potresti ricevere un avviso solo quando viene rilasciato il blocco rilevante, o il successivo in RAM: questo accade dopo l'overflow, probabilmente molto dopo, quindi troppo tardi. Questo contrasta con i canarini basati sullo stack, che vengono controllati prima che ritornano (vale a dire dopo l'overflow, ma prima di usare lo slot dell'indirizzo di ritorno che potrebbe essere stato danneggiato).

Ciò a cui tali controlli sono più o meno efficaci è la rilevazione di problemi double-free. Non possono intrappolare casi use-after-free e, come spiegato sopra, quando rilevano un overflow è probabilmente troppo tardi.

    
risposta data 29.07.2014 - 16:04
fonte

Leggi altre domande sui tag