"LD_LIBRARY_PATH" é um risco à segurança?


8

Conhecemos ld.sopesquisas por bibliotecas em diretórios especificados pela variável de ambiente $LD_LIBRARY_PATH, mas usuários comuns podem executar:

export LD_LIBRARY_PATH=dir1:dir2...

Eles podem salvar a biblioteca infectada em um caminho com prioridade mais alta que a original, para ld.soencontrar essa em vez da biblioteca confiável na ld.so.cache.

Isso é um risco?
Como podemos desativar a gravação nessa variável de ambiente para usuários comuns?


Obrigado @Byte Commander pela edição. meu inglês não é bom :)
Sinoosh

Não tem problema, é melhor do que a média :)
Byte Comandante

Respostas:


17

Isso não representa um risco à segurança, porque você sempre pode definir apenas variáveis ​​de ambiente para seu ambiente atual (por exemplo, sessão atual do Bash) e, usando o exportcomando, seus ambientes filhos (scripts iniciados, subshells, etc.). É impossível escalar uma variável de ambiente criada ou modificada no ambiente pai. Isso inclui que é impossível para usuários regulares fazer alterações em todo o sistema, é claro.

Portanto, o único ambiente que seria afetado se você executar export LD_LIBRARY_PATH=...é o seu shell atual e quaisquer subconjuntos dele que você possa gerar mais tarde. Digamos que você altere o caminho de pesquisa para incluir bibliotecas infectadas no início, ou seja, com a maior prioridade. Em seguida, você executa um executável que carrega uma das bibliotecas infectadas sem nem mesmo saber. O que acontece agora?

Você tem código malicioso (da biblioteca infectada) sendo executado em sua própria conta de usuário com privilégios regulares de não administrador. Isso pode parecer ruim, mas na verdade ... e daí? É executado com privilégios regulares de usuário, o que novamente significa que não pode afetar o sistema inteiro. A propósito, executar diretamente um executável com o mesmo código malicioso teria sido muito mais fácil do que modificar o caminho de pesquisa da biblioteca e aguardar que um executável normal o carregasse.

Conclusão: Um usuário comum pode modificar apenas seu próprio caminho de pesquisa de biblioteca, o que significa que ele também pode carregar apenas essas bibliotecas em sua conta de usuário comum com privilégios regulares que não são do sistema. Dito isso, não faz diferença se eles forçam o carregamento de uma biblioteca infectada ou executam diretamente um executável infectado. Você não ganha absolutamente nada se essa variável de ambiente não puder ser substituída pelos usuários.

PS: Também existem executáveis ​​com o sinalizador setuid ou setgid definido, o que significa que eles não serão executados como o usuário / grupo de quem os executa, mas de quem os possui . Por exemplo, o sudoexecutável pertence à raiz e tem o sinalizador setuid definido, o que significa que sempre é executado como raiz quando executado. Por motivos de segurança, a $LD_LIBRARY_PATHvariável é ignorada pelos executáveis ​​com um dos sinalizadores setuid / setgid definido para garantir que o usuário comum não possa executar um executável executando com privilégios de root para carregar bibliotecas arbitrárias.
(Obrigado a @Rinzwind por apontar isso!)


Muito obrigado ! Estou lendo um livro que diz "o LD_LIBRARY_PATH é considerado um risco à segurança, pois pode permitir que programas não autorizados acessem acidentalmente as bibliotecas do sistema ou exponham os caminhos da biblioteca do sistema a usuários não autorizados". o que os meios?
Sinoosh

1
@Sinoosh Eu realmente não consigo pensar em uma razão pela qual deveria ser um problema de segurança se um aplicativo não confiável souber a localização das bibliotecas do meu sistema. Se tudo estiver configurado corretamente e você não mexer com as permissões, elas devem ser de propriedade do root e não podem ser gravadas por mais ninguém, o que significa que não há risco de que eles sejam infectados ou modificados de alguma forma (a menos que você execute o aplicativo não confiável como root , mas você não fará isso, certo?)
Byte Commander


@ Byte Comandante, estou de acordo com você e não com Autor :)
Sinoosh

Esta resposta não está totalmente correta. LD_LIBRARY_PATHé claro que é um problema de segurança quando você carrega uma biblioteca maliciosa e muda o comportamento de um binário.
heemayl
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.