Propósito de usar setuid () em programas SUID

6

Gostaria de saber que um programa SUID como passwd está usando a chamada de função setuid() . Por que isso diminui os privilégios de root?

Contra que tipos de ataque isso ajuda? Buffer-estouro?

    
por flatronka 16.02.2013 / 11:47

2 respostas

10

Primeiro eu discutirei o bit setuid, que usa o passwd e é diferente da chamada do sistema setuid() (que o passwd não usa). Existe talvez alguma confusão na questão a este respeito.

Não é uma proteção contra um estouro de buffer, é vunerável para tal, ou basicamente qualquer coisa que permita que um invasor use um processo privilegiado para algum propósito indesejado nefasto. Isso ocorre porque o bit setuid é o oposto de "excluir privilégios"; ele concede privilégios de root, mas apenas ao processo e não ao usuário real. Isso inclui passwd .

Essa forma de setuid requer o bit setuid do sistema de arquivos definido no executável; passwd tem isso porque precisa de privilégios para ler e escrever /etc/passwd . No entanto, esperamos que o passwd não tenha nenhuma vulnerabilidade de segurança conhecida (por exemplo, potencial exploit de estouro) que permitiria que uma pessoa nefasta fizesse algo diferente de ler e escrever / etc / passwd (e diferente de fazer isso corretamente!) ele é executado como root e, portanto, poderia fazer qualquer coisa - exceto que ele é projetado para fazer apenas uma coisa específica e fazê-lo fazer qualquer outra coisa deve (novamente, esperamos que ) ser impossível.

Portanto, usar o setuid nesse sentido não é proteção contra qualquer coisa , mas é freqüentemente discutido em relação a vulnerabilidades, pois as vulnerabilidades potenciais são muito importantes executáveis do WRT setuid.

MAS: o bit setuid define o euid e não o uid real, por isso é realmente paralelo ao seteuid() chamada do sistema e não setuid() .

Existe uma forma oposta de "setuid" que é sobre a eliminação de privilégios, que envolve a chamada real do sistema setuid() e não requer o bit setuid. É quando um processo em execução como root (porque root ou sudo o iniciou) muda seu uid para um usuário menos privilegiado. Servidores e daemons geralmente fazem isso se precisarem de privilégios de root na inicialização (por exemplo, para abrir uma porta privilegiada), mas não posteriormente. Dessa forma, se o servidor subseqüentemente for gerado, ele não possui privilégios de superusuário. Você não pode chamar setuid(0) e obter privilégios de root de volta (mas você pode com set * e * uid).

    
por 16.02.2013 / 12:57
3

É simplesmente uma medida preventiva. Qualquer aplicativo pode estar potencialmente vulnerável a qualquer exploit concebível se incorreto. O truque para reduzir o possível dano é executar ações com o mínimo de privilégios requeridos. Deixar cair a execução como root quando não for necessário é um excelente começo.

    
por 16.02.2013 / 11:53