/Linux-Kernel 4.14: Speicherverschlüsselung und Kaltstartattacken-Schutz

Linux-Kernel 4.14: Speicherverschlüsselung und Kaltstartattacken-Schutz

Der Linux-Kernel 4.14 kann mit AMDs neuen Prozessoren den Arbeitsspeicher verschlüsseln. Neu sind auch einen Schutz gegen Kaltstartattacken und einige Tricks, um es Angreifern und Schadcode noch schwerer zu machen.

Das am 6. oder 13. November erwartete Linux 4.14 verspricht, die Systemsicherheit weiter zu steigern. Dafür sorgt unter anderem ein Schutz gegen Angreifer, die sensitive Arbeitsspeicherinhalte durch Neustart mit einem eigenen Betriebssystem abzugreifen versuchen. Erstmals unterstützt der Kernel jetzt auch die Speicherverschlüsselung, die einige der jüngst eingeführten AMD-Prozessoren beherrschen. Es fehlt aber noch Support für die wohl wichtigste Funktion, die AMDs Prozessoren den Betreibern von Cloud-Servern schmackhaft machen soll.

Die Kernel-Entwickler haben zudem einige GCC-Plug-ins verbessert, um es Angreifern noch schwerer zu machen, zur Rechteausweitung dienliche Stellen im Code zu finden. Details zu diesen und einigen weiteren Änderungen rund um die Sicherheit finden Sie in den folgenden Absätzen; in 4.14 eingeflossene Neuerungen rund um Netzwerk, Storage und Dateisysteme erläutert die zweite Seite dieses schrittweise erweiterten Artikels.

Der EFI-Code von Linux unterstützt jetzt eine Technik zum Schutz gegen Angreifer, die durch Neustarts an sensible Arbeitsspeicherinhalte zu gelangen versuchen. Bei solch einer Kaltstartattacke (Cold Boot Attack) löst ein Angreifer mit physischem Zugriff auf das System einen sofortigen Reboot aus, um dann mit einem von ihm kontrollierten Betriebssystem alle noch verbliebenen RAM-Inhalte auszulesen. Der jetzt eingeflossene Support für die “TCG Platform Reset Attack Mitigation Specification” erschwert diesen Angriffsweg: Diese Spezifikation implementierende BIOSe löschen beim Neustart alle Speicherinhalte, bevor sie wieder ein Betriebssystem starten. Das kann aber nennenswert Zeit kosten – die Firmware darf sich den Aufwand daher sparen, wenn das Betriebssystem beim Neustart durch Setzen einer Variable anzeigt, dass es keine schützenswerten Speicherinhalte gibt.

Neu ist auch der Support für AMDs “Secure Memory Encryption” (SME), mit der AMDs Epyc-Prozessoren und der für Business-PCs gedachte Ryzen Pro weite Teile des Arbeitsspeichers verschlüsseln können. Anders als der erwähnte Kaltstartattacken-Schutz im EFI-Code hilft das auch gegen Angreifer, die Speichermodule zum Auslesen in ein anderes System verpflanzen. Außerdem schützt SME auch gegen Lauschen (Sniffing) am Speicherbus oder den Diebstahl nichtflüchtiger Speichermodule (NVDIMMs).

AMD zielt mit der Technik aber offenbar vornehmlich auf Cloud-Provider. Dabei ist SME-Support in Linux aber nur der erste von zwei Schritten. Der zweite ist die auf SME aufbauende Secure Encrypted Virtualization (SEV), durch die der Prozessor die von Virtual Machines (VMs) verwendeten Arbeitsspeicherbereiche mit individuellen Keys verschlüsselt. Dadurch können Angreifer die Speicherinhalte anderer VMs nicht einsehen, selbst wenn sie aus einer VM ausbrechen und den Kernel des Hosts unter ihre Kontrolle bringen. Linux 4.14 beherrscht SEV aber nicht, denn die Patches zur Unterstützung in Linux und dessen Hypervisor KVM sind noch in der Begutachtungsphase; sie dürften bald folgen, sofern die Entwickler nicht noch Eigenschaften finden, die gegen eine Integration sprechen.


AMD

AMD Secure Memory Encryption (SME): Speicher-Controller verschlüsselt RAM.

(Bild: AMD
)

Weitere Details zu SME und SEV liefert eine im letzten Herbst publizierten Meldung zu AMDs RAM-Verschlüsselung. Weitere Hintergründe zur Memory-Encryption-Technik liefern einige Commit-Kommentare (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13), die zugehörige Dokumentation, ein Whitepaper von AMD oder ein älterer LWN.net Artikel. Letzterer erläutert auch die Software Guard Extensions (SGX) von Intel. Diese Speicherverschlüsselung zielt laut dem Online-Magazin eher auf Programme, die sensible Informationen vor lokalen Angreifern schützen wollen, denn mit SGX gehe ein größerer Geschwindigkeitsverlust beim Speicherzugriff einher. Intels Ansatz soll dafür Daten auch ohne VMs vor Angreifern schützen können, die den Kernel unter ihre Kontrolle gebracht haben.

Schrittweise aktualisierter Artikel

Dieser Text wird in den nächsten Wochen mehrfach erweitert, um nach und nach die wesentlichen Änderungen von Linux 4.14 zu beschreiben. Vor die Abschnitte mit bislang beschriebenen Neuheiten werden wir noch Absätze stellen, die Neuerungen bei Treibern, Architektur-Unterstützung und Kernel-Infrastruktur beschreiben. Details zur Versionshistorie des Artikels finden Sie am Artikelende.

Das “Randstruct GCC-Plugin” kann jetzt noch mehr in C programmierten Strukturen (struct) verwürfeln. Das beim Kompilieren des Kernels eingreifende Plug-in erschwert Angreifern ein Auffinden von Pointern in C-Strukturen, die auf häufiger zur Rechteausweitung genutzte Kernel-Funktionen zeigen; das Plug-in unterbindet so ein gezieltes Einspringen über bekannte, bei viele Kernel-Images zu findende Strukturen.

Dieses Plug-in für die GNU Compiler Collection bringt Linux seit Version 4.13 mit. Dort kann es aber nur handverlesene C-Strukturen des Kernel-Codes randomisieren. Durch eine in 4.14 eingeflossene Änderung verwürfelt das Plug-in nun automatisch alle in Frage kommenden C-Strukturen, solange eine Kennzeichnung im Code das nicht explizit untersagt.

Der prinzipbedingte und im Kernel-Log zu Linux 4.13 erwähnte Nachteil des Plug-ins bleibt aber: Für Debian, Fedora, Ubuntu & Co. bringt der Ansatz nur wenig, denn damit Nutzer eigene Module für die Kernel dieser Distributoren erzeugen können, müssten deren Macher den zum Randomisieren verwendeten Zufallswert veröffentlichen – mit dieser Information hätten Angreifer dann aber wieder alles zur Hand, um zur Rechteausweitung dienliche Stellen in C-Strukturen leicht aufzuspüren. Für Hersteller von Embedded-Hardware eignet sich das Ganze daher mehr; ebenso für Facebook, Google und andere Firmen, die in ihren Rechenzentren eigene Kernel einsetzen.

Randstruct war nicht das einzige GCC-Plug-in, an dem die Entwickler geschraubt haben: Das “Structleak Plugin” kann beim Kompilieren jetzt auch Variablen von C-Strukturen initialisieren, bei denen struct nicht im Kontext seiner Erzeugung, sondern erst später im Codefluss über Referenzen gefüllt wird. Das Compiler-Plug-in sorgt so bei mehr Code dafür, dass Strukturen nach der Initialisierung keine zuvor im verwendeten Arbeitsspeicherbereich liegende Daten enthalten, sondern Nullwerte. Das in Linux 4.11 integriert Structleak soll so Informationslecks vermeiden, die Angreifern dienlich sein könnten.

In User Namespace laufende Werkzeuge können nun auch Capabilities setzen, mit denen Programme einige für ihre Arbeit wichtige Rechte nutzen können, die normalerweise dem Root-Anwender vorbehalten sind. Einige Distributionen nutzen Capabilities etwa für ping, damit das Werkzeug automatisch beim Aufruf einige zur Arbeit nötigen Netzwerk-Privilegien erhält, dabei aber nicht mit Root-Rechten läuft, wie es beim SUID-Bit der Fall ist. Die Capabilities sind dabei in erweiterten Attributen (Extended Attributes/EAs) hinterlegt, die sich in einem User Namespace nicht anlegen lassen. Das gelingt jetzt, was etwa zur Installation und zum Bau von RPM-Paketen in Containern wichtig ist, die Capabilities verwenden und die User Namespace nutzen. Bei dieser Namespace-Technik entsprechen die im Container sichtbaren User-IDs nicht jenen des Hosts; vielmehr gibt es ein Mapping, durch das ein Anwender im Container Root (UID=0) sein kann, zugleich auf dem Host aber eine normale, unpriviligierte User-ID hat (UID typischerweise größer 1000). Damit sich ein Root-Anwender im Container über selbst erzeugte Capabilities keine zusätzlichen Rechte verschafft, landen diese in einem anderen erweiterten Attribut als auf dem Host. Details zum Ganzen liefern ein Commit-Kommentar. Auch LWN.net hat einen Artikel zum Capabilities-Support für User Namespaces – die Implementierung hat sich seitdem aber etwas geändert.

Wie schon bei den vorangegangenen Linux-Versionen haben Canonical-Mitarbeiter auch bei 4.14 einige Verbesserungen an der Sicherheitslösung AppArmor eingebracht. Darunter sind etwa Mount Mediation, Grundlagen zur Socket Mediation und Signal Mediation. Einige dieser Funktionen hat das Unternehmen jahrelang nur für den eigenen Ubuntu-Kernel entwickelt. Seit einiger Zeit bemüht sich der Distributor aber endlich um die Integration. Offenbar ist das dem Paketformat Snap zu verdanken, denn dessen Werkzeuge nutzen viele AppArmor-Funktionen zum Abschirmen (“Confinement”), was zu einer der Kernfunktionen von Snap zäht. Auf Distributionen abseits der Ubuntu-Familie gelingt der Sandbox-Betrieb aber bislang oft nicht oder nur eingeschränkt, weil deren Kernel einige der benötigten AppArmor-Funktionen nicht beherrschen. Das bleibt fürs erste aber auch so, denn dem offiziellen Kernel fehlen nach wie einige von Snap verwendete AppArmor-Features. Bei Distributionen, die SELinux nutzen, wird die Problematik wohl noch länger bestehen bleiben, denn AppArmor und SELinux können nicht gleichzeitig aktiv sein.

Kernel-Log zu Linux 4.14

Am 16. September hat Linus Torvalds die erste Vorabversion von Linux 4.14 freigegeben. Damit hat er die “Merge Window” genannte Phase des Entwicklungszyklus abgeschlossen, in der er alle wesentlichen Änderungen für eine neue Kernel-Version einpflegt. Größere, erwähnenswerte Änderungen passieren danach nur noch in Ausnahmefällen. Das Kernel-Log kann daher schon jetzt einen Überblick über die wichtigsten Neuerungen des Linux-Kernels 4.14 liefern, der am 6. oder 13. November erscheinen dürfte.

Eine Reihe von Änderungen gab es auch an Treiber und Infrastruktur für Crypto-Beschleuniger. Durch eine davon unterstützt der schon länger in Linux enthaltene Treiber für AMDs Cryptographic Coprocessor (CCP) jetzt auch den “AMD Secure Processor”, der in Vega-Grafikchips steckt und einen CCP enthalten soll.

Der ARM-, ARM64- und x86-Code enthält jetzt einen Sicherheits-Check, der Adress-Limits bei Zurücksprung in den Userspace prüft, um den Kernel-Code vor dem Überschreiben zu schützen.

Einige unter dem Oberbegriff “Secureexec” entwickelte Änderungen versprechen eine bessere Resourcen-Limitierung per Rlimit bei Programmen, die SETUID oder SETGID nutzen, um mit Rechten anderer Nutzer oder Gruppen zu laufen.

Einige weitere Detailänderungen, die die Sicherheit verbessern, nennen die Merge-Commits der Subsysteme User Namespaces, Seccomp und SELinux.