Seite 5: RAM verschlüssen, Kaltstartattacken-Schutz & GCC-Plug-ins

Inhaltsverzeichnis

Arbeitsspeicherschutz gegen Kaltstartattacke

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 Herunterfahren durch Setzen einer Variable anzeigt, dass es keine schützenswerten Speicherinhalte gibt.

Arbeitsspeicher verschlüsseln

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.

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.

Code beim Kompilieren sichern

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.

Capabilities-Support für Container

In User Namespace laufenden 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.

Sicherheit allerorten

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 sowie Grundlagen zur Signal Mediation; der Basis-Support für Socket Mediation floss auch ein, wurde aber später entfernt, weil er bei einigen Anwendern für Probleme sorgte. 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ählt. 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 vor 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.

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. Ferner haben die Entwickler die Implementation von big_key im Key-Subsystem renoviert. Das passiert erst zur dritten Vorabversion von Linux 4.14, nachdem ein Programmierer allerlei Schwachstellen bei der Handhabung großer Schlüssel im Kernel-Keyring bemerkt hatte.