dimis blog

Wer letztes Jahr aufmerksam den 28C3 verfolgt hat ist dabei mit Sicherheit über den Vortrag von Tilo Müller gestolpert, der dort TRESOR vorgestellt hat. Keine Ahnung ob das dort seine erste Präsentation zu dem Thema war, jedenfalls aber habe ich dort das erste Mal davon gehört.

Tresor ist ein ein Linux Kernel Patch, der vor allem Cold-Boot-Angriffe verhindern soll. Hintergrund ist folgender: Habt ihr ein vollverschlüsseltes System liegt der Schlüssel irgendwo im RAM. Das bedeutet für Cold-Boot-Angriffe, dass die Schlüssel auch wieder aus dem RAM ausgelesen werden können. Oft sogar nachdem der Rechner ausgeschalten wurde.

Ähnlich sieht das mit Angrifffen per DMA (Direct Memory Access) aus. Verschiedene Busse (z.B. FireWire) bieten direken Zugriff auf den physikalischen RAM, vorbei an der CPU. Toolkits wie Inception nuzten genau das aus und lassen einen Angreifer die Schlüssel direkt aus dem RAM extrahieren. Das System muss nur eingeschaltet sein. EIn Login ist auch nicht nötig.

Tresor verschiebt nun die Verschlüsselung und die Rundenschlüsselgenerierung für AES in die CPU. Einen guten Teil Arbeit machen die AES-NI-Befehle der neueren Intel Core-i Generation, weil sie direkt CPU-Befehle mitbringen, die pro CPU-Zyklus eine Runde AES verschlüsseln können. Die Verschlüsselung mit den AES-NI-Befehlen der Intel CPUs ist natürlich auch ohne Tresor möglich. Tresor legt jetzt aber den Schlüssel in Debug-Register ab und löscht diesen direkt danach aus dem RAM – der Schlüssel kann damit nicht mehr aus dem RAM gelesen werden werden.

Damit Angreifer keinen eigenen Code auf Ring 0, also mit Privilegen des Kernels, ausführen können schaltet Tresor /dev/kmem ab, modiziert ptrace und verbietet alle loadable kernel modules, die alle auf Ring 0 Code ausführen würden. Könnte ein Angreifer eigenen Code in den Kernel laden wäre es ein leichtes die Debug-Register und damit dem Schlüssel auszulesen.

Forscher der Northeastern University haben das Toolkit Inception erweitert und einen DMA-Angriff auf Tresor (und damit auch auf ähnlich arbeitende Systeme) vorgestellt, der es erlaubt den Schlüssel aus den CPU-Registern zu extrahieren. Der Angriff:

1. Der Angreifer hat physikalischen Zugriff auf das System und dieses hat einen DMA-fähigen Bus. Konkret implementiert wurde der Angriff im Paper mit FireWire.
2. Das Gerät holt sich den Inhalt des RAMs
3. Im RAM-Dump werden die Paging Structures und die Interrupt Descriptor Table identiziert.
4. Das angreifende Gerät bereitet einen Payload vor
5. Der Payload wird auf das angegriffene System übertragen und im Ring 0-Kontext ausgeführt
6. Das Gerät holt sich den Schlüssel aus dem RAM

Über DMA hat man Zugriff auf dem RAM. Nur wie führt man Code mit Ring 0-Privilegien auf der CPU aus? Eine offensichtliche Möglichkeit wäre einen Systemcall zu hooken, also die Stelle im RAM suchen, an der der die Funktion liegt, seinen Payload reinschreiben und dann warten bis der Systemcall durch ein Programm ausgerufen wird. In diesem Fall bräuchte man aber Wissen über das installierte Betriebssystem.

Um den Angriff unabhängig vom Betriebssystem zu machen hooken die Forscher eine Interrupt Service Routine, die dann ihren Payload  ausführt.  Dazu suchen die Forscher die Interrupt Descriptor Table (IDT) im Memorydump und schreiben das Ziel des Interrupts so um, dass der Payload ausgeführt wird. Der Payload extrahiert dann den Schlüssel aus den Registern und kopiert ihn an eine vorher festgelegte Stelle im RAM. Die kann dann vom angreifenden Gerät über DMA ausgelesen werden.

Das Identifizieren der Paging Structures und Interrupt Descriptor Tables basiert auf Heuristiken (warum das so ist und was da passiert lest ihr am besten im Paper nach) . Die Forscher legen dazu einige Eigenschaften fest und suchen im Memorydump dann nach diesen Eigenschaften. Das ist natürlich eine Fehlerquelle, in der Praxis funktioniert das aber:

As a result, while it is certainly possible to falsely identify an IDT or kernel paging structure, we conclude that our heuristics are effective in practice.