Por que passar os segredos através de variáveis ambientais consideradas “extremamente inseguras”?

Question

Passar segredos (senha) para um programa via variável ambiental é considerado "extremamente inseguro" de acordo com Documentos do MySQL e como má escolha (do aspecto de segurança) em outros recursos .

Eu gostaria de saber porque - o que é que estou perdendo? No manual do MySQL mencionado (estou usando isso como um exemplo), passar a senha via -p na linha de comando é considerado como " inseguro " e env env como " extremamente inseguro" ", fonte em negrito e itálico.

Eu não sou um especialista, mas sei os fundamentos: simples comando ps , mesmo emitido por usuário não privilegiado lê cada programa juntamente com parâmetros de comando enquanto apenas o mesmo usuário (e root, claro) pode ler o ambiente do processo. Portanto, apenas root e johndoe podem ler o ambiente do processo johndoe - iniciado, enquanto o script www-data hackeado lê tudo por meio de ps .

Deve haver algum grande problema aqui que eu esteja sentindo falta - então, por favor, me explique o que estou perdendo?

Meu objetivo é ter um meio de transferir segredo de um programa para outro, geralmente, não interativo.

    

Answer 1

extremely insecure and should not be used. Some versions of ps include an option to display the environment of running processes. On some systems, if you set MYSQL_PWD, your password is exposed to any other user who runs ps.

Elaborado em aqui ( via ):

Background: in the process image argv[] and envp[] are stored in the same way, next to each other. In "classic" UNIXes /usr/bin/ps was typically setgid "kmem" (or similar group), which allowed it to dig around in /dev/kmem to read information about the active processes. This included the ability to read the process arguments AND the environment, of all users on the system.

These days these "privileged ps hacks" are largely behind us: UNIX systems have all come up with different ways of querying such information (/proc on Linux, etc) I think all(?) of these consider a process's environment only to be readable by its uid. Thus, security-sensitive data like passwords in the environment aren't leaked.

However, the old ways aren't 100% dead. Just as an example, here's an example from an AIX 5.2 machine I have access to, running as a non-root user

[Fim da vida: 2009. Alguém sabe sobre AIX mais recente?]

...

For the record, some while back we discovered (on IRC?) that OpenBSD 5.2 has this exact security exposure of leaking the environment to other local users (it was fixed shortly after that release, though).

[Ano de lançamento: 2012]

    

Answer 2

Este conselho na documentação do MySQL está mal formulado.

Passar uma senha em uma variável de ambiente não é menos seguro do que transmiti-la na linha de comando, pelo contrário. A maioria dos unices modernos expõe argumentos de linha de comando de processos, mas não seu ambiente, a todos os usuários por meio do comando ps e outros softwares semelhantes. Existem exceções, mas eu nunca ouvi falar de um sistema onde é o oposto (expondo o ambiente sem expor os argumentos).

Incluir uma senha em um comando que é digitado em um shell interativo é uma má ideia, porque a senha acaba no histórico do shell. Tudo bem se o histórico do shell estiver desativado, mas você precisa se lembrar de fazer isso. Isso se aplica se a senha é passada como um argumento ou no ambiente.

O que pode ser mais perigoso com variáveis de ambiente é se a variável é passada para outros processos. Por exemplo, definir uma senha de banco de dados em .profile seria uma ideia muito ruim, já que seria visível para todos os programas. Da mesma forma, executar um script com export MYSQL_PWD=… próximo ao topo que executa muitos comandos além de mysql seria uma má ideia. Mas se a variável de ambiente só é passada para os comandos mysql , então não há nada de errado com isso.

A documentação do MySQL não deve usar linguagem que classifique a passagem de uma senha através de uma variável de ambiente como menos segura do que passá-la através de um argumento de linha de comando. É o contrário. (A menos que o ambiente esteja configurado para mais do que o comando mysql , mas esse não é o cenário descrito na documentação.)

    

Answer 3

O principal problema com a passagem de segredos em variáveis de ambiente é o escopo apropriado do ambiente para o processo que usa esse segredo, e para não fornecê-lo a processos que não deveriam tê-lo.

É seguro definir uma variável de ambiente apenas para iniciar um determinado processo que a utiliza.

Mas não é seguro definir segredos no ambiente globalmente em seu shell (para a sessão atual) (e ainda pior nos arquivos de inicialização globais do shell ( .bash_profile , .bashrc , .profile )) porque todo o processo lançado a partir desse shell terá esse segredo em seu ambiente. Alguns podem vazá-los, seja de propósito (malware) ou não (pense no histórico de comandos do shell ou em um módulo de relatório de falhas que despeja todo o conteúdo do ambiente em um arquivo de log ou em um servidor remoto).

Infelizmente, do ponto de vista de um desenvolvedor de aplicativos, é impossível garantir que os usuários do seu aplicativo esclareçam adequadamente o ambiente. Eu pessoalmente vi tantos segredos armazenados em ~/.profile .

Portanto, para evitar o mau uso do ambiente pelos usuários, é mais seguro não carregar segredos diretamente no ambiente (para reduzir o impacto de um vazamento) e usar variáveis de ambiente para passar links para onde o segredo é realmente armazenado : use uma camada adicional de indireção.