# Kernel Bug (?)

## jbrazio

Ao passear pelos threads sem resposta deparei com uma em Italiano que apontava para o seguinte site que fala de um bug presente no kernel 2.4.x e 2.6.x em arquitectura x86. O kernel que estou a utilizar na minha maquina é o 2.4.20-gentoo-r6 com gcc 3.3.2, e é dado como vulnerável.. correndo o exploit nada acontece. Chegaram a testar as vossas maquinas ?

EDIT: Esta tambem na slashdot.

----------

## falso

ate corria pra experimentar.. mas nao quero estragar isto:

```

 17:33:10 up 83 days, 22:08,  1 user,  load average: 0.00, 0.00, 0.00

Linux rdk.homeip.net 2.4.25-gentoo #1 Seg Mar 22 04:01:29 WET 2004 i586 AMD-K6(tm) 3D processor AuthenticAMD GNU/Linux

```

----------

## jbrazio

 *falso wrote:*   

> ate corria pra experimentar.. mas nao quero estragar isto:

 

O máximo que te acontece é teres de resetar maquina.

----------

## falso

nao entendeste a piada.. caga nisso  :Very Happy: 

----------

## meetra

uptimes do bufo.

----------

## Enderson

Testei aqui o crash.c, e funcionou!  :Smile: 

Já estou aplicando o patch!  :Smile: 

----------

## fernandotcl

Esse é um bug um tanto quanto feio, principalmente porque não precisa de privilégios de super usuário para despertar.

----------

## leandro

 *Enderson wrote:*   

> Testei aqui o crash.c, e funcionou! 
> 
> Já estou aplicando o patch! 

 

Funcionou aqui tb, com o mm-2.6.7-rc3-mm1. Agora à noite já liberaram o mm2, com a correção.  :Smile: 

----------

## xef

O exploit tambem funcionou aqui(linux-2.6.5), já apliquei o patch.

Pelo menos com o linux ao mesmo tempo que se descobre um novo bug é lançado um patch para o corrigir.

O crash.c depois de aplicado o patch faz o que devia, desenhar pontinhos e asteriscos  :Wink: 

----------

## jbrazio

Eu felizmente não necessitei de aplicar patches. O que me intrigou foi o facto de o meu kernel ser dado como vulnerável e de facto não ser essa a situação.

Inicialmente pensei que era algum tipo de hoax mas visto que foi slashdoted e de facto o bug encontra-se marcado no bugzilla do kernel/gcc/gentoo desisti desta ideia.

----------

## codemaker

Eu tive notícia do bug através do kerneltrap.org há uns dias. Na altura ainda se debatia se o problema seria do gcc ou de kernel. Este assunto também estava a ser debatido na parte em inglês deste forum.

Ainda não apliquei patch no meu nem estou a pensar aplicar. Quando actualizar o kernel para 2.6.x com x > 6 trata-se disso  :Wink: . Ainda se fosse uma vulnerabilidade que pudesse ser explorada remotamente por entidades estranhas à máquina... agora quando o problema só se pôe se existirem pessoas que acesso a uma shell não me preocupei nada.

----------

## fernandotcl

Isso tudo mostra uma coisa bastante curiosa. Hoje mesmo o Windows travou pra mim, felizmente estava fazendo um backup e só tive que refazer. O Windows trava muito, mas muito mesmo, é normal travar, quebrar e exigir reboots (muitas vezes hard reboots), enquanto uma maneira de fazer o Linux quebrar já é considerada um exploit grave e fixada ASAP. Você percebe a diferença entre os sistemas por essas coisas.

----------

## jbrazio

Opá.. mas o Windows tem vontade própria.. utilizar Windows provoca uma sensação que penso que só pode ser comparada a jogar à roleta russa com uma Desert Eagle.

:-x

----------

## Mythos

O kernel que tinha development-sources/2.6.6 estava também com bug.

foi só correr o patch e recompilar, ficou tudo bem  :Smile:  Menos um bug  :Wink: 

```
wget -c http://linuxreviews.org/news/2004-06-11_kernel_crash/26_kernel_ia32-and-x86_64-fix-fpu-state.patch.txt

patch -p1 -d /usr/src/linux <26_kernel_ia32-and-x86_64-fix-fpu-state.patch.txt

cd /usr/src/linux; make dep && make clean bzImage modules modules_install; reboot

```

E o Kernel está pronto para outro!

----------

## r3pek

nao me lembro onde li, mas sei k li no artigo onde vi o security bug, que o gajo k detectou esta falha esxperimentou varios kernel's e o unico k nao teve problema foi o 2.4.20-gentoo. nao sabia pk, mas foi o unico k passou no teste....

----------

## xef

 *Mythos wrote:*   

> 
> 
> ```
> wget -c http://linuxreviews.org/news/2004-06-11_kernel_crash/26_kernel_ia32-and-x86_64-fix-fpu-state.patch.txt
> 
> ...

 

Isto é capaz de não ser suficiente, o bzImage é criado, mas não o vejo ser colocado em nenhum local pra ser usado pelo grub ou lilo  :Wink: 

----------

## To

 *jbrazio wrote:*   

> Opá.. mas o Windows tem vontade própria.. utilizar Windows provoca uma sensação que penso que só pode ser comparada a jogar à roleta russa com uma Desert Eagle.
> 
> 

 

Podias ter dito que era tipo jogar à roleta russa com uma semi-automática  :Laughing: 

Li esta nos prémios Darwin do ano passado, americanos...

Tó

----------

## peterx

 *r3pek wrote:*   

> nao me lembro onde li, mas sei k li no artigo onde vi o security bug, que o gajo k detectou esta falha esxperimentou varios kernel's e o unico k nao teve problema foi o 2.4.20-gentoo. nao sabia pk, mas foi o unico k passou no teste....

 

Acho que não viste o site referido pelo jbrazio. Porque, ainda são alguns os kernels que não são afectados pelo exploit.

----------

## r3pek

 *peterx wrote:*   

>  *r3pek wrote:*   nao me lembro onde li, mas sei k li no artigo onde vi o security bug, que o gajo k detectou esta falha esxperimentou varios kernel's e o unico k nao teve problema foi o 2.4.20-gentoo. nao sabia pk, mas foi o unico k passou no teste.... 
> 
> Acho que não viste o site referido pelo jbrazio. Porque, ainda são alguns os kernels que não são afectados pelo exploit.

 

por acaso nao tinha mesmo visto, mas o site k vi só tinha o do gentoo... eplo mesnos na altura  :Smile: 

----------

## jbrazio

 *To wrote:*   

> Li esta nos prémios Darwin do ano passado, americanos...

 

E eu a pensar que me tinha saido com uma original. :-/

jk

----------

## fernandotcl

 *xef wrote:*   

> Isto é capaz de não ser suficiente, o bzImage é criado, mas não o vejo ser colocado em nenhum local pra ser usado pelo grub ou lilo 

 

Verdade. E segundo os desenvolvedores do kernel, é mais seguro executar um "make mrproper" antes de tudo. Eu costumo usar, pra recompilar o kernel:

```
cp .config ~ && make mrproper && mv ~/.config . && make dep && make bzImage modules modules_install && mount /boot && cp arch/i386/boot/bzImage /boot && lilo && umount /boot
```

Só não sei se o caminho da bzImage está certo.

----------

## Mythos

ummm como é obvio sou masuquista e tenho uma bzImage numa pasta  para no caso de haver panic no kernel, ter uma imagem resguardada para alguama eventualidade.

se der barraca, tecla c root(0,2) kernel /xpto/bzImage boot ...

no grub ponho : 

```
kernel /usr/src/linux/arch/i386/boot/bzImage
```

assim ela é sempre actualizada  :Wink: 

----------

## jbrazio

 *Quote:*   

> -------- Original Message --------
> 
> Subject: Re: [gentoo-security] Advisory regarding the new Kernel DOS bug
> 
> Date: Fri, 18 Jun 2004 10:44:26 +0000
> ...

 

Não sei se alguém subscreve a Gentoo-security ML mas ao que parece falta pessoal para manter os pacotes de kernel actualizados.. Fica aqui o aviso para algum hackaro que queira entrar para a equipa Gentoo.

----------

## humpback

```

#include <stdlib.h>

#include <sys/types.h>

#include <unistd.h>

int main()

{

  while(1){

    fork();

    malloc(1024);

  }

  return 0;

}

```

Quero ver quantas maquinas por ai aguentam algo como isto. Muitos DoS que por ai andam são altamente complexos, mas coisas tão simples continuam sem soluçao.

----------

## fernandotcl

 *humpback wrote:*   

> Quero ver quantas maquinas por ai aguentam algo como isto. Muitos DoS que por ai andam são altamente complexos, mas coisas tão simples continuam sem soluçao.

 

Uma vez eu vi nos fórums internacionais uma forma de travar a máquina usando um comando do bash que deixava o processador em 100% de utilização. Eu fui testar, e no começo o mouse ficou travando muito, mas deu pra checar a utilização, 100%. Antes que eu pudesse digitar Ctrl+C ou Ctrl+Alt+Del ou mesmo Ctrl+Alt+Bksp, a máquina parou completamente de responder e tive que fazer meu primeiro hard reset no Linux. Me senti no Windows.  :Very Happy: 

----------

## RoadRunner

 *humpback wrote:*   

> 
> 
> ```
> 
> #include <stdlib.h>
> ...

 

Basta uma máquina com restrições ao número de processos possíveis para um determinado utilizador ou grupo. A protecção ao malloc existe em várias alternativas.

Antigamente na universidade havia uma máquina chamada pardal que era usada pelos alunos do segundo ano da licenciatura para fazerem os trabalhos da cadeira de Sistemas Operativos, isto porque a máquina Student onde todos os alunos têm as suas contas pessoais estava sempre a ir abaixo nas alturas dos trabalhos, por razões óbvias =)

A Pardal tinha esse tipo de restrições e funcionava na perfeição.

----------

## codemaker

 *RoadRunner wrote:*   

> 
> 
> Basta uma máquina com restrições ao número de processos possíveis para um determinado utilizador ou grupo. A protecção ao malloc existe em várias alternativas.
> 
> 

 

Exactamente. Uma coisa é a falta de recursos numa máquina que pode ser ultrapassada se se limitar a quantida de recursos que cada utilizador pode requerer. Outra coisa é um bug no kernel que o faz simplesmente parar independentemente dos recursos da máquina.

----------

## r3pek

coisas simples k crasham a makina.... ora deixem ca ver....

tentem por exemplo isto numa consola de X:

```
kill -9 -1
```

axo ké só assim...

não me perguntei pk... mas sei k isto numa consola de X crasha a makina.

e axo ké assim, não tnh a certeza. se assim nao crashar é:

```
kill -1 -9
```

coisas destas k ng se lembra né?  :Wink: 

----------

## humpback

 *RoadRunner wrote:*   

> 
> 
> Basta uma máquina com restrições ao número de processos possíveis para um determinado utilizador ou grupo. A protecção ao malloc existe em várias alternativas.
> 
> 

 

E elas são?

 *RoadRunner wrote:*   

> 
> 
> A Pardal tinha esse tipo de restrições e funcionava na perfeição.

 

A pardal tinha BSD e não linux  :Smile: 

Em bsd eu sei como fazer essas coisas.

----------

## r3pek

 *humpback wrote:*   

>  *RoadRunner wrote:*   
> 
> Basta uma máquina com restrições ao número de processos possíveis para um determinado utilizador ou grupo. A protecção ao malloc existe em várias alternativas.
> 
>  
> ...

 

nao acredito k as hardened-sources nao tenham nd para fazer isso...

----------

## RoadRunner

 *humpback wrote:*   

>  *RoadRunner wrote:*   
> 
> Basta uma máquina com restrições ao número de processos possíveis para um determinado utilizador ou grupo. A protecção ao malloc existe em várias alternativas.
> 
>  
> ...

 

hmm.. não sabia, pensei que era linux. Nesse caso já não digo nada então. De qualquer forma lembro-me que grsec tinha algo para restringir o número de forks. Para restringir memória não sei.. selinux será que tem?

----------

## codemaker

 *r3pek wrote:*   

> coisas simples k crasham a makina.... ora deixem ca ver....
> 
> tentem por exemplo isto numa consola de X:
> 
> ```
> ...

 

Não entendi. Repara:

man kill

 *Quote:*   

> 
> 
> DESCRIPTION
> 
>        The  default  signal  for  kill is TERM. Use -l or -L to list available
> ...

 

é natural que dê a impressão de crashar a máquina. Esse comando termina todos os processos. Era isso que querias dizer?

----------

## fernandotcl

Mas pra matar os processos do root você precisa ser root, não precisa?  :Confused: 

----------

## Mythos

Tanta preocupação, mas como já tenho dito a maioria dos problemas vem a nível de hardware, os processadores só cresceram em Mhz, só agora optam por algumas medidas de segurança, quanto ao fork, bom se é bug ou não, posso também dizer que o problema é da memória que não é suficiente, se os seus recursos fossem infinitos, não haveriam grandes problemas, penso que andaríamos de bengala e aquilo continuaria. 

Agora o do "crash.c" é que é engraçado  :Smile: , eu não percebo nada de programação, mas julgo que um bom programador de assembly consegue ainda fazer coisas mais engraçadas ...

Quanto ao grsec:

grsec-sources

Description: Vanilla sources of the linux kernel with the grsecurity 2.0 patch

acho que está nos packages do Gentoo...

----------

## fernandotcl

Engraçado, fui no link do LinuxReviews que foi postado no começo do tópico, e é impressão minha ou mudaram o programa? Esse não usa floats e está usando built-in assembly...  :Confused: 

E, continuando o assunto, a VIA ressalta que os processadores deles são os mais seguros (C3, Eden).

----------

## Mythos

fernandotcl onde é que está esse link ?

Por falar no LinuxReview tenho lá visto umas coisas intressantes, a IBM está a tentar dar a facadinha que levou da Microsoft, quando tinha lançado o OS/2 e a Microsoft com um sistema do piorio conseguio os passar e dominar o mercado.

Granda Guerra, SCO Vs Linuz Red Hat Vs SCO e IBM vs Microsoft. 

Por acaso não tinha reparado que o Linux estava a beliscar e de que maneira a Microsoft, será que eles não aprenderam que nada é eterno!!!

Só pena dqui a uns anos a IBM que já produz 40% do Kernel ou mais, começar a cobrar por isso.

----------

## codemaker

 *fernandotcl wrote:*   

> Mas pra matar os processos do root você precisa ser root, não precisa? 

 

Claro. Aquele comando executado por um utilizador normal apenas fecha os processos do utilizador em questão. Todos os outros utilizadores estão "protegidos" contra a utilização desse comando por qualquer outra pessoa. Assim, a utilização desse comando numa consola X por parte de um utilizador, resulta na terminação da sessão de X desse utilizador. A máquina não pára nem ocorre qualque comportamento estranho  :Wink: . 

Já utilizei esse comando centenas de vezes numa máquina com centenas de utilizadores. Seria engraçado se sempre que eu o executasse, ninguém conseguisse trabalhar em paz  :Very Happy: . Eu usava esse comando principalmente para me certificar que não deixava qualquer área ou processo aberto quando utilizava terminais públicos ou quando tinha vários processos que recusavam   ser terminados (experiências em programação) e não estava com paciência para enviar um signal kill a cada um deles individualmente  :Very Happy: 

----------

## fernandotcl

 *Mythos wrote:*   

> fernandotcl onde é que está esse link ?

 

http://linuxreviews.org/news/2004-06-11_kernel_crash/index.html

Está no primeiro post.  :Very Happy: 

 *codemaker wrote:*   

>  *fernandotcl wrote:*   Mas pra matar os processos do root você precisa ser root, não precisa? 
> 
> Claro.

 

Então não vejo problemas com isso. Porque se o objetivo é crashar a máquina pra num eventual reboot ganhar o controle dela, com privilégios de root isso não seria necessário.

----------

## codemaker

 *fernandotcl wrote:*   

> 
> 
> Então não vejo problemas com isso. Porque se o objetivo é crashar a máquina pra num eventual reboot ganhar o controle dela, com privilégios de root isso não seria necessário.

 

Obviamente. Por isso não entendi o que o r3pek quis dizer.   :Rolling Eyes: 

----------

## jbrazio

 *codemaker wrote:*   

>  *fernandotcl wrote:*   
> 
> Então não vejo problemas com isso. Porque se o objetivo é crashar a máquina pra num eventual reboot ganhar o controle dela, com privilégios de root isso não seria necessário. 
> 
> Obviamente. Por isso não entendi o que o r3pek quis dizer.  :roll:

 

Secalhar um bug antigo relacionado com o comando kill, estou a mandar postas de bacalhau ao ar neste momento.

----------

