O PHP exec () armazena o comando executado em qualquer lugar?

Question

Suponha que eu tenha o seguinte código em um aplicativo da Web PHP.

$encrypt ? $password = generatePassword($passwordstrength): $password="";
$estring = "7z a -p$password -mx0 packFoo.aes.7z mydir/foo";
if($encrypt) {
    exec($estring);
}
mailuser($password);//uses standard PHP mail function

A senha é gerada aleatoriamente por uma função que usa PHP rand ().

Eu não encontrei a senha em / var / logs e não em .bash_history.

Eu preciso saber se o valor de $ password pode ser recuperado do servidor no caso de o servidor estar comprometido. Por fim, posso afirmar que o valor de $ password não está armazenado no servidor?

    

Answer 1

Como apontado por Mat nos comentários , a menos que você configure especificamente a auditoria, é altamente improvável que o comando como tal seja deliberadamente armazenado em qualquer lugar e mantido em um formato diretamente acessível. grep -lR ... / como root pode ser uma experiência esclarecedora (você pode querer remontar tudo noatime primeiro ...).

No entanto, há sempre um "mas". Neste caso, uma possibilidade óbvia que eu posso ver (especialmente porque você não limpa com segurança as variáveis $ password ou $ estring no código que você mostrou) é que o conteúdo delas pode ser escrito para trocar espaço. Isso significaria que eles estão comprometidos com o armazenamento permanente pelo menos por um tempo, mesmo não na presença de um invasor ativo. Isso pode ser amplamente atenuado pela desativação do swap por completo ou pela execução de swap criptografado com uma chave de criptografia aleatória, o que torna a troca inacessível após uma reinicialização (porque a chave de descriptografia necessária para perdê-lo é perdida quando a RAM do sistema é limpa).

Eu imagino que 7zip é bem comportado o suficiente para limpar a senha de sua linha de comando rapidamente e depois para longe de suas variáveis internas assim que ela não for mais necessária, mas coisas como expansão os cronogramas principais podem ser mantidos por um longo período de tempo, aumentando assim o potencial para que eles sejam trocados. Aqueles não necessariamente permitirão a recuperação da senha, mas podem muito bem permitir a recuperação do texto original do arquivo criptografado. Um simples ps axw emitido no momento certo mostrará alguém que está logado na senha em texto simples a partir da linha de comando, mas não é armazenado e a janela de oportunidade é pequena. / p>

Quando você envia o e-mail, presumo que ele contenha a senha em forma de texto não criptografado (ou algo que seja facilmente derivado no texto simples correspondente, como um corpo de mensagem codificado em Base64). Esse e-mail quase certamente será temporariamente gravado na fila de e-mails do sistema , o que significa que a senha acaba no disco (a menos que você tenha o diretório da fila de e-mail em um Disco RAM, que além do fato de que a fila de mensagens deve estar em armazenamento persistente apresenta seu próprio conjunto de problemas operacionalmente). Especialmente se você estiver executando uma configuração inteligente, o arquivo de fila provavelmente será excluído muito em breve, mas, como foi gravado no disco, "o dano está feito", por assim dizer. Algo como strings /dev/sd? em qualquer servidor pelo qual o e-mail passa provavelmente recuperará a senha para qualquer pessoa que saiba o que procurar, a menos que você tome medidas específicas para atenuar essa ameaça.

É claro que o e-mail, em primeiro lugar, não foi projetado para ser completamente seguro. A única maneira de ter garantias confidenciais de confidencialidade com e-mail por SMTP (mesmo se você estiver usando SMTP sobre SSL ou STARTTLS, em toda a cadeia de servidores de e-mail) é criptografia de ponta a ponta, como S / MIME ou OpenPGP.

TL; DR: Seu aplicativo da Web provavelmente não armazena deliberadamente em qualquer lugar o comando, incluindo a senha ou a própria senha, mas outros componentes em que ela depende muito bem pode durante o curso de operações normais.

    

Answer 2

Primeiro, observe que você tem um problema de segurança maior: rand() não é adequado para gerar uma senha . Ele usa um gerador rápido e previsível de números pseudo-aleatórios. Use openssl_random_pseudo_bytes() em vez disso, como claramente indicado no documentação .

É comum registrar os nomes dos comandos, mas é incomum registrar seus argumentos. Portanto, a senha não terminará em um log do sistema, a menos que esse servidor tenha sido configurado para uma quantidade incomum de registro.

A linha de comando pode ser rastreada por qualquer processo em execução ao mesmo tempo que 7z , tudo o que precisa fazer é executar ps .

Você pode evitar colocar a senha na linha de comando passando apenas -p ( 7z a -p -mx0 packFoo.aes.7z mydir/foo ); Nesse caso, você precisará usar Espere para enviar a senha (duas vezes) para 7z , porque ela insiste em a senha vinda de um terminal e sendo digitada duas vezes. Aqui é um exemplo semelhante com ssh.

Por outro lado, a senha será armazenada no sistema de arquivos por algum tempo. Definitivamente será armazenado em um arquivo temporário no spool de email. Depois que o email é enviado, o arquivo temporário será excluído, mas a senha pode permanecer acessível por um processo em execução como root que acessa o disco diretamente para ler o espaço livre. A senha também pode ser trocada em algum momento.