Descoberta falha grave no kernel do Linux

É necessário um shell local na máquina correto ?

É mais fácil desligar o computador no botão liga-desliga ! Nem precisa compilar nada ...

E quanto o FTP (conforme a noticia) : Alguém permite que um arquivo que "suba" por ftp seja executado ??
(acho que nem o Windows permite isso) ...

Então NÃO DÁ para explorar a falha remotamente, certo ??

Segurança "local" não existe !!! Basta chutar o gabinete !!! :-P

Testei na minha máquina e realmente travou - sem direito a Ctrl+Alt+Backspace ou entrar num shell ... minha preocupação é a mesma acima, será que dá p/ ser executada remotamente ?

Tem um patch que vi no site http://re.a.la/news/2004-06-11_kernel_crash/index.html.en

P/ kernel 2.6: http://re.a.la/news/2004-06-11_kernel_crash/2.4.26_i387.h_patch.txt

Celacanto Provoca Maremoto,

usando esse bug pode-se travar qualquer na qual você tenha uma shell. (ssh)

Não precisa ter acesso físico.

Esse bug é totalmente escroto. Totalmente mesmo, eu mesmo estou muito triste porque isso apareceu :( Como explorar isso de uma forma legal?

1. Acesse uma conta shell e execute o codigo.

2. Em uma maquina de "web hosting", compile o codigo na sua maquina, mande o executavel atraves de um FTP, tornando-o via FTP executavel também. Se o host permitir qualquer tipo de "server-side" scripts, como Perl, PHP, Python, ou seja la o que for, so mandar executar o arquivo que voce deu upload e tornou executavel.

Se pelo menos fosse apenas o root que pudesse travar... Mas infelizmente é o usuário tambem, entao qualquer processo pode simplesmente travar a maquina.

É realmente uma pena. :(

Alguém tem uma idéia de como esse programa funciona ?

Isso não é tão sério. . .

__A solução já veio. . .E, sinceramente, quantos programas maliciosos travam máquinas com Windows???É claro, é grave, mas não mortal, não é nada frente aos terríveis vírus do WIndows! ! !Trava a máquina, vocÊ reinicia e volta a funcionar. . .E não usa mais o código! ! !
__E se for no server? ? ?VocÊ é idiota de ficar usando executável de todo tipo num servidor???E ainda tem a solução que pode ser aplicada para contornar o problema. . .

Tem uma boa explicação em:
http://www.linuxreviews.org/news/2004-06-11_kernel_crash/index.html

Havia testado o código no kernel 2.6.6 e como era de se esperar a máquina travou, então resolvi experimentar o 2.6.7-rc3-bk6 (http://www.kernel.org/) e depois de executar o código nada de anormal aconteceu, creio que talvez possa ser uma alternativa bastante viável para quem não quiser ser afetado por este problema.
Acredito que qualquer um que use um computador espera ser afetado por um problema no sistema operacional algum dia (afinal tudo que é criado pelo ser humano é sucetível a erro), mas o interessante neste caso foi a agilidade e o compromisso da comunidade em DIVULGAR A EXISTÊNCIA E A GRAVIDADE do problema, solucioná-lo e disponibilizar rapidamente as correções.

É um código bem simples.
E foi descoberto ao acaso.
Parece ser uma falha na função Time do kernel.

É uma falha grave e não adianta ficar tampando o Sol com a peneira. O melhor a fazer é a solução sair rapidamente e ser divulgada logo.

Eu testei num kernel 2.4.26 com o patch do grsecurity, e tb travou... Essa foi braba.

Minha preocupação é quando vai ter um patch oficial do pessoal do www.kernel.org...

Não gosto de confiar muito em patchs de outros.

De qualquer forma o nosso amigo já falou que testou com o 2.6.7-rc3-bk6 e não teve problemas.

Acho legal no linux é isso.
É descoberta uma falha grave no kernel e você tem a notícia da descoberta da falha junto com a correção. Quero ver o tio bill ser mais rápido que isso. Só se atrasar o anúncio, o que não acontece no linux, porque sempre alguém vai querer vazar a informação.
Temos que lembrar que descobrir falhas graves como essa é esperado e não é nenhuma vergonha. Vergonha é lançar um sistema com mais de 20.000 bugs graves e conhecidos, como foi o lançamento do windows 2000, para quem não se lembra. Imagina, 20.000 formas conhecidas de você travar a máquina ou roubar um arquivo ou senha. E mesmo assim, lançou o sistema como estável.
Para quem não se lembra, essa informação foi tirada de um memorando interno da microsoft que vazou na ocasião.

O mais interessante de tudo é que trava e não trava, testei no servidor de internet aqui na empresa, o micro aparentemente está travado, mas ainda está com o compartilhamento ativado e com total funcionalidade, alguém teve a mesma experiência ??

Obs: travou todos os novos serviços, mas os que estavam funcionando não pararam!

Isso não é um dead-lock?? É quando o sistema trava a entrada (teclado), mas não trava o sistema. Na prática, você não consegue fazer mais nada, apesar dos programas continuarem rodando. Muita gente acha que isso é um travamento real.

Eu fiz um teste num kernel 2.4.18 e travou tudo , inclusive a seção SSH que eu estava usando.

Provavelmente, a principio os serviços básicos de rede estão ok! até ao ping está respondendo, mas não responde localmente de forma alguma, nem vídeo ou teclado, etc ...

[]´s

O interessante é perceber que hoje em dia as falhas encontradas no Linux já chegam às primeiras páginas - notei que uma chamada para esta falha está na capa do UOL há mais de 12 horas, por exemplo.

Falhas graves sempre teremos, da mesma forma que os prgramas de código fechado sempre terão. Mas este é sem dúvida um momento importante para perceber a diferença entre os dois modelos de desenvolvimento: a falha ser divulgada juntamente com o patch, e com a possibilidade de outras pessoas desenvolverem correções alternativas, é a meu ver uma grande vantagem.

Olá, testei com a versão 2.6.6 do kernel e o patch da página www.linuxreviews.org, bom o programa que trava está rodando a mais de dez minutos e eu escrevendo a mensagem para vcs. :-D Pelo menos a a solução saiu rapidamente. Pregunta: "Será q as páginas de notícias (não especializadas) vão colocar que a falha já está solucionada?" ;-D

Como foi colocado acima, se os serviços estão presentes não seria possível logar na máquina travada (ssh) e derrubar o processo mal comportado ? Alguém tentou?

Ué.. se ele trava os "futuros" processos não há tannnto assim o que temer.. heheh.. se alguém executar o código remotamente também não vai poder tentar qquer outra coisa depois.

Mas o mais interessante é que a correção já foi feita . Só espero que agora o UOL também publique isso rapidamente.

André Michi

Eu apliquei os dois patchs que estao sendo mencionados no site lá e testei e não travou... kernel 2.4.26 e nao é necessario shell local, tendo shell, ou ftp mesmo... mandando via ftp, criando um cgi e rodando... seja la com ofor... hehehehe trava :D

Aqui ocorreu algo engraçado. O máquina ficou totalmente travada, mais ainda respondia a pings. Mas eu não conseguia acessá-la por ssh. Se eu fizesse um telnet pra porta do ssh, ele chegava a conectar, mas o ssh não mandava nenhuma mensagem.

Dar enfase as más noticias os "abutres" da mídia fazem muito bem, mas quero ver se vão falar sobre os records em soluções a Bugs que o SL oferece, por este e mais outros motivos que não dou mais crédito ao que vem do lado do grupo da uol, falando em uol que leu a reportagem na veja sobre o okurt (é assim que se escreve?) verdadeiros abutres ensinados e programados.
Se fosse um software proprietário quanto tempo teria que se esperar para a solução ???

Sacanagem!

Alguém ai testou em uma máquina com selinux. Será q ele impede o programa de travar a máquina ?

Me pergunto se o kernel tb é escrito pensando-se na questao segurança e nao so desempenho, portabilidade,etc...

Testei no meu Debian unstable com o kernel 2.6.6
e travou tudo! É uma falha grave porém mostra como o software livre corrige suas falhas rapidamente. Se fosse no Windows teriámos que esperar o patch deles que ainda fodem com todo o micro!

Incrivel como tem gente xiita neste mundo. Ao inves de se preocupar em xingar a M$, deveriam era se preocupar em aplicar o patch, independente se é facil ou nao de exploitar o problema.. cresçam, e hajam como admins de verdade, sendo linuxista ou nao.

Trata-se de uma falha grave pois qualquer usuário que consiga executar o código malicioso trava o kernel - todos servicos já eram.

Bugs existem em qualquer programa, kernel, mecanismo. Quanto mais complexo, maior a possibilidade de falha.

Softwares livres possuem a vantagem da transparência. Falhas são descobertas depurando o código fonte ou mesmo por acaso, como ocorreu. Elas existem - é só uma questão de tempo.

Algumas pessoas acham que software proprietário fechado ganha vantagem por natuza - se vc não ve o código, tem menos chances de encontrá-la. Esse é um pensamento falso e , ironicamente, o próprio caso acima do Linux demonstra isso - o bug foi descoberto ao acaso. O autor inclusive pensou que se tratasse de um bug no gcc. Ver o código é uma das maneiras de se encontrar bugs, mas existem vários outros métodos de 'caixa preta' para encontrá-los. E eventualmente eles serão descobertos.

Logo, a diferenca está no tratamento desses bugs, assim como tratamento e respeito de quem utiliza (usuários) esse software.

Não quero ser nenhum flamer, mas hoje de manhã recebi este e-mail do Slackware-Security:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[slackware-security] kernel DoS (SSA:2004-167-01)

New kernel packages are available for Slackware 8.1, 9.0, 9.1,
and -current to fix a denial of service security issue. Without
a patch to asm-i386/i387.h, a local user can crash the machine.

More details about this issue may be found in the Common
Vulnerabilities and Exposures (CVE) database:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0554

Here are the details from the Slackware 9.1 ChangeLog:
+--------------------------+
Tue Jun 15 02:11:41 PDT 2004
patches/packages/kernel-ide-2.4.26-i486-3.tgz: Patched local DoS
(CAN-2004-0554). Without this patch to asm-i386/i387.h a local user
can crash the kernel.
(* Security fix *)
patches/packages/kernel-source-2.4.26-noarch-2.tgz: Patched local DoS
(CAN-2004-0554). The new patch can be found here, too:
patches/source/kernel-source/CAN-2004-0554.i387.fnclex.diff.gz
(* Security fix *)
patches/kernels/*: Patched local DoS (CAN-2004-0554).
(* Security fix *)
+--------------------------+

Where to find the new packages:
+-----------------------------+

Updated packages for Slackware 8.1:
ftp://ftp.slackware.com/pub/slackware/slackware-8.1/patches/packages/kernel-ide-2.4.18-i386-6.tgz
ftp://ftp.slackware.com/pub/slackware/slackware-8.1/patches/packages/kernel-source-2.4.18-noarch-7.tgz
ftp://ftp.slackware.com/pub/slackware/slackware-8.1/patches/kernels/

Updated packages for Slackware 9.0:
ftp://ftp.slackware.com/pub/slackware/slackware-9.0/patches/packages/kernel-ide-2.4.21-i486-4.tgz
ftp://ftp.slackware.com/pub/slackware/slackware-9.0/patches/packages/kernel-source-2.4.21-noarch-4.tgz
ftp://ftp.slackware.com/pub/slackware/slackware-9.0/patches/kernels/

Updated packages for Slackware 9.1:
ftp://ftp.slackware.com/pub/slackware/slackware-9.1/patches/packages/kernel-ide-2.4.26-i486-3.tgz
ftp://ftp.slackware.com/pub/slackware/slackware-9.1/patches/packages/kernel-source-2.4.26-noarch-2.tgz
ftp://ftp.slackware.com/pub/slackware/slackware-9.1/patches/kernels/

Updated packages for Slackware -current:
ftp://ftp.slackware.com/pub/slackware/slackware-current/slackware/a/kernel-ide-2.4.26-i486-4.tgz
ftp://ftp.slackware.com/pub/slackware/slackware-current/slackware/d/kernel-headers-2.4.26-i386-3.tgz
ftp://ftp.slackware.com/pub/slackware/slackware-current/slackware/k/kernel-source-2.4.26-noarch-4.tgz
ftp://ftp.slackware.com/pub/slackware/slackware-current/kernels/
ftp://ftp.slackware.com/pub/slackware/slackware-current/testing/packages/linux-2.6.6/kernel-generic-2.6.6-i486-5.tgz
ftp://ftp.slackware.com/pub/slackware/slackware-current/testing/packages/linux-2.6.6/kernel-headers-2.6.6-i386-3.tgz
ftp://ftp.slackware.com/pub/slackware/slackware-current/testing/packages/linux-2.6.6/kernel-source-2.6.6-noarch-3.tgz

Just the patch for 2.4.x kernels:
ftp://ftp.slackware.com/pub/slackware/slackware-9.1/patches/source/kernel-source/CAN-2004-0554.i387.fnclex.diff.gz
77d9eb0640f07df4167aaa53e0b42e2e CAN-2004-0554.i387.fnclex.diff.gz

Just the patch for 2.6.x kernels:
ftp://ftp.slackware.com/pub/slackware/slackware-current/testing/source/linux-2.6.x/CAN-2004-0554.i387.fnclex.diff.gz
e453d64187eac2216bebf85d72449fcb CAN-2004-0554.i387.fnclex.diff.gz

MD5 signatures:
+-------------+

Slackware 8.1 packages:
8bbced2d1f09d033de89ae5957427a25 kernel-ide-2.4.18-i386-6.tgz
050aa2dd8d38f0ba3de2fca621eb13c9 kernel-source-2.4.18-noarch-7.tgz

Slackware 9.0 packages:
21dbafdcf32d84c22daddc349a719420 kernel-ide-2.4.21-i486-4.tgz
56ca0fbf5778283a1d9a76a278cb7cf5 kernel-source-2.4.21-noarch-4.tgz

Slackware 9.1 packages:
614b79763721126939569f235d4524d6 kernel-ide-2.4.26-i486-3.tgz
43681f735928641a2b5fc786604bca77 kernel-source-2.4.26-noarch-2.tgz

Slackware -current packages:
7a19720356937bcc0f360b8b158a1419 kernel-ide-2.4.26-i486-4.tgz
c0d2d8b2977d5c86d100fe02a8c2681b kernel-headers-2.4.26-i386-3.tgz
8fbb66feb2d108baa6af6a895fc7f49a kernel-source-2.4.26-noarch-4.tgz
91ccc5ff7a5be15afdee86a60c6b408d kernel-generic-2.6.6-i486-5.tgz
bdcb17009e79bb375dad7fecdd7e60ae kernel-headers-2.6.6-i386-3.tgz
ed7c1e42f537414db8cd4dda8e2e9077 kernel-source-2.6.6-noarch-3.tgz

Installation instructions:
+------------------------+

Use upgradepkg to install the new packages.
After installing the kernel-ide package you will need to run lilo ('lilo'
at a command prompt) or create a new system boot disk ('makebootdisk'), and
reboot.

If desired, a kernel from the kernels/ directory may be used instead. For
example, to use the kernel in kernels/scsi.s/, you would copy it to the
boot directory like this:

cd kernels/scsi.s
cp bzImage /boot/vmlinuz-scsi.s-2.4.26

Create a symbolic link:
ln -sf /boot/vmlinuz-scsi.s-2.4.26 /boot/vmlinuz

Then, run 'lilo' or create a new system boot disk and reboot.

+-----+

Slackware Linux Security Team
http://slackware.com/gpg-key
security@slackware.com

+------------------------------------------------------------------------+
| To leave the slackware-security mailing list: |
+------------------------------------------------------------------------+
| Send an email to majordomo@slackware.com with this text in the body of |
| the email message: |
| |
| unsubscribe slackware-security |
| |
| You will get a confirmation message back containing instructions to |
| complete the process. Please do not reply to this email address. |
+------------------------------------------------------------------------+

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAzzc6akRjwEAQIjMRAmNLAJ9cY5eDhdmZJBDc4IoJD+owJ2PlkACcCOWh
DyVVz1pzzG06SBnUbpC/iHg=
=luGU
-----END PGP SIGNATURE-----

Ao que parece, o Slackware é a primeira distribuição popular a disponibilizar o patch.
Com execessão do Fedora, que já estava lá no site onde foi anunciando o BUG.

Me corrijam se eu estiver errado.
Por favor!

Pode ser talvez essa a causa que minha máquina aqui(slackware) também trava de vez em quando? Fico louco quando isso acontece! Não uso nada de código estranho, mas minha máquina trava às vezes. Realmente não sei o porquê.

Testei ontem na faculdade onde existe um sistema LTSP... Não tivemos mais aula...

Apliquei o patch 2.4.26_i387.h_patch e agora posso encerrar o processo normalmente. Ele fica usando uns 60% cd CPU e imprimindo vários pontos na tela mas não trava mais a máquina

John disse,
"Pode ser talvez essa a causa que minha máquina aqui(slackware) também trava de vez em quando? Fico louco quando isso acontece! Não uso nada de código estranho, mas minha máquina trava às vezes. Realmente não sei o porquê."

É John realmente tenho o mesmo problema quando estou usando o NetBeans, depois de entrar em modo de debug de uma aplicação por diversas vezes o Linux trava, teclado, GNOME, etc etc, mas o interessante é que tudo aparenta estar funcionando corretamente, tanto que a outra máquina que acessa a rede através do servidor "supostamente" travado, continua acessando a internet tranquilamente e vários outros serviços como httpd, named e dhcp também continuam na ativa, apesar de o único jeito de dar um shutdown, nesse momento ser o dedão no botão.

Leidson Campos
PlanetaMessenger.org

Ah. Sobre meu post anterior, meu Linux é o Fedora Core 1.

Leidson
PlanetaMessenger.org

Gente esse BUG é de respeito, mas não é tudo isso que estão falando, pois acabei de compilar o código C que trava o Linux e executei e realmente o servidor fica "travadinho", mas foi aquilo que postei anteriormente, vários serviços (ou todos) continuam funcionando perfeitamente, pois nesse exato momento estou postando de outra máquina (que inclusive é Win2k, ugfhh, me desculpem), mas que tem o acesso a internet disponibilizado através desse servidor Linux (Fedora Core 1) que está "travado" e se eu estiver certo, em alguns segundos vcs poderão ler esse post que estou escrevendo no momento (Viva o Linux).
John, para sua informação, acho que se trata do mesmo problema que acontece com vc, pois o comportamento da máquina quando se executa esse código C é exatamente o mesmo quando uso o NetBeans e o mesmo trava após algumas sessões de debug passo-a-passo.

Leidson Campos
PopolonY2k
PlanetaMessenger.org

Uhuuuuuuuuuuuuuuuuuuuuuuu,

Postou !!! Tá travado mas funciona.
Pergunta pros Windowzeiros se eles conseguem conectar com o micro travado.

VIVA O LINUX.

Leidson Campos
PopolonY2k
PlanetaMessenger.org

BOm, remotamente é possivel se:
- voce tiver acesso shell...
- alguns antigos daemons de ftp (wu-ftpd) se não forem bem configurados ou versões muito antigas permitem execução de arquivos remotos (por padrao ele permite upload no diretorio incoming, ai vc da um quote site exec /incoming/arquivo)
- alguma falha em algum daemon (famoso bug do SSL+apache que vc caia na shell do user do apache)

mas qual a graça de travar uma maquina ? que poder voce vai ter sobre ela ? hehehhe !!

Até
Alexandre Correa

Saudações a todos.

Analizem esse fato: Para travar uma máquina linux tendo um shell local ou via php cgi, como foi citado, você não precisa de um código que explore um bug do kernel. Basta fazer um código de duas linhas em C que duplique infinitamente um processo na memóira. Em 1 segundo a máquina está travada e também não é necessário ser root.