Que coisas ruins podem acontecer se não usarmos sudoedit?

Question

Sabemos que é mais seguro usar o sudoedit, mas que coisas ruins podem acontecer se tivermos o seguinte em sudoers?

Cmnd_Alias FOO = /bin/ed, /usr/bin/ed, /usr/bin/vi
foouser LOCALHOST = NOPASSWD: NOEXEC: FOO

O escape "foouser" para o prompt root? - claro, além de que ele agora poderia editar o arquivo / etc / shadow para colocar um hash pwd personalizado no usuário root para se tornar root em cerca de 3 segundos.

Talvez alguma mágica usando LD_PRELOAD com ed? Como exatamente?

* = o sudo ed seria executado como root. mas o sudoedit funcionaria como o usuário, o arquivo editado será copiado antes / depois de editá-lo.

    

Answer 1

Can the "foouser" escape to root prompt?

Presumivelmente, o foouser agora pode abrir qualquer binário do sistema e "editá-lo" em algo completamente diferente, deixando qualquer tipo de buraco de segurança que o filho possa sonhar. Isso tem um potencial especial se você fizer isso com um binário setuid, como passwd , porque significa que um usuário não-root poderia usá-lo para fazer coisas privilegiadas que ele não pretendia fazer.

besides that he could now edit the /etc/shadow file to put a custom pwd hash

Ou apenas exclua o hash, caso em que você não precisará de nenhuma senha para fazer login como root.

    

Answer 2

Existe uma quantidade incrível de arquivos que podem ser modificados para "instalar um backdoor" no sistema (editar /etc/group é o mais fácil, mas há muitas maneiras mais furtivas de alcançá-lo ). Também é possível desabilitar essa noexec protection editando /etc/sudoers file! Eu não confiaria em NOEXEC para tornar o "sudo $ editor" seguro. não é seguro. Use sudoedit (com muito cuidado porque muitos arquivos podem ser usados para ganhar privilégios de root!)

Futhermore, o wrapper noexec do sudo está rastreando um alvo (lentamente) em movimento (veja sudo_noexec. c history e A diferença entre fork (), vfork (), exec () e clone () ) . Portanto, o wrapper sudo_noexec pode não protegê-lo em alguma variante do Unix e não pode restringir novas chamadas do sistema (supondo que seu editor use essa nova API).

Para responder especificamente à pergunta sobre LD_PRELOAD , o arquivo de configuração do sudo ativa env_reset por padrão para fazer com que os comandos sejam executados com um novo ambiente mínimo . Então duvido que possa ser explorado.

P.S. Eu postei uma pergunta semelhante link !

    

Answer 3

O problema não é 'o que poderia acontecer' tanto quanto o que não poderia acontecer. Quero dizer, vi é uma ferramenta bastante poderosa, e usá-lo como um usuário privilegiado fornece muitos caminhos potenciais de ataque e exploração.

E é por isso que você não deve fazer isso - porque você está jogando 'bloquear o mousehole' em uma grande casa antiga.

Qualquer coisa interativa é "arriscada". Avenidas de ataque:

• Shell escapa - a NOEXEC ajuda aqui.
• Editando arquivos de configuração do sistema - há um monte de culpados "óbvios", como /etc/passwd etc., mas também há lugares onde você poderia, por exemplo, inserir um script CGI em uma instância do apache e escalar esse privilégio. Ou modifique um script chamado por root s crontab. (Isso é particularmente divertido se eles tiverem o NFS montado!)
• editando scripts do sistema (como o conteúdo de /etc/rc ).
• Ataques de travessia de links simbólicos - crie um link simbólico para /etc/passwd e edite esse para ignorar qualquer tipo de lista branca de arquivos.

Você pode também dar NOPASSWD: ALL porque tudo o que você realmente confia é que seus usuários não farão algo idiota como root.

Adicione o ponto adicional - muitas pessoas têm editores favoritos. Eu usei ed quando precisei, e principalmente uso vim nos dias de hoje. Mas nem todo mundo gosta deles. Uma das grandes vantagens do sudoedit é que ele permite usar qualquer coisa.