Isso não é um risco de segurança, pois você sempre pode definir variáveis de ambiente para o seu ambiente atual (por exemplo, a sessão atual de Bash) e, usando o comando export , seus ambientes filho (scripts que você inicia, subshells etc. . É impossível escalar uma variável de ambiente criada ou modificada no ambiente pai. Isso inclui que é impossível para os usuários regulares fazerem alterações em todo o sistema, é claro.
Assim, o único ambiente que seria afetado se você executasse export LD_LIBRARY_PATH=... é o seu shell atual e qualquer subshell 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 prioridade mais alta. Então você executa um executável que carrega uma das bibliotecas infectadas sem saber. O que acontece agora?
Você tem um código mal-intencionado (da biblioteca infectada) sendo executado sob sua própria conta de usuário com privilégios regulares de não-administrador. Isso pode parecer ruim, mas na verdade ... e daí? Ele é executado com privilégios de usuário regulares, o que significa que não pode afetar todo o sistema. By the way, diretamente executando um executável com o mesmo código malicioso teria sido muito mais fácil do que modificar o caminho de pesquisa de biblioteca e aguardando um executável normal para carregá-lo.
Conclusão: Um usuário comum só pode modificar seu próprio caminho de pesquisa da biblioteca, o que significa que ele também pode carregar apenas essas bibliotecas sob sua conta de usuário comum com privilégios comuns 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 se executam diretamente um executável infectado. Você não ganharia absolutamente nada se essa variável de ambiente não pudesse ser substituída pelos usuários.
PS: Existem também executáveis que têm o conjunto de sinalizadores setuid ou setgid , o que significa que não serão executados como o usuário / grupo daquele que os dirige, mas daquele que os possui. Por exemplo, o executável sudo é de propriedade de root e possui o conjunto de sinalizadores setuid , o que significa que ele sempre é executado como root quando executado. Por razões de segurança, a variável $LD_LIBRARY_PATH é ignorada por executáveis com um dos sinalizadores setuid / setgid definidos para garantir que o usuário comum não possa executar um executável com privilégios de root para carregar bibliotecas arbitrárias.
(Obrigado a @Rinzwind por apontar isto!)