irsl/google-osconfig-privescProva di concetto relativa alla falla di escalation dei privilegi identificata in Osconfig di Google.
Il processo google_osconfig_agent è un componente del tooling GoogleCloudPlatform (https://github.com/GoogleCloudPlatform/osconfig) che gira su ogni VM in modo predefinito. L'agente viene eseguito come root ed è responsabile di alcuni servizi controllabili dall'utente, incluso OS config (https://cloud.google.com/compute/docs/os-config-management), che è una sorta di implementazione Google della configurazione dello stato desiderato basata su polling.
Questa repository ospita una demo di una falla di escalation dei privilegi che ho identificato nell'implementazione (ed è stata corretta da Google in seguito).
I task da eseguire sono chiamati recipe e uno dei tipi di recipe supportati è l'esecuzione di uno script shell. Durante l'elaborazione di una tale recipe, l'agente - che gira come root con pieni privilegi - salva temporaneamente i file nella directory /tmp e poi li esegue. La directory creata dall'agente può essere dirottata e quindi lo script da eseguire può essere sostituito, portando di fatto a un'elevazione locale dei privilegi.
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)
Sistema operativo: istanza f1-micro di GCE con l'immagine Debian 10 predefinita.
Google è passata all'utilizzo di una directory temporanea casuale invece di una prevedibile.
La versione corretta è stata rilasciata il 2020-09-05. È necessario aggiornare il pacchetto del sistema operativo.
Questa è una vulnerabilità di escalation locale dei privilegi, quindi potrebbe essere sfruttata da chi ha già diritti di esecuzione di codice sulle VM GCE interessate:
chi ha una shell a bassi privilegi
un attaccante tramite un servizio di rete già compromesso
Il punto chiave è impossessarsi della "directory di base" (/tmp/osconfig_software_recipes), cosa possibile se nessuna recipe è stata ancora elaborata nella sessione corrente, il che significa:
nessuna recipe è stata ancora eseguita finora (ad es. la funzionalità osconfig non era in uso, ma lo sarà in un secondo momento)
la VM viene riavviata e tutte le recipe sono presenti nel db (/var/lib/google/osconfig_recipedb), ma alcuni aggiornamenti delle policy vengono eseguiti in un secondo momento
Anche se questa combinazione particolare diminuisce effettivamente la probabilità di sfruttamento, penso che utilizzare una directory di lavoro in /tmp non sia sicuro in questo caso. (Nemmeno Google lo riteneva sicuro, e da allora il problema è stato corretto.)
2020-08-07: Problema scoperto e segnalato
2020-08-08: Problema triagato da Google, priorità cambiata a P1
2020-08-10: Problema confermato da Google ("🎉 Bella presa!"), priorità cambiata a P2, severità a S2
2020-08-14: Aggiornamento sul processo VRP
2020-09-05: Problema corretto da Google
Imre Rad
https://github.com/GoogleCloudPlatform/osconfig
https://issuetracker.google.com/issues/163147689
https://github.com/GoogleCloudPlatform/osconfig/commit/fa7e4ba5ee85be212ffbac66d96862c792bd270c