OpenBSD sta implementando KARL. In che modo migliora la sicurezza?

Question

OpenBSD sta implementando KARL. In che modo migliora la sicurezza?

#1 da (4 voti)

5

Secondo questo article , OpenBSD sta implementando una funzionalità che creerà un kernel unico ogni volta che un utente si riavvia o aggiorna il suo computer.

Si chiama KARL, "Link randomizzato sull'indirizzo del kernel". Ciò funziona ricollegando i file interni del kernel in un ordine casuale in modo da generare ogni volta un blob binario del kernel univoco.

La spiegazione tecnica dice;

A unique kernel is linked such that the startup assembly code is kept in the same place, followed by randomly-sized gapping, followed by all the other .o files randomly re-organized. As a result the distances between functions and variables are entirely new. An info leak of a pointer will not disclose other pointers or objects. This may also help reduce gadgets on variable-sized architectures, because polymorphism in the instruction stream is damaged by nested offsets changing.

In che modo migliora la sicurezza?
Quale tipo di attacchi sarebbe mitigato da questa nuova funzionalità?
In che modo è diversa dalla randomizzazione del layout dello spazio indirizzo del kernel?

linux kernel openbsd

posta Digital fire 07.07.2017 - 05:10

fonte

1 risposta

Leggi altre domande sui tag linux kernel openbsd

Qual è lo scopo dei nomi di input del modulo dipendenti dal tempo? In che modo i truffatori possono iniettare i pop-up sui computer di destinazione?

score 4 · Accepted Answer

Da quanto ho capito, questo è un passo avanti rispetto a KASLR. Per inferenze di posizione di memoria con una granularità più fine di quella che KASLR protegge.

Con KASLR, rendi più difficile per i gadget ROP sovrascrivere (ad esempio, heap spray) aree di memoria che alla fine daranno il controllo del codice iniettato / conosciuto. Tuttavia, trattandosi di una corsa agli armamenti, le contromosse come lo spray JIT si sono evolute.

An info leak of a pointer will not disclose other pointers or objects.

Come con ASLR che randomizza e quindi rende più difficile "trovare" i punti di ingresso della funzione userland per manomettere, e KASLR fa la stessa cosa - entrambi sono ancora vulnerabili - se un utente malintenzionato può

studiano il modo in cui i componenti del kernel sono collegati e caricati in memoria l'uno rispetto all'altro
quindi "trova un punto di riferimento" (in questo caso, da una perdita di informazioni di un puntatore ") e poi
applica le conoscenze precedenti per dedurre la posizione di altri oggetti / funzioni sensibili che potrebbero essere presi di mira dai gadget.

How does this improve security?

Apparentemente, KARL rende questa inferenza molto più difficile perché dovrai studiare (1) di nuovo dopo ogni riavvio. Ciò aumenta significativamente il costo dello sfruttamento (eccetto in una situazione in cui l'autore di un attacco non ha nemmeno bisogno di riavviarsi anche se si mischiano con il kernel in una tecnica ampiamente fallita) - e rende quindi il sistema operativo più sicuro.

What type of attacks would be mitigated by this new feature?

I gadget che dipendono dall'inferimento di posizioni di oggetti del kernel basate su una "conoscenza di" un punto di riferimento separatamente.

How is this different from Kernel Address Space Layout Randomization?

Questa è una difesa aggiuntiva su KASLR. Per difendersi dall'uso di gadget che funzionano con una granularità più fine rispetto a ciò che KASLR difende.