© Lukas Gojda / 123RF.com

Virtuelle Sockets spielen vor allem in der Kommunikation zwischen virtuellen Maschinen und ihrem Host eine Rolle. In ihrer Implementierung wurden nun ernste Sicherheitslücken entdeckt.

Virtualisierung spielt seit vielen Jahren eine wichtige Rolle in der IT. Dabei kommen seit geraumer Zeit unter Linux auch virtuelle Sockets zum Einsatz. Sie erlauben eine effiziente Kommunikation zwischen virtuellen Gastsystemen und dem Host. Dafür findet die VSOCK-Adressfamilie Verwendung. Die eigentliche Netzwerkkonfiguration der virtuellen Maschine spielt dabei nur einen Nebenrolle, da die VSOCK-Familie davon unabhängig ist. Dadurch bieten virtuelle Sockets einen nützlichen Mechanismus für die Kommunikation zwischen virtuellen Maschinen und deren Host-Systemen, der nicht von den Details der eigentlichen Netzwerkeinstellungen abhängt.

Die Details der VSOCK-Implementation befinden sich in der Datei »linux/vm_sockets.h«. Über die »socket(AF_VSOCK, …)«-Funktionen lassen sich so virtuelle Sockets der Typen »SOCK_STREAM« oder »SOCK_DGRAM« erzeugen. »SOCK_STREAM« stellt eine Byte-Stream-Verbindung bereit, wohingegen »SOCK_DGRAM«-Sockets verbindungslos sind. Welche virtuellen Sockets genau zur Verfügung stehen, hängt vom zugrundeliegenden Hypervisor ab.

Der IT-Sicherheitsforscher Alexander Popov hat im Februar verschiedene Sicherheitslücken in der Implementation der virtuellen Sockets im Linux-Kernel entdeckt [1]. Insgesamt handelt es sich dabei um fünf verschiedene Schwachstellen, die ein lokaler Angreifer für Attacken gegen das System ausnutzen kann, etwa für Denial-of-Service-Attacken. Er kann allerdings auch Root-Rechte auf dem System erlangen und so größeren Schaden anrichten. Aufgrund des verbreiteten Einsatzes virtueller Maschinen innerhalb von Cloud-Computing-Lösungen ist die Sicherheitslücke als entsprechend kritisch einzustufen.

Die nun publizierten Schwachstellen schlummern seit November 2019 im Kernel und betreffen alle Versionen seit 5.5. Schon die erste Implementation der Virtual-Socket-Multi-Transport-Unterstützung des Kernels enthielt die Probleme. Die kritischen Schwachstellen hängen mit Programmierfehlern des Programmcodes der »CONFIG_VSOCKETS«- und »CONFIG_VIRTIO_VSOCKETS«-Kernel-Treiber zusammen, die in Modulform einen Bestandteil jeder größeren Linux-Distribution bilden. Die Module müssen für das erfolgreiche Ausführen der Attacke geladen sein. Diese Hürde kann ein Angreifer allerdings einfach nehmen, denn der Kernel lädt die beiden Module automatisch, sobald ein Benutzer des Systems einen virtuellen Socket über die »socket(AF_VSICK, …)«-Funktionen erzeugt.

Beim zugrundeliegenden Programmierfehler in den beiden Kernel-Modulen handelt es sich um ein Race-Condition-Problem. So bezeichnet man allgemein eine Situation in der Programmierung, in der das Ergebnis einer Operation vom zeitlichen Verhalten bestimmter Einzeloperationen oder der Umgebung abhängt. Besonders bei sicherheitskritischen Operationen hat ein solches Verhalten oft fatale Folgen für die Systemintegrität. Das Race-Condition-Problem tritt in der Datei »net/vmw_vsock/af_vsock.c« auf. Hier sind entsprechende Locking-Mechanismen zur Absicherung gegen derartige Fehler nicht korrekt eingebaut. Die fehlerhafte Programmierung fand sich schon in den ursprünglichen »VSOCKET«-Commits »c0cfa2d8a788fcf4« und »6a2c0962105ae8ce« vom November 2019.

Popov gelang es, einen darauf basierenden Exploit zu entwickeln, der es einem lokalen Anwender erlaubt, Root-Rechte zu erlangen. Dieser Exploit umgeht auch die üblichen SMEP- und SMAP-Schutzmechanismen. Popov hat daneben einen Patch für den Kernel bereitgestellt, der das Problem beseitigt. Der recht einfache Patch stellt sicher, dass die Transportvariable erst nach einem Aufruf der Funktion »lock_sock(sk)« der Variablen »vsk->transport« zugeordnet wird. Diese Korrektur muss man an insgesamt fünf Stellen der Datei »net/vmw_vsock/af_vsock.c« vornehmen, um die Race-Condition und damit das Angriffsszenario zu verhindern. (jcb/jcb)