Arquivos históricos do BR-Linux.org apresenta:

Vulnerabilidade no kernel do Linux

Notícia publicada por brain em fevereiro 18, 2004 04:56 PM | TrackBack


O Gabriel Araujo (gabriel@macacos.org) avisa: "Acabei de receber um alerta na bugtraq avisando sobre a descoberta de um novo bug no código de gerenciamento de memória do kernel do Linux. Embora seja possível explorá-lo somente localmente, é importante dar o alerta a todos - upgrade nos kernels! As principais distribuições já anunciaram correcões." A falha afeta os kernels 2.2 (até 2.2.25), 2.4 (até 2.4.24) e 2.6 (até 2.6.2).

 

Comentários dos leitores
(Termos de Uso)

» Marcus Grando () em 18/02 17:00

Pois é, tava achando estranho ter saido tanto a versão final 2.4.25 quanto a 2.6.3 hoje...


» George Tavares () em 18/02 17:08

Pelo menos foram precavidos, consertaram antes de anunciar.


» Manoel Pinho () em 18/02 18:36

De novo esse negócio de exploits locais ? Isso pode não ser tão grave quanto exploits remotos, mas ainda assim é grave, especialmente em grandes redes de máquinas linux.

O pessoal está precisando dar uma auditoria severa no kernel.


» Silvio Fonseca () em 19/02 00:04

O pior é que este é o terceiro bug na mesma área, ta virando coleção:
do_brk, remap, unmap... Todos com exploits conhecidos (o do unmap vai ser liberado semana que vem, mas já existe) para escalar privilégios de um usuário qualquer para root... Basta uma vulnerabilidade qualquer em um daemon (apache, sendmail, bind, [coloque aqui um daemon que roda no seu servidor mais importante]) para ter um compremetimento total...

Alguém esqueceu de escrever os test cases para essa área do kernel... :-)


» help () em 19/02 00:54

Isso é para quem confia em Deus !!!
http://www.gracasadeus.cjb.net/
http://www.gracasadeus.cjb.net/
http://www.gracasadeus.cjb.net/
http://www.gracasadeus.cjb.net/
http://www.gracasadeus.cjb.net/
http://www.gracasadeus.cjb.net/


» o_O () em 19/02 01:35

Vale lembrar que aquele mero cliente FTP que coloca suas paginas PHP no ar, é um usuario local. Os scripts PHP sao usuarios locais, entao nao tem muito conforto em "nao ser remoto".

É impressao, ou dando uma pesquisada basica em http://www.cert.org/nav/index_red.html, encontramos mais problemas com Linux do que qualquer outro sistema operacional (windows incluso)? :/

E quase todos os ultimos incluem kernel 24 e 26 :\


» Oliver Pereira () em 19/02 08:58

É vc tem razão o linux aparece com mais erros ou bugs a diferença e que no Linux eles aparecem e as correções tambem, porque ninguem tem interesse de esconder já os outros...
Acho que vc deveria rever seus conceitos sobre remoto e local...(script=user_local) :-)


» Welington R. Braga () em 19/02 10:31

Erro sobre erro!

Remendo sobre remendo!

... e assim vai evoluindo o Kernel do Linux!

A diferença entre o resto é que nós vemos os bugs e remendos surgirem em "real-time", já nos outros só vemos depois de algumas semanas e até meses, quando é tarde demais


» kerneltrap () em 19/02 11:00

Isso pq já rola no underground notícias de que novas falhas estão por vir....

É esperar!!!


» o_O () em 19/02 12:20

Colega Oliveira.
Nao entenda mal, nao fico orgulhoso desse numero de problemas. Mas no exemplo que eu dei, as notas publicadas pelo CERT costumam tambem aparecer as correcoes, mesmo que demore mais. O lance e que a quantidade de falhas e alta. Algumas sao, como voce disse, corrigidas tao logo descobertas, mas sabemos que nem todas sao assim. Algumas ficam meio obscuras por um tempo, outras que nao damos a devida atencao ficam sem correcoes. E assim vao sites oficiais do Debian, FTPs oficiais sei la de quem, sendo comprometidos por falhas no kernel. Sai correcao? Otimo, mas vamos ter que recompilar kernel e aplica correcoes agora toda semana? Olha, nao sei quanto a voce, mas eu tenho cerca de 18 servidores que so eu cuido, todos diretamente acessiveis na rede. Cada falha, la vou eu aplicar correcoes ou mudar versao de kernel. Acredite, nao e a coisa mais produtiva de se fazer, e aplicar patches ou recompilar kernel nao tem as facilidades de atualizacoes binarias, que nem um windowsupdate da vida.
Entao acho que eu tenho algum direito de reclamar um pouco, ja que levo a serio e fico atualizando essas falhas todas, e nao e em uma ou 2 maquininhas. E nao e rapido tambem, pois nem todas maquinas tem seus 2Ghz de processamento e discos velozes.

E eu nao acho que tenha problema algum com meus conceitos de remoto e local. A execussao remota de um script eh a execussao de rotinas locais. Faca um CGI da vida e execute o id(1). Eis que voce e o usuario que roda o Apache. Um usuario local.
Pior ainda, a maioria das instalacoes PHP da maioria das distribuicoes vem com um php.ini aberto o bastante pra permitir execussao de rotinas POSIX ou de conectividade. E a maioria dos administradores Linux tem a pessima mania de nao colocar o /tmp em uma particao separada e menos privilegiada, e ai o PHP (usuario do apache, local) baixa e grava o que bem entender no /tmp e o executa. E bem vindo, o zezinho da malazia que e seu cliente web, executou um script remotamente, que foi processado com os privilegios do usuario local que roda o Apache. Bem vindo ao ambiente problematico.
Mais alguma falha nos meus conceitos?


» chimpa () em 19/02 13:28

Uma falha grave -> ***execuÇão***

>Acredite, nao e a coisa mais produtiva de se >fazer, e aplicar patches ou recompilar kernel nao >tem as facilidades de atualizacoes binarias, que >nem um windowsupdate da vida.

E vou te contar uma novidade: ninguém gosta de ter que ficar fazendo update e manutenção. Mas se vc ainda não percebeu - faz parte do jogo. E update e manutenção nem sempre estão relacionados com segurança, mas também para adquirir vantagens e novas features de versões mais recentes. Se está dando taaanto trabalho pra vc administrar 18 máquinas , talvez devesse se organizar melhor. Faz parte do jogo e não é nenhuma novidade.



» vladimir () em 19/02 13:38

Caro o_O,

mude suas máquinas para windows, que este ambiente não é problemático, não precisa recompilar kernel, as atualizações serão binárias e automáticas com o windowsupdate, e seu hardware será muito melhor aproveitado, já que nem todas as suas máquinas tem 2Ghz e discos rápidos. Uma beleza, nem sei pq voce tem 18 máquinas com linux.


» Marcus Grando () em 19/02 19:50

Defensores do windows, o linux também tem atualizações binárias e automáticas. E se for o caso de facilitar a atualização você mesmo pode fazer seu rpm e colocar nas suas várias máquinas. Não dependendo de ninguem para consertar o erro...

Cada um tem que cuidar do seu rabo...

Abraços


» Marcus Grando () em 19/02 19:53

>"Erro sobre erro!
>
>Remendo sobre remendo!
>
>... e assim vai evoluindo o Kernel do Linux!"

Pois é, que sistema para evoluir não tem que testar e mudar? inclusive o windows, ou tu acha que eles auditam muito o windows?

Todo desenvolvimento de alguma coisa esta sugeito a isso portanto não é um mérito do linux.

Se você olhasse bem o que cresceu nesse último kernel viria que para um bug tem muito mais coisa boa...

Abraços


» Roger de Almeida () em 20/02 20:37

Galera,

O Kernel é feito por humanos. Humanos erram!
Logo, o Kernel contém erros.

O software livre não esconde as suas falhas. Isso é importante, o que torna-o confiável. Entretanto, o proprietário, esconde seus "buracos", pois pode comprometer a sua "imagem".

[]
Roger


» Edilson () em 17/03 23:26

Galera (senhores, se necesssário),

Existe uma grande diferença em um sistema operacional fechado e um sistema operacionsal aberto. Quando foi lançado, o windows 95 (praticamente eliminando a plataforma DOS), a aceitação foi grande. Quando foram descobertos os "bug's" do windows 95, as criticas aumentaram (principalmente com a entrada da internet). Quando o windows98 SR2 foi lançado, os bug's do windows 95 sumiram quase que completamente, e o ciclo se repetiu com as novas versões. A diferença é que os bug's eram descobertos e ninguém podia resolvê-los (a não ser o proprietário).
Hoje o linux disponibiliza todo o código aberto (já aprimorado e com os recursos de cada versão). Hoje, nós temos todo um sistema operacional, bem aceito e poderoso em recursos em nossas mãos para utilizá-lo e alterá-lo conforme nossas necessidades.
O sistema não está bom para você? Adeque-o às suas necesssidades, se não está bom em recursos, ajude a aprimorá-lo.
Não tenho 18 servidores, mas no seu lugar procuraria um sistema pago e transferiria a responsabilidade. Não deixaria meus clientes na mãos.


Comentários desativados: Esta discussão é antiga e foi arquivada, não é mais possível enviar comentários adicionais.



O Arquivo Histórico do BR-Linux.org mantém no ar (sem alteração, exceto quanto à formatação, layout, tabela de caracteres, etc.) o acervo de notícias, artigos e outros textos publicados originalmente no site na segunda metade da década de 1990 e na primeira década do século XXI, que contam parte considerável a história do Linux e do Open Source no Brasil. Exceto quando indicado em contrário, a autoria dos textos é de Augusto Campos, e os termos de uso podem ser consultados na capa do BR-Linux.org. Considerando seu caráter de acervo, é provável que boa parte dos links estejam quebrados, e que as informações deste texto estejam desatualizadas.