Visite também: Currículo ·  Efetividade BR-Mac

O que é LinuxDownload LinuxApostila LinuxEnviar notícia


Escalada de privilégios no kernel

Enviado por Nicolas Wildner[Ironmaniaco] (nicolasgauchoΘgmail·com):

“O kernel linux foi expurgado de um bug que gera privilégios de root – novamente. Tal vulnerabilidade era de 2007, em um componente do sistema operacional responsável pela tradução de valores 64 bits para 32 e vice versa, e foi corrigido em 2007 com o lançamento do kernel de versão 2.6.22.7. Porém, vários meses depois, desenvolvedores inadvertidamente fizeram “roll back” desta alteração, deixando assim o sistema operacional aberto a usuários desprivilegiados a ganhar acesso total root.

O bug foi originalmente descoberto pelo hacker Wojciech “cliph” Purczynski. Porém, Ben Hawkes, o desenvolvedor que descobriu tal regressão, pensou com seus botões se tal falha ainda estaria ativa, gerando uma segunda versão do exploit.

Complemento: Olhando pelos links de referência você pode achar o “proof of concept” de tal exploit, que só precisa de um “gcc” para compilar. O resultado na minha máquina foi:

nicolas@debian:~/Pacotes/Exp$ whoami
nicolas
nicolas@debian:~/Pacotes/Exp$ ./a.out
resolved symbol commit_creds to 0xffffffff81067fc5
resolved symbol prepare_kernel_cred to 0xffffffff81067ec8
mapping at 3f80000000
UID 0, EUID:0 GID:0, EGID:0
# whoami
root

E meu usuário não possui qualquer regra de SUDO, ou privilégios adicionais concedidos pelo PAM. Agora é esperar que os mirrors “SEC” de todas as distros, atualizem o ultimo patch que corrige tal situação.” [referência: uncompiled.com]


• Publicado por Augusto Campos em 2010-09-16

Comentários dos leitores

Os comentários são responsabilidade de seus autores, e não são analisados ou aprovados pelo BR-Linux. Leia os Termos de uso do BR-Linux.

    Bremm (usuário não registrado) em 16/09/2010 às 7:37 am

    $ sudo uptrack-show
    Installed updates:
    None

    $ sudo uptrack-upgrade
    Nothing to be done.
    Your kernel is fully up to date.

    Considerando que já se passaram praticamente 24h, não vi nada falando sobre correções nas listas de segurança que acompanho (apesar do frenesi por ter uma falha ridícula como essa sem ter sido corrigida).

    Marcos Alexandre (usuário não registrado) em 16/09/2010 às 8:47 am

    tenso

    Adilson dos Santos Dantas (usuário não registrado) em 16/09/2010 às 9:01 am

    Nem vou esperar. Já estou aplicando o patch no kernel aqui em casa.

    david dias (usuário não registrado) em 16/09/2010 às 9:29 am

    Ué?! Cade os fanáticos numa hora dessas?!

    Osama Bin Laden (usuário não registrado) em 16/09/2010 às 9:37 am

    Osama,
    presente!

    Zhu Sha Zang (usuário não registrado) em 16/09/2010 às 10:03 am

    FreeBSD/Solaris nos servidores por aqui.

    o (usuário não registrado) em 16/09/2010 às 10:13 am

    Aqui o exploit deu erro de compilação

    $ gcc robert_you_suck.c
    robert_you_suck.c: In function ‘docall’:
    robert_you_suck.c:106: warning: cast from pointer to integer of different size
    robert_you_suck.c:110: warning: cast to pointer from integer of different size
    robert_you_suck.c:116: warning: cast from pointer to integer of different size
    robert_you_suck.c:117: warning: cast from pointer to integer of different size
    robert_you_suck.c: In function ‘main’:
    robert_you_suck.c:133: warning: integer constant is too large for ‘long’ type
    robert_you_suck.c:134: warning: integer constant is too large for ‘long’ type
    robert_you_suck.c:135: warning: integer constant is too large for ‘long’ type
    robert_you_suck.c:138: warning: cast to pointer from integer of different size
    robert_you_suck.c:171: error: ‘ORIG_RAX’ undeclared (first use in this function)
    robert_you_suck.c:171: error: (Each undeclared identifier is reported only once
    robert_you_suck.c:171: error: for each function it appears in.)

    Adilson dos Santos Dantas (usuário não registrado) em 16/09/2010 às 11:11 am

    Para o que deu erro de compilação: Veja se tem estes arquivos abaixo. Pode ser que não tenha instalado todos os pacotes do gcc.

    #include
    #include
    #include
    #include
    #include
    #include
    #include
    #include
    #include
    #include

    Ainda sobre o bug, apliquei os patches e o resultado foi o seguinte:

    adilsond@yoda:~/Downloads/exploit$ whoami
    adilsond
    adilsond@yoda:~/Downloads/exploit$ ./exploit
    resolved symbol commit_creds to 0xffffffff8105ad86
    resolved symbol prepare_kernel_cred to 0xffffffff8105ac80
    mapping at 3f80000000
    UID 1000, EUID:1000 GID:1000, EGID:1000
    sh-4.1$ whoami
    adilsond

    Então para o mais apressado ou paranóico pode pegar os patches nos links de referencia ou no meu blog enquanto não sai a atualização.

    Ironmaniaco (usuário não registrado) em 16/09/2010 às 11:36 am

    Aqui eu ficarei esperando os updates do CentOS(servidores de PRODUÇÃO), e do Debian(Desktop).

    E sim, eu rodei este exploit dentro de uma VM, e não na minha máquina REAL, pra mandar esta notícia pro Br-Linux…

    Ironmaniaco (usuário não registrado) em 16/09/2010 às 11:39 am

    >>> Então para o mais apressado ou paranóico pode pegar os patches
    >>> nos links de referencia ou no meu blog enquanto não sai a atualização.

    Eh. No site onde está o exploit, tem também os links do GIT para corrigir esse bug.

    >>> Ué?! Cade os fanáticos numa hora dessas?!

    Aplicando Patches, e não querendo iniciar flames como vc ;)

    >>> FreeBSD/Solaris nos servidores por aqui.

    EHUEHEUHEUEH. Olha as referências do Exploit, quem é parte da galera que escreve :P

    Linux (usuário não registrado) em 16/09/2010 às 12:01 pm

    Pobres mortais… esse exploit eh mais velho que o bug… rsrsrs.. Uma &%#$@! terem divulgado, “hacker” burro!

    foobob (usuário não registrado) em 16/09/2010 às 1:12 pm

    ZOMG, se não é um mítico cracker se fazendo de hacker!…

    Ironmaniaco (usuário não registrado) em 16/09/2010 às 1:30 pm

    >>> Pobres mortais… esse exploit eh mais velho que o bug…

    Bastava ler a notícia pra saber que é uma REGRESSION. Algo que havia sido corrigido mas voltou. Ai bastou reescrever pequenos trechos para que voltasse a funcionar…

    BSD_User (usuário não registrado) em 16/09/2010 às 1:30 pm

    Isto é uma vergonha!

    Piero Ferraz (usuário não registrado) em 16/09/2010 às 3:31 pm

    Pois é, aqui no meu note até posso corrigir mas na empresa onde trabalho pffffff

    sabe aquelas empresas que utilizam Linux só porque é gratuito e tem uma performance melhor do que o Windows, nada mais

    nunca, jamais rodam algum update rsrs, não trabalho na infra mas sei que a pessoa não ta nem ai pra isso, engraçado que sei que os clientes que também utilizam Linux não ligam pra essas coisas
    e que beleza, são só os servidores de banco de dados e firewall rsrsrsrs aqueles ” profissionais ” que usam Linux mas não sabem nada do mesmo.

    sempre dou azar trabalhar em lugares assim, eles assumem que o Linux é seguro e que não tem necessidade de atualizar.

    a realidade é que no mercado ta cheio de gente assim e inclusive nas empresas de grande porte, não acho certo culpar os desenvolvedores do kernel caso aconteça algo, quem administra esses ambientes é que deve ficar atento para essas coisas.

    se o Linux fosse 100% seguro não teria updates de segurança !

    Valdery (usuário não registrado) em 16/09/2010 às 3:31 pm

    Esse bug afeta quais versões do kernel Linux? Afeta a versão 2.6.34-4 ?

    Bremm (usuário não registrado) em 16/09/2010 às 4:07 pm

    @ Valdery

    Afeta todas até o presente momento, exceto a imediatamente anterior à regressão (que tem outros bugs).

    Para Ubuntu e derivados — recebi esta URL às 14h14min (horário de Brasília):

    https://edge.launchpad.net/~ubuntu-security-proposed/+archive/ppa/+packages

    Adilson dos Santos Dantas (usuário não registrado) em 16/09/2010 às 4:22 pm

    Valdery,

    Afeta em algum ponto depois da 2.6.23 até a 2.6.34.4 que é a última versão.

    Piero,

    Já peguei muitos servidores aonde não tem muita atualização por conta destes funcionários e atualizava todos eles. Agora nem sei o que está acontecendo após a minha saída.

    Mas isso não é exclusivo do Linux. Já vi casos de sistema desatualizados naquele de janelas que é bem pior.

    Bremm (usuário não registrado) em 16/09/2010 às 4:30 pm

    Eis as duas versões existentes que não são afetadas pelo bug:

    Linux kernel 2.6.22.7
    Linux kernel 2.4.35.3

    http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2007-4573

    Xinuo (usuário não registrado) em 16/09/2010 às 5:40 pm

    @Piero Ferraz, os servidores que administro só entram os administradores mesmo, ou seja, não têm pq temer elevação de privilégios, por parte dos usuários (pois eles já são admins).

    No meu desktop, que está com HD criptografado, só eu uso, e, lógico, que eu sou o admin e não costumo clicar em links ou baixar coisas e executá-las sem saber o que é, ou pesar a segurança.

    A vulnerabilidade não é de exploração remota, precisa que alguém esteja acessando o sistema local e execute algo. Assim está longe de ser uma emergência, no meu caso.

    Tb acho que não é o mesmo bug (e sim um descendente), pois foi necessário alterar o exploit antigo para que a falha fosse explorada. Não sei todos os detalhes, mas seria interessante saber quando o exploit deixou de funcionar, para saber quanto tempo ficou-se exposto ao bug original.

    O problema maior vai para admins que têm usuários (sem privilégios) utilizando os computadores. Dependendo do que fazem pode-se minimizar o risco com a opção de montagem “noexec” e “ro” nos file systems apropriados.

    Se forem usuários remotos de linha de comando, talvez um chroot tb funcione.

    Alguém sugere mais técnicas genéricas para evitar problemas como esse?

    Ironmaniaco (usuário não registrado) em 16/09/2010 às 6:04 pm

    >>> A vulnerabilidade não é de exploração remota, precisa que
    >>> alguém esteja acessando o sistema local e execute algo.
    >>> Assim está longe de ser uma emergência, no meu caso.

    Não é difícil de se achar servers com o usuários administrativos www-data, postgres, mysql, apache, nagios….etc.. com Shell válida e sem senha ¬¬.
    Retirar a Shell e colocar o !! no Shadow, seria interessante.

    >>> risco com a opção de montagem “noexec” e “ro” nos file systems apropriados.

    Exato.
    /home e /tmp que seriam os únicos lugares onde alguém com uma shell poderiam COMPILAR algo(caso você seja louco o suficiente para ter COMPILADORES em um SERVER DE PRODUÇÂO). Retira o defaults e mete o noexec na fstab. Bom demais.

    >>> Alguém sugere mais técnicas genéricas para evitar problemas como esse?

    Compiladores só em desktop e ambiente de homolog. Compilou em homologação, transfere pra produção.

    foobob (usuário não registrado) em 16/09/2010 às 6:20 pm

    compilou executável com exploit em desktop em ambiente de homolog, transferiu pra produção… voilá! rsrs

    Xinuo (usuário não registrado) em 16/09/2010 às 10:19 pm

    @foobob, ok, vc têm um executável e vai transferi-lo para o servidor de produção onde vc têm um login sem privilégio. Mas vc não falou o que fazer quando chegar lá e os únicos lugares que vc têm para gravar o programa (/home, /tmp ou /var/tmp) estão montados com a opção de noexec, ou seja, o SO não executa binários localizados nesses locais. E então o que vc faz?

    @Xinuo

    O chroot não adianta nada pois o cara pode escalar para root dentro do chroot e escapar. A maneira mais simples de escapar do chroot é virando root dentro dele.

    @Xinuo

    Realmente, ao que parece, a solução paleativa é montar /home e /temp como noexec na fstab.

    Isso vai fazer com que hackers normais não consigam usar o exploit. O cara tem de ser acima da média pra conseguir comprometer um software já rodando em outra partição com privilégio de execução, talvez aplicar um exploit nele de estouro de buffer e fazer ele baixar o executável de outro local e executar ele.

    Ou seja, o cara teria de usar 2 exploits para ter sucesso. E antes de tudo ele teria de encontrar um executável vulnerável já rodando na máquina para estourar o buffer e executar código arbitrário.

    É a melhor solução temporária enquanto não sai kernel novo já com o patch homologado pra galera usar em produção.

    Ricardo (usuário não registrado) em 17/09/2010 às 12:56 am

    Posso estar enganado ou não ter entendido a matéria direito mas, para obter acesso root, precisa do gcc?
    Se mudar a permissão do gcc para só o root executar não conserta a bagunça?

    @Ricardo

    No caso você não precisa do gcc na maquina que será atacada. Basta poder rodar o exploit que você pode ter pego compilado já.

    Se rodar o exploit em um kernel vulnerável, pimba. Escalou pra root e ai pode tudo.

    Nessas horas é legal pensar também no SELinux que pode barrar isso também, já que nele até root não pode sair fazendo qualquer coisa.

    Ironmaniaco (usuário não registrado) em 17/09/2010 às 9:16 am

    >>> compilou executável com exploit em desktop em ambiente de
    >>> homolog, transferiu pra produção… voilá! rsrs

    Se o cara tiver ESTE tipo de conhecimento sobre a infra, ta na hora de rever outros conceitos adicionais de acesso e de informação privilegiada.

    E outra, lembre-se que o /tmp e o /home estão MONTADOS com o noexec. Você não conseguirá fazer nada ;)

    Lucas Timm (usuário não registrado) em 17/09/2010 às 9:50 am

    Não funcionou nem no CentOS nem no RHEL :)
    Quem é melhor, pacotes estáveis ou pacotes atualizados?

    Filipe Rosset (usuário não registrado) em 17/09/2010 às 9:59 am

    Exato Timm. Provavelmente a RH não “desfez” a correção como foi feito na árvore principal. Outra observação como o Nicolas disse, é que só afeta arquitetura x86_64 ou seja pobres mortais rodando 32 bits não tem o problema.
    Testado no Fedora e o kernel contém a vulnerabilidade.

    Wallacy (usuário não registrado) em 17/09/2010 às 11:02 am

    Testei no SLED e não deu problema, porém no OpenSUSE deu…

    O correção já saiu, acho que só falta terminar de sincronizar os repositórios.

    Bremm (usuário não registrado) em 17/09/2010 às 3:11 pm

    @ Ironmaníaco

    Parece que o pessoal não conhece /bin/false… lol

    @ André Luis Pereira dos Santos

    O caso que o Ironmaníaco descreveu acima é um tremendo pepino. Basta um www-data com shell válido (e sem senha). É bom também ver se no /etc/ssh/sshd_config tem a linha “PermitEmptyPasswords no”.

    Wallacy (usuário não registrado) em 17/09/2010 às 3:34 pm

    Hum… Na verdade eu que fui lento: A correção saiu as 20h38m do dia 15. Ou seja 17h36m depois do post do camarada do uncompiled.com (e antes do post do BR-Linux).

    Eu que fui lerdo e não atualizei…

    Segue o screnshot do yast: http://img828.imageshack.us/img828/130/imagem4p.png

    Leonardo (usuário não registrado) em 20/09/2010 às 12:10 am

    Ao que tudo indica , esta falha foi utilizada para hackear (cracker) os servidores da locaweb

Este post é antigo (2010-09-16) e foi arquivado. O envio de novos comentários a este post já expirou.