Como usar a variável env do PATH para ler o arquivo / etc / shadow sendo o usuário regular

Question

Então este foi o projeto que recebi e estou preso no meio do caminho.

  

Na maioria das distribuições Linux (incluindo o Fedora e o Ubuntu), /bin/sh é na verdade um link simbólico para /bin/bash . Para usar o zsh, precisamos vincular /bin/sh a /bin/zsh . As instruções a seguir descrevem como alterar o shell padrão para zsh:

     

• faça o login como root
  
• cd /bin
  
• rm sh
  
• ln –s zsh sh
  

A função de biblioteca system(const char *cmd) pode ser usada para executar um comando dentro de um programa. A maneira como system(cmd) funciona é invocar o programa /bin/sh e, em seguida, deixar o programa shell executar cmd . Por causa do programa shell chamado, chamar system() dentro de um programa Set-UID é extremamente perigoso. Isso ocorre porque o comportamento real do programa shell pode ser afetado por variáveis de ambiente, como PATH ; essas variáveis de ambiente estão sob controle do usuário. Ao alterar essas variáveis, os usuários mal-intencionados podem controlar o comportamento do programa Set-UID.

     

O programa Set-UID abaixo deve executar o comando /bin/ls ; no entanto, o programador usa apenas o caminho relativo para o comando ls, em vez do caminho absoluto:

int main() 
{
    system("ls"); return 0;
}

     

Entre como root, escreva este programa em um arquivo chamado bad_ls.c , compile-o (usando gcc –o bad_ls bad_ls.c ) e copie o executável como um programa Set-UID em /tmp com permissões 4755.

     

É uma boa ideia permitir que usuários regulares executem o programa /tmp/bad_ls (de propriedade de root) em vez de /bin/ls ? Descreva um ataque pelo qual um usuário comum pode manipular a variável de ambiente PATH para ler o arquivo /etc/shadow .

Alterei com êxito o shell padrão para zsh, criei o executável bad_ls e copiei para /tmp com o ID de permissão 4755.

  

Descreva um ataque pelo qual um usuário comum pode manipular a variável de ambiente PATH para ler o arquivo /etc/shadow .

Aqui é onde eu estou preso.

Depois de executar o arquivo bad_ls , altero a variável PATH env para apontar para o diretório atual usando o código

export PATH =.:$PATH 

Se eu executar ls -a /etc/shadow , tudo que eu obtenho é este: /etc/shadow

Eu ficaria muito grato se você pudesse me guiar neste problema.

    

Answer 1

O problema é que system("ls") executaria o executável com o nome ls que encontrar primeiro no conjunto do usuário PATH .

Este ls não precisa necessariamente listar o conteúdo de um diretório. Em vez disso, poderia ser um script como este:

#!/bin/sh
cat /etc/shadow

Digamos que você coloque esse script em algum lugar em um diretório abaixo do seu diretório pessoal, por exemplo, /home/datashark/bin e adicione isso ao seu PATH :

PATH="/home/datashark/bin:$PATH"

Se você executar agora ls , não receberá uma listagem de diretórios, em vez disso, receberá uma mensagem de erro:

cat: /etc/shadow: Permission denied

Mas se você executar bad_ls , a system("ls") -call também procurará um executável chamado ls em seu PATH e localizará e /home/datashark/bin/ls em vez de /bin/ls . Como bad_ls é executado com permissões de raiz elevadas, o script chamado ls (em determinados sistemas - veja abaixo) também é executado com permissões de raiz elevadas e o comando cat /etc/shadow , que imprimirá o conteúdo de /etc/shadow .

Portanto, é uma má idéia para o root permitir que usuários normais executem bad_ls desde que ele tenha privilégios de SUID, porque ele executaria qualquer programa chamado ls que vem primeiro no usuário PATH .

Nota:

Isso não funciona em todos os sistemas Linux. Por exemplo, de acordo com man 3 system , ele não funcionará em sistemas em que /bin/sh seja vinculado a um (não corrigido) bash da versão 2 ou mais recente (2.0 foi lançado em 1996). bash descarta privilégios na inicialização. Isso não afeta somente o script ls , mas também a chamada system() antes, pois system() passa o comando para /bin/sh .

Pode funcionar em outras distribuições que não usam bash como /bin/sh . Ao contrário das informações declaradas no projeto, o Ubuntu (como Debian e provavelmente a maioria dos derivados de ambos) usa dash e não bash as /bin/sh e vem fazendo isso desde a versão 6.10 (a partir de 2006! Veja esta página no Wiki do Ubuntu . Parece que com as versões recentes do Ubuntu (pelo menos 16.04) dash e, portanto, /bin/sh são corrigidos para descartar automaticamente as permissões SUID (Procure "priv" em man dash ).