Problemas de segurança na execução de scripts PHP como o proprietário do arquivo PHP com o suexec

Question

Estou usando o suexec para garantir que os scripts PHP (e outros aplicativos CGI / FastCGI) sejam executados como o titular da conta associado ao host virtual relevante. Isso permite proteger os scripts de cada usuário da leitura / gravação por outros usuários.

No entanto, ocorre-me que isso abre um buraco de segurança diferente. Anteriormente, o servidor da Web era executado como um usuário sem privilégios, com acesso somente leitura aos arquivos do usuário (a menos que o usuário alterasse as permissões do arquivo por algum motivo). Agora, o servidor da Web também pode gravar nos arquivos do usuário.

Portanto, embora tenha impedido que usuários diferentes tirassem proveito dos scripts uns dos outros, fiz com que, no caso de algum aplicativo ter uma vulnerabilidade de injeção de código remota, ele agora não só tivesse acesso de leitura, mas também acesso de gravação a todos os scripts e website desse usuário.

Como posso lidar com isso?

Uma ideia que tive foi criar uma segunda conta de usuário para cada conta de usuário no sistema, para que cada usuário tivesse sua própria conta de usuário e todos os seus scripts fossem executados com outra conta de usuário. Mas isso parece complicado.

    

Answer 1

A execução do PHP nas permissões do servidor da Web não é necessariamente melhor ou pior do que o uso do SuPHP. É apenas diferente . O primeiro modelo separa o proprietário do servidor da Web, enquanto o segundo modelo separa o proprietário (e seu código PHP) de todos os outros usuários na máquina.

O uso do suPHP não aumenta necessariamente sua segurança geral, apenas o redireciona. Em vez de tentar impedir invasões, você está isolando os sites uns dos outros. A justificativa é que, particularmente em um ambiente de hospedagem compartilhada, o antigo modelo de segurança não estava funcionando: os usuários constantemente exploravam sua segurança, definindo permissões de gravação mundial em tudo para que o aplicativo da Web funcionasse e, em seguida, o comprometimento de segurança em uma conta rapidamente metastataria para todos os outros no servidor.

Portanto, é comum agora usar ferramentas como suPHP em grandes ambientes de hospedagem compartilhada para remover a barreira entre o usuário e seu aplicativo PHP e, em vez disso, erigir uma barreira entre um usuário e seus vizinhos.

Portanto, neste caso, você não fornece segurança , você fornece separação . Infelizmente, o suPHP requer que os arquivos sejam de propriedade pelo usuário que você pretende executar, portanto, criar um usuário de FTP separado seria ... uma bagunça. Você precisaria constantemente de chown arquivos entre o usuário suPHP e o usuário FTP.

Em vez disso, você precisa escolher uma função: proteger um site ou proteger um servidor. Se você deseja proteger o site, é necessário separar o servidor da Web do proprietário do conteúdo. Esse é um relacionamento um tanto complexo para ser mantido corretamente, por isso não é recomendado para ambientes de hospedagem compartilhada. Se, ao invés disso, você quiser proteger o servidor de seus usuários, então use o suPHP para separar o usuário (e seu código) dos outros no servidor. Nesse caso, o usuário é responsável por sua própria segurança. Boa sorte, usuário! Tecnicamente, é possível ter um aplicativo PHP seguro - em teoria, pelo menos.

    

Answer 2

Primeiro, se o proprietário de um arquivo não precisar ter acesso de gravação, não o forneça. Você pode fazer isso definindo o primeiro número de permissões do UNIX. Isso significa que apenas o root terá acesso de gravação aos seus arquivos. Isso será muito chato quando precisarem atualizar os arquivos, mas você disse que eles não devem ter acesso de gravação ...

Em segundo lugar, eles executam seu script como um usuário específico. Se eles estiverem bloqueados em um arquivo usando open_basedir, não será um problema se eles puderem gravar seus arquivos. Se houver um hack, ele destruirá apenas os arquivos desse usuário. Mesmo sem o open_basedir, eles só devem poder gravar em seus arquivos, a menos que você tenha arquivos com direitos do 777, o que é outro problema.

Em terceiro lugar, muitos sites precisam ter acesso de escrita, pelo menos, para arquivos / pastas. Por exemplo, o Wordpress precisa escrever no caso de haver um upload de arquivo. O acesso de escrita para sites não é necessariamente uma falha de segurança se você gerencia bem.

O suexec é um bom começo e o open_basedir garante que seus usuários com acesso de gravação permaneçam no diretório definido.

    

Answer 3

suexec sempre me chamou a atenção para lidar com o fato de você estar em um ambiente de hospedagem compartilhada - permitindo que solicitações não confiáveis invoquem um script, já que o usuário proprietário é muito ruim (e como o WordPress é instalado ) - se você estivesse em um host dedicado, você não configuraria todos os seus arquivos para o modo 0777, afinal. Apenas remover o acesso de gravação não ajudaria, porque os arquivos ainda são de propriedade por esse usuário e, portanto, graváveis. Ter dois usuários separados também não ajuda muito, pelo mesmo motivo.

A solução correta, na minha opinião, seria rodar scripts como um usuário não privilegiado, mas chroot deles - talvez FastCGI seria uma boa solução aqui ... onde o processo fcgi é chrooted, mas o servidor web sabe onde encontre o socket que cria.

Eu percebo que isso não é uma "resposta" como tal, mas eu colocaria dinheiro em alguém que tenha inventado isso antes e provavelmente o implementasse - talvez até mesmo como um patch para suexec (eu imaginaria ForceSUExecUID e ForceSUExecGID opções que poderiam ser aplicadas por host virtual…)