Existe alguma maneira de o invasor poder usar o mkdir para comprometer um sistema?

Question

Estou configurando uma conta de usuário restrita para o usuário ricardo , um usuário problemático no meu sistema. Eu quero conceder a ele o direito de criar diretórios usando sudo , o que ele às vezes precisa fazer. Estou considerando essa regra no meu arquivo /etc/sudoers :

ricardo   ALL=(root) NOPASSWD: /bin/mkdir

Usando apenas esta regra, existe alguma maneira de Ricardo comprometer intencionalmente ou acidentalmente o sistema?

    

Answer 1

Eu suspeito que um ataque como esse funcionaria, onde «alguma coisa» é um módulo do kernel que tentará carregar após o rootfs ser montado:

$ sudo mkdir -m 777 /lib/modules/'uname -r'/a
$ cp evil.ko /lib/modules/'uname -r'/a/«something».ko

Note também que você pode usar outros nomes, dependendo dos alias declarados no módulo. Eu estou supondo que não será carregado até que o depmod seja executado, o que acontecerá na próxima vez que houver uma atualização do kernel - então o mkdir nem será mostrado recentemente no log do sudo.

Existem muitas coisas em / etc que leem todos os arquivos em um diretório, às vezes recursivamente. Pior ainda, alguns desses diretórios não existem por padrão, e a única maneira de conhecê-los é ler a manpage, os scripts de init, etc., para o programa que os utiliza. Alguns, pior ainda, são obsoletos com compatibilidade retroativa e podem nem ser mais documentados.

edit: Pensei em mais alguns diretórios, estes em /usr/local :

• /usr/local/lib/perl/5.14.2 (difere dependendo da versão do Perl, tente perl -V para descobrir). Crie um subdiretório File lá e coloque um Find.pm nele. Agora, sempre que alguém usar File::Find , eles usarão a versão do invasor. Da mesma forma, faça o mesmo com Getopt::Long . Utilitários do sistema são freqüentemente escritos em Perl, então isso provavelmente dá raiz. (Tente ack-grep --color -a 'use.+::' /usr/sbin | less -R )
• Acho que Python, Ruby etc. têm diretórios semelhantes. Os utilitários do sistema também são escritos em Python.
• Subverte muitas coisas que alguém compila com subdiretórios de /usr/local/include .

Answer 2

Ao executar mkdir como root, o usuário pode impedir que outros processos / usuários criem novos arquivos e diretórios criando diretórios com nomes idênticos (e / ou direitos incorretos) antes.

Isso pode ser relevante para a segurança, especialmente com arquivos de log e bloqueados .

Como jordanm anotou, o número máximo de inodes também pode ser usado que pode bloquear todo o sistema.

Ao adicionar o usuário a grupos específicos (ou usando ACLs ), você deve conseguir resolver os problemas sem conceder direitos via sudo .

    

Answer 3

Você deve redirecioná-lo para uma prisão chroot. Ou melhor ainda, para uma pequena VM, que ele pode falhar uma vez por hora. Tudo o que você precisa fazer é fornecer uma nova cópia.

    

Answer 4

Existem possibilidades devido à capacidade de criar diretórios com acesso de gravação. Com mkdir -m 777 blah , o usuário ricardo pode escrever o que quiser no novo diretório. Você precisaria de um processo no sistema já em execução como um usuário diferente que recorrerá a uma árvore de diretórios para carregar configurações, scripts ou módulos. Então, o usuário poderia adicionar suas próprias coisas para serem carregadas ou executadas. A primeira coisa que posso pensar é se você executar um servidor web que pode executar php ou cgi. Você poderia então executar scripts como esse usuário. Eu estou lutando para chegar a mais exemplos do mundo real, especialmente root , mas tenho certeza que eles estão por perto.

ssh é um exemplo de um daemon que captura esse tipo de cenário. Se você criou um diretório .ssh para um usuário que não tinha um e colocou seu próprio arquivo authorized_hosts no lugar. sshd percebe que as permissões dos diretórios estão abertas demais e ignora a chave pública.

Você pode definitivamente criar um incômodo criando diretórios onde espera-se que os arquivos apareçam (como arquivos transitórios tmp ou swap) que muitos programas não suportariam muito bem.

Você pode criar muitos cgroups, mas não parece que você faz nada com eles. Você pode ser capaz de trazer um sistema para seus joelhos, pelo menos. Demorou cerca de 10.000 cgroups em uma caixa com 256M para o assassino da OOM remover o sshd.

Se você controlar a opção -m para mkdir e o UMASK do ambiente sudo , acho que está de volta a ser apenas um incômodo.