DLL Hijacking também afetaria algumas distribuições Linux
Enviado por Alexandro Silva (alexosΘalexos·org):
“Durante esta semana vimos o “caos” reinando no império do tio Bill. Devido a falhas em DLLs no sistema da Microsoft foram encontradas cerca de 30 vulnerabilidades em seus produtos. HDMoore e sua trupe imediatamente atualizaram o svn do Metasploit com o exploit para explorar está vulnerabilidade. Só que no estilo “Nóis morde, mas nóis também assopra” foi criada uma ferramenta de auditoria, assim usuários do sistema de Redmond podem auditar seus sistemas em busca de falhas.
O site Exploitdb também disponibilizou dezenas de exploits para explorar estas falhas, estudem com muita cautela.
Porém foi descoberto que algumas distribuições Linux possuem uma vulnerabilidade similar, a falha teve inicio através de um patch do Debian ano passado. Distribuições como Ubuntu e Fedora também estão vulneráveis de acordo com as discussões iniciadas pelo pesquisador em segurança Tim Brown…” [referência: blog.alexos.com.br]
• Publicado por Augusto Campos em
2010-08-27
@brlinuxblog
Feed RSS
A única coisa é que para o conceito do Tim Brown funcionar com o Linux, é necessário que o usuário além de baixar o conteúdo malicioso e dar privilégios de execução para ele, execute ele como root.
Bem diferente de explorar a mesma falha no Windows, onde todo mundo é Admin por padrão e o UAC não é respeitado por ninguém (todos clicam no OK sem ler).
É uma falha em algumas aplicações linkadas dinamicamente no Linux, sim, mas muito mais difícil de ser explorada do que a falha equivalente no Windows.
Essa é mioha opinião, que tentei embasar minimamente. :)
@André Luis Pereira dos Santos, acontece que “vira e mexe” aparece uma falha no Linux que permite que o usuário adquira privilégios de superusuário sem que o sistema perceba.
@tenchi
Eu acho que na maioria dos casos o sistema acaba concedendo privilégios a mais pro usuário, ou criam-se regras muito genéricas para concessão de privilégios. Já vi amigos criarem regras abomináveis no sudoers apenas pela praticidade de se usar o sudo onde bem entenderem. =P
Sobre a tal da falha, eu acredito que ela não seja tão crítica para a gente; já vi situações anômalas parecidas com essa e o AppArmor / SELinux se encarregou de barrar a dita cuja.
@André Luis Pereira dos Santos, acontece que “vira e mexe” aparece uma falha no Linux que permite que o usuário adquira privilégios de superusuário sem que o sistema perceba.
…que são corrigidas em questão de horas pela equipe do kernel Linux ou algum voluntário ou equipe de voluntários, como o Projeto Debian.
Estou “muito preocupado” com o DLL hijacking. Uso Win XP sem anti vírus.
Isso não é falha do Windows, mas nos programas. E como diz no post http://blog.metasploit.com/2010/08/exploiting-dll-hijacking-flaws.html , “this flaw can be exploited by sending the target user a link to a network share containing a file they perceive as safe”.
@André Luis Pereira dos Santos,
“é necessário que o usuário além de baixar o conteúdo malicioso e dar privilégios de execução para ele, execute ele como root.”
Não é verdade. Não é necessário dar privilégios de execução nem executá-lo como root. Só é necessário baixá-lo.
Suponha que o usuário rode algum programa que coloque “:diretorio” no LD_LIBRARY_PATH, como indica o artigo linkado. O diretório vazio (antes do ‘:’) será tratado como diretório atual. Iniciando um programa via interface gráfica, esse diretório será a home do usuário em 99% dos casos. Caso o usuário baixe um libgtk-x11-2.0.so (ou outro arquivo ao qual o programa se linka) malicioso em sua home, ele será carregado por esse programa ao ser carregado. Pronto, conta de usuário comprometida.
Dependendo das intenções do invasor, ele nunca vai precisar pegar root na máquina para cumprir seus objetivos. Ele pode espionar aquele usuário em específico que é alvo dele. Se for uma máquina desktop, pode monitorar browsers, instalar keyloggers, e por aí vai.
Portanto fique atento ao nome dos arquivos que você baixa ;)
Epa olhando os comentários na lista.
Isto realmente pode acontecer no linux, e parando para pensar, bem obivio este bug, tanto no windows como no linux, e pode afetar muitas outras arquiteturas/sistemas (“programas alheios”)
Auditar tudo vai ser um belo trabalho, um exemplo de outro software que creio eu também pode ter esse problema é o tomcat quando rodado como super-usuário, ele redefine os LD_LIBRARY, da mesma forma que o couchdb, e deu até um frio na espinha minha, pois tenho servidor com couchdb e ubuntu
OpenSuse fora da lista, mas em certa forma nao esta imune ae isto!!!
@Pensador
Se o usuário não der permissão de execução para a lib maliciosa baixada, ela nãompoderá ser usada nem mesmo no espaço daquele usuário.
Alipas, usuários não root não podem sequer mudar variáveis do sistema, nesse caso variáveis que setam paths de libs.
Pelos menos não de software instalado via apt-get/yum e simiiares.
Ou seja, é um ataque bastante difícil de ser conseguido no Linux.
Novamente, é minha opinião.
Alguém ai vê uma forma de passar por cima dessa proteção?
@André Luis Pereira dos Santos,
Acho que você não entendeu o ataque ainda. Vou tentar explicar:
1) Suponha que você tenha algum programa instalado que, em seu script de inicialização, use export LD_LIBRARY_PATH=”$LD_LIBRARY_PATH:/usr/lib/meuprograma:/usr/libexec/meuprograma/blah” ou coisa do tipo. Apenas para clarificar: isso não foi colocado pelo invasor. Estamos supondo que exista algum programa no seu sistema que faça isso.
2) Leve em conta que o LD_LIBRARY_PATH setado no ambiente, antes do script rodar, provavelmente vai estar vazio. Leve em conta que a maioria dos programas iniciados por um usuário serão iniciados a partir da home do mesmo.
3) Suponha que o programa que será explorado é uma aplicação gráfica em GTK. Portanto, ele carrega a libgtk-x11-2.0.so. Em condições normais, ele tentaria carregar somente de /usr/lib e outros diretórios de sistema. Mas como o script de inicialização dele é falho, e deixou uma entrada vazia no LD_LIBRARY_PATH, então ele estará procurando a libgtk-x11-2.0.so no diretório atual (no caso a home do usuário) antes de procurar em /usr/lib.
4) O invasor te induz a baixar um libgtk-x11-2.0.so malicioso. Você baixa esse arquivo na sua home.
5) Quando você abrir o programa da próxima vez, se o arquivo que você baixou ainda estiver lá, ele será carregado.
6) Conta de usuário comprometida.
@Pensador
Passei por uma situação semelhante a essa, basicamente por um erro de ordem da LD_LIBRARY_PATH. O que me salvou foi o SELinux, ele não permitiu a execução do programa.
@Pensador
Suas premissas só serão verdadeira caso o software for escrito literalmente “nas coxas”.
Setar corretamente variáveis de ambiente, é obrigação.
Sei que acontece por ai, mas são poucos os casos tão primários e que estejam disponíveis em repositórios como so do Debian, Ubuntu, Red Hat, CentOS, SuSE e OpenSuSE e outras distribuições comprometidas com segurança.
Não podemos dizer o mesmo do que é achado for Windows em coisas como superdownloads.com.br, baixaaqui.com.br, download.com etc.
Estes ai são os “repositórios” Windows.
Na verdade, estão mais para supositórios.
Sou um defensor do Linux, mas que se a falha existe temos que corrigir e não ficar dizendo que a falha é difícil de ser explorado no Linux e ficar com os braços cruzados esperando uma invasão acontecer no nosso sistema.
Abs,
Pensador isto não funciona, nenhum software vai ficar procurando libs na home do usuario aleatoriamente, apenas em um local especifico.
@Fu
Só o Windows mesmo pra suas aplicações carregarem até DLLs via web sem checagem alguma.
@Roney
A falha não é do Linux. A tal “falha” é em aplicações que usam de maneira porca o carregamento de libs quando são dinamicamente linkadas.
Isso vale também pra Windows.
O fato, é que a coisa só explodiu no universo Windows e por enquanto, nenhuma aplicação usada por muitos usuários Linux apareceu afetada.
Fu, se o diretório do usuário estiver no path de bibliotecas, do jeito que o pensador descreveu, naturalmente os programas procurarão por suas bibliotecas lá.
Pra quem tá falando das permissões… E se a pessoa baixar um zip ou .tar.gz com os arquivos, extrair tudo e abrir o que ela quiser, o que é bastante comum? Arquivos compactados normalmente mantém as permissões, assim não será necessário marcar a permissão de execução.
Um exemplo de carregar arquivos do sistema no /home é o plugin do Flash. Ele fica dentro do .mozilla no seu /home. Se você instalar ele corretamente ele vai para outra pasta no raiz, mas o Firefox e o Konqueror sempre olham nessa pasta do “/home/você/.mozilla” em busca de plugins.
Estamos discutindo algo meio imbecil, já se disse que existe a falha e que pode atingir sistemas Linux.(PONTO) Já tem correção pra isso? qual é? esse é o assunto a se discutir… Você sabe o que a falha afeta? ainda não corrigiram, voce pode ajudar… Discutir que tem pelo no ovo é facil, vamos descobrir como o pelo apareceu lá e como tira-lo dali
Carregar lib da home é grosseiro, se a lib está em /home o programa tem que rodar isolado do sistema ponto final. depois que o programa termina sua execução, nada dele deve restar, se ele quer dados do sistema, somente leitura, mesmo na home da criatura, e de tempos em tempos a notificaçao de que um programa inseguro está rodando dando a opção de mata-lo, tanto na CLI quanto na Gráfica… sei lá… medidas extremas, para situações extremas… já tem muito tempo que eu acho que programas inseguros só devem rodar em sandboxes.
[WinUser com o veneno escorrendo...]
É… pois é, né? O fim dos “tempos”… ai, ai…
Desculpe, gente. Eu sou debochado mesmo. E eu uso Linux, mais precisamente o Ubuntu, minha distro por simpatia. Mas de boa, estou rindo mesmo é de muitos que batem no peito pra dizer coisas do tipo “Linux é seguro, Windows é uma peneira!!!” Mas felizmente não me refiro ao pessoal daqui, que até mantém um diálogo legal. O Windows pode ser um aro de basquete, tão aberto que é em relação a falhas, mas os furos na represa Linux estão começando a aparecer.
Mas tipo: sendo problema no sistema operacional ou nos programas, o fato é que a ilusão de que Linux é imune a falhas (que 98% da comunidade se mata dizendo isso, não vamos ser hipócritas) não pode ser mais aceita. Se a falha é mais difícil ou não de ser explorada se comparado com o Windows, não importa. Como disseram acima, é uma falha, independente do grau de agressividade para sistema A ou B.
E parabéns ao Br-Linux por trazer esta notícia. Deve ter muito site Linuxer por aí que pode estar evitando postar tal conteúdo por medo de possíveis gozações. Linux x Windows, Vasco x Flamengo, São Paulo X Corinthians, Homem x Mulher, Catolicismo x Evangelismo, Esquerda x Direita, Brasil x Argentina, enfim, sem os “VS” o mundo não teria graça.
Valério, que nóia estranha a sua. Em que mundo você vive? Isso tudo por causa de uma vulnerabilidade de segurança? Existem muitas outras, pra todo sistema operacional. Não existe segurança perfeita, existe um continuum (que inclusive conflita com a funcionalidade do sistema operacional ou aplicação), e é por isso que importa sim, bastante, que a falha seja mais fácil de explorar em um Windows do que em uma distribuição GNU/Linux.
Aliás, uma pergunta a outros leitores informados sobre o assunto. Me parece que a culpa de essa falha funcionar no GNU/Linux é devido ao estúpido comportamento de a variável $LD_LIBRARY_PATH (e também a $PATH, e outras variáveis de caminhos do sistema) assumir “.” (diretório atual) quando encontra um elemento nulo (como em “:/usr/lib/myapp”, que tem dois elementos). Alguém sabe se e como é possível esse mudar esse comportamento? Certamente seria oportuno para endurecimento (hardening) de sistemas.
Por isso eu compilo tudo estaticamente :-) Aí a aplicação depende só da libc :-) (é claro que tô brincando).
O cara nem precisa colocar a biblioteca nesta variável. Se o camarada definir só a variável LD_PRELOAD pro caminho da sua lib da morte, já dá pra fazer umas brincadeiras legais.
Mas querer contornar estes problemas me parece um comportamento do Windows, que vive tentando se proteger do próprio usuário, se esquecendo de se proteger de outras fontes de problemas :-)
@Patola, http://migre.me/19bpQ Acredito que seja possível colocar um
continuedentro daqueleif (len == 0)para evitar isso. Outro dica seria usar RBAC, que impede o carregamento de bibliotecas localizadas em locais que sejam passíveis de escrita pelo usuário.@tenchi, Não é “o cara” que coloca o caminho no LD_LIBRARY_PATH. O ataque é baseado na suposição que ele já esteja lá http://migre.me/19bAU
(…) vida longa ao debian :D :D :D
ref: http://www.openwall.com/lists/oss-security/2010/08/26/1
Será que um
export $LD_LIBRARY_PATH=/dev/null
no /etc/profile poderia mitigar este risco.
@Pensador
Caso interessante: Java, e suas variáveis de ambiente (a nível de desenvolvimento).