[1] Comentário enviado por sombriks em 09/05/2007 - 04:20h

hahaha, essa funciona até em windows, rodando cgywin.

Agora o desafio é algum atacante conseguir shell no seu server pra fazer uma forkbomb dessas.

PS: a versão em C é mais rápida!

http://en.wikipedia.org/wiki/Fork_bomb

0 0

[2] Comentário enviado por cesperanc@ em 09/05/2007 - 08:29h

Ehhhehhhh...
Gentoo rulez....

No meu gentoo lindo a sequência não funcionou... coloca o job em background mas segundos depois diz:
bash: fork: Resource temporarilly unavailable...

Sou um homem um pouco mais feliz...

0 0

[3] Comentário enviado por removido em 09/05/2007 - 08:45h

No ubuntu 7.04 precisa digitar 2x a seqüência pra travar.

1 0

[4] Comentário enviado por super-root em 09/05/2007 - 08:55h

Testei no slackware 10.2 e não travou kkkk!

0 0

[5] Comentário enviado por bestlinux em 09/05/2007 - 09:30h

Pelo que vi nos comentarios, so travou no Debian entao ?? o_0

0 0

[6] Comentário enviado por Edy em 09/05/2007 - 09:41h

Vou testar no servidor que hospeda uma base Oracle aqui na empresa.... Acho que um Red Hat...

0 0

[7] Comentário enviado por lucas.suporte em 09/05/2007 - 09:56h


Artigo interessante irei testar na minha distro!!!!
Valeu pelos links de bash estava procurando uns links e os que vc passo são bons !!!
Valeu

Lucas Rocha

0 0

[8] Comentário enviado por tenchi em 09/05/2007 - 10:03h

Aqui travou no Ubuntu Feisty...
Seu desgraç%$%$#@! Vc travou minha máquina!!!!! HAUHAUHUA

Nossa, eu já arrumei vários jeitos de travar minha máquina, mas um jeito tão simples assim é novidade (tente executar um vídeo no framebuffer do MPlayer em desenvolvimento... Vc perde o controle total sobre o teclado, se o vídeo travar... ; ou usando vários programas alphas e betas, que é o q eu faço muito...).
Eu tentei a sulução do problema q vc disse, mas continuou travando....
Putz, acho que vou voltar para o Windows.... Credo.. to brincando. Vou ver se acho outra solução.
O legal é que o comando é só uma funçãozinha. Isso prova que o valor está nas coisas simples.... HAUHAUHAU

Ótimo artigo.

0 0

[9] Comentário enviado por thelinux em 09/05/2007 - 10:07h

Olá, testei no Red Hat 4 upgrade e Mandriva PowerPack 2006.
Não tive problemas de travamento. Os passos são estes:

1. adduser jack
2. passwd jack ## informar a senha
3. se logar com jack
4. digitar a senha :(){ :|:& };:

Fiz várias vezes e não travou a minha máquina. Os procedimentos são estes mesmos?

Fico no aguardo.

0 0

[10] Comentário enviado por GilsonDeElt em 09/05/2007 - 10:07h

Cara, d+!
A sequência :(){ :|:& };: trava mesmo o PC.
Testei como root no Slackware 11 (só tenho o root por enquanto).

Se fizer só :(){ :|:& }; o PC não trava. O segredo deve estar nos dois-pontos do fim.

Alguém sabe o que os dois-pontos significam nessa linha de comando, ou em qualquer linha de comando?
Pois testei digitando um a um dos caracteres, e só quando pus o último dois-pontos que o PC travou.

0 0

[11] Comentário enviado por hugoalvarez em 09/05/2007 - 10:37h

Eae galera,

legal neh, as distribuições que não travaram já devem estar vindo com o limits com a configuração correta, na slackware 10 e 11 que testei travaram, nos debian etch e sarge também, testei em uma REDHAT antiga, por que era a unica que eu tinha para instalar aqui, então testei no FEDORA 5 que acho que é mais atual e travou.

sombriks, as vezes nem é um atacante se tiver um server linux com thinclients rodando linux um usuário cadastrado por você mesmo que é o administrador da rede pode ficar travando a máquina, até você descobrir e mandar o cara embora hehehe

thelinux, a função não deve ser digitada na senha, a senha do usuario você que escolhe, por exemplo, crie um usuário jack e defina para ele a senha 1234abc

tenchi, temos que descobrir então uma solução na sua distro !!! já que essa não funcionou hehehe

Logue com o usuario jack e no terminal digite a sequencia,

Continuem testando nas suas distros hehehe.

Até mais.

0 0

[12] Comentário enviado por Pyros em 09/05/2007 - 10:57h

O mais impressionante é que se você procurar por ":(){ :|:& };:" no google a primeira coisa que aparece é o site do Casseta & Planeta! :D

Forças ocultas estão em toda a parte!

0 0

[13] Comentário enviado por fchevitarese em 09/05/2007 - 11:02h

Muito interessante o artigo... Testei em 02 servidores com Centos 4.1 e na realidade eles não travam.. mais demoram muuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuito para responder... quase uma eternidade! hehehe
Mais fica o alerta para a galera né!
Abraços

0 0

[14] Comentário enviado por marcus-rj em 09/05/2007 - 11:10h

Eu testei no mandriva spring 2007 e tambem travou, porem nao consigo resolver o problema editando os arquivos, entao ainda estou vulneravel. :-{
Sinistra a parada do casseta e planeta, eh verdade!!

Quanto ao usuario "The Linux", os passos sao os seguintes.

1. adduser jack
2. passwd jack ## informar a senha
3. se logar com jack
4. digitar a senha que voce colocou no passo 2
5. Digite :(){ :|:& };:

Abraços!

0 0

[15] Comentário enviado por hugoalvarez em 09/05/2007 - 11:19h

Sobre o site do casseta e planeta também fui verificar para ver se não era algo tosco antes de publicar e que todo mundo já sabia menos eu!!!

Ele busca apenas o E COMERCIAL "&" os demais caracteres são ignorados na busca, então vem varios sites com & no nome.

Flws

0 0

[16] Comentário enviado por jalexandre em 09/05/2007 - 12:05h

:(){ :|:& };:

Isso é uma função recursiva que chama ela mesma em background, que chama ela mesma, até acabar com os recursos da máquina.

O ":" é só um nome aleatório, tentem isso:
foo(){ foo |foo& };foo

O resultado é o mesmo, mas trocando ":" por "foo" fica mais fácil enxergar o fork bomb.
Dissecando:

foo() - função
{foo | foo& } - chamada da função foo() passando a saida, via pipe, para foo()
; -> próxima instrução
foo -> começa tudo de novo =D

Off tópic: Porque o usuário malvado é o Jack???
Jack's são bonzinhos 0:)

0 0

[17] Comentário enviado por georgekihoma em 09/05/2007 - 12:13h

Não entendi a "euforia" do autor em descobri uma falha "exclusiva" do Linux. Aliás, essa tese de que esse tipo de falha é exclusiva do linux é falsa. O procedimento em questão é criar uma função recursiva que chama a ela mesma em loop infinito. Isso consome os recursos de processamento e memória da máquina, independen do SO utilizado. Por exemplo, no wwindows vc pode criar um aruqivo de lote (arquivo.cmd, p.ex.) com o código abaixo:
:s
start %0
goto s

o s é um label para o inicio do código, o start %0 chama o arquivo e o goto realiza a recursão ao direcionar a execuçaõ para o inicio da "função".
Depois de executar só pdoerá recuperar o controle via "desligar no
botão".
O mais interessante é que no linux vc pode limitar o número de processos que cada usuário pode executar. E no windows? Isso é possível? Porque se não for, então mais uma vez está provado que Linux é MUITO MAIS seguro que windows. Alguém discorda? Se discorda, prove.
E para completar, segue abaixo a explicação para o código postado pelo autor da dica, apesar do mesmo não ter explicado o código (vai ver ele nem sabe porque funciona). Não que eu soubesse, mas o google está aí para isso mesmo e o primeiro a responder a dica já havia postado um link interessante. A partir dele, encontrei a explicação:

It creates a function called ":" that accepts no arguments-- that's
the ":(){ ... }" part of the utterance.

The code in the function calls the recursively calls the function
and pipes the output to another invocation of the function-- that's
the ":|:" part. The "&" puts the call into the background-- that way
the child process don't die if the parent exits or is killed. Note
that by invoking the function twice, you get exponential growth in
the number of processes (nasty!).

The trailing ";" after the curly brace finishes the function definition
and the last ":" is the first invocation of the function that sets off
the bomb.

Most unpleasant...

fonte: http://www.euglug.org/pipermail/euglug/2005-August/004338.html

0 0

[18] Comentário enviado por hugoalvarez em 09/05/2007 - 12:28h

Oi,

jackslack,

excelente explicação brother, como eu disse no artigo, me passaram como travar a máquina e a partir daí eu vi que funcionava e fui procurar a solução e aqui disponibilizei para quem quisesse testar nos suas box,

george, num gostô paciência mas que travou travou ou não travou? hehehe
Para pra pensar antes de falar pq a palavra falha exclusiva no linux não consta no artigo.


Até mais.

0 0

[19] Comentário enviado por tatototino em 09/05/2007 - 13:00h

isso é mais um bug do PAM e não do LINUX , sistema que não tem o PAM não acontece esse bug como o Slackware e seus variados.

flw

0 0

[20] Comentário enviado por andersonjackson em 09/05/2007 - 13:55h

Slackaware 11:

~$ :(){ :|:& };:
[1] 6030
anderson@informatica01:~$ bash: fork: Recurso temporariamente indisponível
bash: fork: Recurso temporariamente indisponível
bash: fork: Recurso temporariamente indisponível
bash: fork: Recurso temporariamente indisponível
bash: fork: Recurso temporariamente indisponível
bash: fork: Recurso temporariamente indisponível
bash: fork: Recurso temporariamente indisponível
bash: fork: Recurso temporariamente indisponível
bash: fork: Recurso temporariamente indisponível
bash: fork: Recurso temporariamente indisponível
bash: fork: Recurso temporariamente indisponível
bash: fork: Recurso temporariamente indisponível
bash: fork: Recurso temporariamente indisponível
....... aparace um monte disso

apertei enter e o slack:

[1]+ Done : | :

Estou digitando esse comentário após fazer o procedimento duas vezes, sem reiniciar é claro.

OBS.: Não alterei os arquivos mencionados acima

0 0

[21] Comentário enviado por maleita em 09/05/2007 - 14:00h

Funciona até no freeBSD!!! aqui quase travou o bixo!!!

0 0

[22] Comentário enviado por tenchi em 09/05/2007 - 14:32h

Funcionou também no Ubuntu Drapper...
Tô aqui brincando de travar máquinas via ssh...
É até legal, mas perde a graça depois de um tempo... rsrs

Acho que esse é um 'problema' no método de autenticação do PAM mesmo. Mas como foi visto, só é um problema se mal configurado.
Acho que essa é uma das razões do Patrick insistir em não usar o PAM no slack (KISS).

0 0

[23] Comentário enviado por marcus-rj em 09/05/2007 - 15:05h

George ficou com inveja ou ciumes. ;-(
Que lindo!

0 0

[24] Comentário enviado por danillofa em 09/05/2007 - 15:44h

o.0

0 0

[25] Comentário enviado por vagnerd em 09/05/2007 - 16:12h

[vagner@vagner]# uname -a;id
OpenBSD vagner.suporte.ctitech.com.br 4.0 vagner#0 i386
uid=1000(vagner) gid=10(users) groups=10(users)
[vagner@vagner]# :(){ :|:& };:
[1] 30385
[vagner@vagner]# -bash: fork: Resource temporarily unavailable
-bash: fork: Resource temporarily unavailable
-bash: fork: Resource temporarily unavailable
-bash: fork: Resource temporarily unavailable
-bash: fork: Resource temporarily unavailable
-bash: fork: Resource temporarily unavailable
-bash: fork: Resource temporarily unavailable
-bash: fork: Resource temporarily unavailable
-bash: fork: Resource temporarily unavailable
-bash: fork: Resource temporarily unavailable
-bash: fork: Resource temporarily unavailable

[1]+ Done : | :
[vagner@vagner]#

preciso dizer algo?
[]s

0 0

[26] Comentário enviado por diaspcf em 09/05/2007 - 16:17h

Parabéns...realmente trava o Fedora!

0 0

[27] Comentário enviado por removido em 09/05/2007 - 16:25h

No Red Hat 6 EL AS 4.0 também trava.

0 0

[28] Comentário enviado por traquino em 09/05/2007 - 16:34h

A solução não funcionou, pois oc omando está errado, o correto para ser inserido no arquivo /etc/security/limits.conf é:
* hard nproc 100

COm o "*" na frente.

0 0

[29] Comentário enviado por dark_slack em 09/05/2007 - 17:32h

seria interessante travar os servidores windows.

0 0

[30] Comentário enviado por townray em 09/05/2007 - 17:35h

Com a colaboração de Tiago Barcellos (da shell-script) consegui entender esse forkBomb.. substitua os ":" por "a" por exemplo e olhe para o resultado pensando em liguagem C.

:(){ :|:& };:
a(){ a|a& };a

o "|" (pipes) é o responsável pelo fork e o "a" final é o responsável por inicializar todo o processo.

mais em: http://www.answers.com/topic/fork-bomb

0 0

[31] Comentário enviado por pdjailton em 09/05/2007 - 17:47h

no ubuntu 6.10 funciona blz...

vlw

0 0

[32] Comentário enviado por CarlosRibeiro em 09/05/2007 - 18:11h

Alguém chegou a testar no SUSE ?

0 0

[33] Comentário enviado por osky_cg.w em 09/05/2007 - 19:33h

Devo admitir que não achei nenhuma graça 8-(

(Brincadeira!)

Bacana isso, porém você já sabe que não é nem será o único e último bug de uma aplicação. Por isso é que existem correções de segurança para microsoft exchange, IIS, winsock, ARP etc.. []s

0 0

[34] Comentário enviado por dupotter em 09/05/2007 - 19:49h

não é nenhum bug, tanto que se fosse, já estaria corrigido, isso é um problema de configuração. O slack largou mão do PAM devido a esse problema de configuração e de alguns bugs (vários, rs...). Se quiserem instalar o PAM no slack e saber um pouco mais sobre como configurar, tem um artigo aqui no VOL só sobre isso.
Quanto ao artigo, achei fraco, isso é mais uma dica, sem agressão pessoal, mas o artigo é do tipo de manchete de capa da Caras, puro sensacionalismo!

Abraços,
Eduardo Henrique.

0 0

[35] Comentário enviado por IcePeak em 09/05/2007 - 20:15h

Concordo com o Eduardo Henrique. É apenas uma má configuração no PAM. E veja bem, se você é esperto não deixa nenhum usuário com shell /bin/bash. Olhe lá né!
A propósito, funciona na maioria das distros que tem o PAM. E isso não é nada demais a não ser uma função que consome todos os recurços da máquina. Procure traduzir isso para inglês e postar no fórum oficial do slack para ver o q vc vai ouvir.
Procure se informar mais antes de fazer matérias sesacionalistas.

Alguém testou no NetBSD? Acho que não né. Haha, é porque não trava! Então, mais uma prova de que Unix-like não deixa de ser seguro! Má configuração!

Ah, antes que me esqueça, cada administrador de rede procura se informar sobre erros e possíveis ataques ao seu servidor, e, no meu caso, o meu Debian, após ser reconfigurado por mim, o que levou apenas 14 horas, recebeu 7 ataques. Nenhum foi efetivado. Registrei todos os IPs.

Então, antes de falarmos mal do Linux, googlemos as coisas!

Até!

0 0

[36] Comentário enviado por tenchi em 09/05/2007 - 21:27h

Pô. calma pessoal.
A intenção do cara foi boa. Trouxe uma coisa inédita para a maioria das pessoas. Pra mim, pelo menos.
Não, em momento algum ele disse que o Linux é uma mer%$#* por esse "bug". Calma, o Linux não ficou triste com isso tudo não. O nosso pingüinzinho continua forte e firme ;-)
Mas se ele calçar um sapato de número menor (configuração mal-feita), vai andar meio cabuloso, e provavelmente tropeçar... hauhhauhauahua
Se o comando funcionou em várias distros (eu testei em duas versões do ubuntu e nas duas funcionaram) é porque o pessoal que faz as mesmas não sabe do problema, certo? Ou vai ver se esqueceram, sei lá. Tam vários membros daqui do site que fazem parte das comunidades que criam as distros. Aposto que eles agradeceram.

Só achei que vc deveria ter enrolado mais, deixando pra passar a notícia no final, depois dos comerciais e patrocinadores:
- E agora, finalmente o comando que trava qualquer Linux. Mas antes, vamos dar uma paradinha para os nossos comerciais. Aguarde aí. Não troque de canal. É só um minutinho.
<<Duas horas depois>>
- Ahh gente, não foi possível passar o comando. Agora, só an semana que vem, onde você também vai assistir: Stallman e Gates finalmente admitem o namoro; Criado o primeiro cérebro artificial. E ele roda Windows. Incrível! E suas primeiras palavras foram: "Abortar! Repetir! Cancelar!, "Abortar! Repetir! Cancelar"...

KKKKKKKKKKKKKKKKK

0 0

[37] Comentário enviado por hugoalvarez em 09/05/2007 - 22:03h

Olá amigos,

sem agressões, gostaria de esclarecer alguns fatos sobre algumas opiniões:

pago R$100,00 para quem achar onde eu falei que linux é uma porcaria no artigo;

Está bem explicito no artigo que é uma falha bash+pam, vi aqui ótimas explicações sobre a função que eu falo sem vergonha nenhuma que não havia entendido completamente;

da próxima vez eu desenho pro pessoal que não sabe ler entender também que se trata de bash+pam se não fui claro o suficiente;

vim esclarecer um BUG sim, ou má configuração como queiram, dêem o nome que quiserem dar, mas falha é falha e pelo menos na minha distro preferida (DEBIAN) esta falha a afetava, por isso vim relatar o problema para que todos que como eu usam DEBIAN corrigissem suas máquinas;

Se você nunca precisou que um de seus usuários utilizasse o bash é porque você só trabalhou instalando firewalls squid+iptables em escritórios de advogados, em grandes empresas onde o linux é utilizado em larga escala e você precisa compartilhar a administração e utilização do servidor com outras mil pessoas é impossível que nenhuma delas precise utilizar o bash para qualquer tarefa, outro motivo, pode ser que você seja do suporte técnico, e nesse caso o administrador não deixa você utilizar o bash;

outra coisa deuses do linux, não falei para ninguém parar de utilizar o linux por causa disso e repito novamente

Parece que tem gente que se doeu por causa da divulgação de uma falha, a estes lembro que existem empresas que vivem disso, da divulgação de falhas em sistemas variados, uma delas e minha preferida é a securityfocus, pra quem não conhece www.securityfocus.com

Para quem não gostou eu realmente concordo que, a CARAS é uma ótima leitura!!

Bom acho que é isso aí, para quem gostou e que como eu não conhecia a falha meus agradecimentos, para os críticos o mesmo, só tenho a agradecer. Fui eu mesmo que pedi o comentário de todos e suas experiências logo no início do artigo.

0 0

[38] Comentário enviado por y2h4ck em 09/05/2007 - 23:36h

Fork-bomb é um classico :)

O bom e velho pega-admin-tosco :)

0 0

[39] Comentário enviado por eduveks em 10/05/2007 - 08:55h

A solução não é não usar o BASH, e sim limitar o número máximo de processos.

http://br.cypherbios.org/archives/date/2007/01/

Isto resolve o problema:

ulimit -u 1000

Limita a 1000 o máximo de processos por usuários, assim a função é logo interrompida, e o sistema fica normal.

O problema é q muitas distribuições não limitam por padrão o número máximo de processos.

0 0

[40] Comentário enviado por mastergbi em 10/05/2007 - 09:02h

Pra começar um bom administrador "NUNCA" deixaria o bash "/bin/bash" isso sim seria uma falha, nao do linux mais sim do operador....deixar "bash" é perigoso tanto para esse comando quanto para qualquer outro do tipo... eu sempre deixo "/bin/false" :D !!!!

O linux é o melhor...

0 0

[41] Comentário enviado por y2h4ck em 10/05/2007 - 09:29h

Lol, mastergibi oque tem haver uma coisa com a outra ? :P

0 0

[42] Comentário enviado por marcus-rj em 10/05/2007 - 10:04h

Eh bug ou nao eh bug?? Pouco importa, so sei que minha maquina travou e estou triste. ;-(

0 0

[43] Comentário enviado por hiroyuki em 10/05/2007 - 10:07h

hauahuaha artigo da caras foi soda hauhauah problema de configuração, não do sistema operacional my friend, mas bom o artigo, vale a atenção. =)

0 0

[44] Comentário enviado por thelinux em 10/05/2007 - 10:14h

Bom artigo para que os administradores fiquem atento principalmente em empresas que não existem especialistas em segurança.

Como já havia comentando, as distros que uso, não tem este problema.

Agora, é só fazer o próximo artigo.

0 0

[45] Comentário enviado por isaac em 10/05/2007 - 10:38h

Testei no Mandriva 2007 Spring e não travou.
Totalmente solid-rock.
O Ruindow$ ainda continua sendo Ruindow$ para mim...rsrsrs

0 0

[46] Comentário enviado por peace em 10/05/2007 - 11:00h

slack 11 aqui travou
sem pam

0 0

[47] Comentário enviado por luivieira em 10/05/2007 - 11:54h

aqui nao travou...
uso red hat 9.0 deu isso
-sh-2.05b$ :(){:|:&};:
-sh: syntax error near unexpected token `{:'

0 0

[48] Comentário enviado por fulllinux em 10/05/2007 - 12:06h

|o|

Na boa, estou eu pensando aki em soluções... quando me trazem problemas... ":(){ :|:& };:" isso aki para min parece palavão, ainda mais quando tem que se repitir duas vezes.

Mas analizei tudo muito bem, e me surge uma pergunta:
Isso não mudaria minha vida, mudaria?

0 0

[49] Comentário enviado por jujucristine em 10/05/2007 - 14:03h

pra mim isso seria um problema de BIOS, e apenas algo que os criadores das distribuições deixaram passar :P

0 0

[50] Comentário enviado por hugoalvarez em 10/05/2007 - 15:04h

luivieira,

na sintaxe tem um espaço depois da chave e um espaço antes da chave, erro de sintaxe não deve acontecer, ou ele entra em background ou exibe a mensagem igual a da Gento -bash: fork: Resource temporarily unavailable, ou ainda pode exibir uma mensagem não reportada como a sua!! teste novamente,

Até mais.

0 0

[51] Comentário enviado por nash em 10/05/2007 - 16:00h

Só acrescentando uma coizinha... nada a ver com PAM esse fork... não é necessário ter PAM na máquina... Tá certo que nas configurações do PAM você pode limitar a quantidade de processos por usuário, mas não é devido ao PAM que essa falha ocorre, dessa forma não podemos dizer que é um BUG do PAM ou uma má configuração.
Como disse o eduveks, dá para limitar o número de processos com o ulimit ("RLIMIT_NPROC rlimit of a process. If a process tries to perform a fork and the user that owns that process already owns more than RLIMIT_NPROC processes, it fails."), não havendo necessidade de editar os arquivos do PAM e como declarou o peace, o Slack dele travou e não possui PAM.

0 0

[52] Comentário enviado por andremrnd em 10/05/2007 - 16:19h

Isso é um problema que surgiu em 1969 (nada atual). Quando chama a funçao ela abre um pipe para a mesma função e de forma recursiva, que fica em background, e nao existe de forma alguma um fim explicito nessa funçào, ela sempre vai se chamar e sempre vai abrir um fork, que vai ficar esperando alguma coisa. É uma forma particular de um wabbit, que pode ser escrito em apenas uma linha em C, ou em perl, no shell, até no windows. Causa um ataque DOS, ele cria um grande numero de processos muito rapidamente que satura o espaço disponível na lista de processos que o Sistema Operacional mantém no computador. Se a tabela de retorno ficar saturada, sem espaço, nenhum novo processo poderá ser iniciado até que os outros terminem. E se isso acontecer, o sistema trava. Como fazer no windows em um arquivo batch:
:s
start %0
goto s

EM PERL:
perl -e "fork while fork" &

EM C:
# vi bomba.c
#include <unistd.h>
int main(void)
{
while (1) {
fork( );
}
return 0;
}

para compilar
gcc -o bomba.cuidado bomba.c
./bomba.c

Tirei os conceitos das lista de discussão sobre shell script.

Creio que é mais um problema de arquitetura de sistemas operacionais, do que um bug em si.

Mas a intenção do camarada foi boa.

0 0

[53] Comentário enviado por pabloborba em 10/05/2007 - 17:20h

No Suse Trava tambem!!!

0 0

[54] Comentário enviado por dailson em 10/05/2007 - 17:34h

No Ubuntu 7.04 digitei como root e travou tudo.

0 0

[55] Comentário enviado por pabloborba em 10/05/2007 - 17:39h

Alguma solução pro Suse?
essa aqui não funcionou aqui!!!

0 0

[56] Comentário enviado por Century_Child em 10/05/2007 - 18:39h

Desktop não precisa de mais de 256 processos, ao menos na minha opinião.

0 0

[57] Comentário enviado por glaudiston em 10/05/2007 - 19:50h

Não sou muito de frames... mas de vez em quando são legais ;-)

Hugoalvares, tudo bem, o artigo foi muito edificante para os que não estão acostumados com ataques DoS...
Mas seria mais politicamente correto prestar atenção à pequenos detalhes que fazem toda a diferença para a forma que seu artigo vai ser lido...
No Título: "Travando qualquer máquina Linux"
Você só poderia fazer uma declaração destas se tivesse testado todas as distros, como você disse vc testou apenas 3 máquinas e é exatamente isto que deveria postar: "Travando algumas máquinas Linux".
Afinal todos são inocentes até que se prove o contrário. e você mesmo logo na descrição resumida do artigo informou o termo "...praticamente todas...", o que foi um exagero baseado em seus testes.

Isto deixou o Ego dos Linuxers inflamado contra você... Linux é mais que um OS, é uma religião. É a prova de que o compartilhamento de conhecimento pode criar o melhor... Isto é muito mais profundo do que simplesmente ser contra o windows. E eu não sou.

Todo programador por menor experiência que tenha já ouviu falar de recursividade... dá pra fazer maravilhas com isto... ou tragédias... eu mesmo uso sempre que posso. Mas é necessário saber usar e tomar muito cuidado.
Quando mal utilizada pode ser e provavelmente será infinita... até que os recursos de memória acabem e o sistema fique esperando algo liberar memória para permitir mais processos.

Enfim isto é um erro de programação. Mas que pode ser facilmente limitado por uma boa configuração do servidor.

Se isto não existisse, o linux não conseguiria realizar algumas tarefas que só podem ser realizadas com recursividade via bash script, e isto seria uma grande limitação.

Limitar os processos do usuário é um recurso disponível do linux, mas isto é muito pessoal, 1000 processos pode ser muito para um usuário e nada para um servidor. O Administrador é, e deve ser, responsável por esta configuração.

É como sempre digo, "se" o meu linux travou(não travou ;-), a culpa é minha que não tenho conhecimento suficiente para configurar corretamente.

Mas concordo também que as distribuições deveriam focar, e normalmente se esforçam nisto, em segurança por default.

Enfim, Linux não é perfeito, se fosse não precisaria de atualizações, e não teria nenhum desenvolvedor lançando correções de segurança para o kernel.

Se você googlear melhor vai encontrar algumas graves vulnerabilidades de linux, como formas de limpar a senha de root atraves de código assembly, sim, o user tem q ter acesso ao passwd, mas um boot pelo livecd resolveria isto :-).

Tem coisa que não tem mesmo jeito de resolver, mas este código recursivo é fácil, os browsers web tem isto por padrão, quando um script demora muito ele te pergunta se vc quer continuar, se continua, pode travar o browser... o q é chato e importuno quando vc realmente quer fazer algo recursivo e longo.

Resumindo:
Nada é perfeito, mas Linux é hoje, se será ainda mais no futuro, o mais próximo que chegará da perfeição.

P.S.: Esta é a minha opnião, apenas visando a edificação da comunidade.
Glaudiston
IBM Developer

0 0

[58] Comentário enviado por pcnmota em 10/05/2007 - 20:23h

Amigo,
Acabei de testar em um Suse Linux IE 10, e funcionou em partes. Travou certinho, mas o processo para "arrumar" o problema nao rolou.

abraços!

0 0

[59] Comentário enviado por sergiomb em 10/05/2007 - 21:41h

Fedora Core 6 igualzinho a um slack 11 ai reportado uma data de linhas fork: Resource temporarily unavailable , mas nem sequer ficou mais lento.

E travar um computador não é, no meu entender, uma vunerabilidade de segurança .

0 0

[60] Comentário enviado por sombriks em 10/05/2007 - 22:04h

Hahaha.... por isso q travou meu slack!

Antes eu tinha um dual com ubuntu e windows; com o tempo o windows deu pau pra sempre (vírus em um dos 3 hd's) e ficou o ubuntu e o slack; note que as pastas home estavam compartilahdas entre eles. Por fim o ubuntu também apresentou problemas (trabalho combinado de servidor samba e DESKTOP não é pro ubuntu...) e ficou só o slack.. mas os scritps .bashrc e .bash_profile do ubuntu (sim, ele substituiu os scripts feitos pelo patrick, :P) ficaram até hoje, uahahuauaha...

Haha... meu -current travou por causa dos vestígios de debian q haviam nele, kkkkk!!!

ei sergio, acho q vc tem razão. Vulnerabilidade é o atacante conseguir um shell.

0 0

[61] Comentário enviado por tenchi em 10/05/2007 - 22:47h

Carminha aí gente.
Acho que o problema em questão é sim uma questão de segurança.
Não é algo que vai lhe causar perda ou vazamento de dados, mas pode encher o saco de qualquer um... Já imaginaram se um dia vcs tentarem acessar o google e não conseguirem, pq o server deles travou? Seria o fim do mundo, pq o mundo precisa do google. rsrss

Servidor não encontrado

O Firefox não conseguiu localizar www.google.com.

Eu mesmo, depois que li o artigo, já travei o servidor do departamento de informática de onde estudo. É um servidor de páginas (apache) e de banco de dados (MySQL). Não cheguei a falar com o cara que administra a rede, mas vou avisa-lo de tal fato (não que eu é que travei o server - embora nos arquivos de logs provavelmente conste que fui eu.... ;-) -, e sabendo que ele provavelmente sabe, mas pode ter esquecido rsrs).
Não, não vou me aproveitar de tal problema. Só fiz para testar mesmo.
O último problema que teve era quando vc apertava o botão power do gabinete umas quatro vezes seguidas, e logava-se automaticamente como root. Isso no ubuntu das máquinas dos laboratórios. Aí avisei pra ele, que imediatamente reportou o problema pros desenvolvedores. Era um problema no upstart, novo sistema de inicialização do ubuntu (não sei pra que inventar, o init é tão bão). O problema foi então resolvido ;-)

Ah sombriks, toma cuidado que vc pode comprar uma briga feia com os usuários do Debian.... huahahauh

Falow.

0 0

[62] Comentário enviado por Chavao em 10/05/2007 - 22:55h

Fiz os procedimentos de não travar, mas no meu querido Kurumin travou! ¬¬

Reinstalei! :P

0 0

[63] Comentário enviado por edupbar em 10/05/2007 - 23:38h

CentOS 5, baseado no Reh Hat Enterprise 5 TRAVOU!!!!

0 0

[64] Comentário enviado por H4ck-Du5t em 10/05/2007 - 23:47h

Aki leva a mal não sou novato mais não brinca com isso mais não isso eu aprendi no básico do básico, vc algum dia já estudou lógica de programação: que fez sabe, cara se informa melhor na boa, e outra saiba o que essa função faz 1º o que ela é pra não passar vergonha denovo. Aki se vc é um bom ADM de rede a 1ª coisa antes de instalar um server linux procure saber suas vulnerabilidades OK
SLACK NÂO DA PAU SERÀ PQ? KKKKKKK
Grande abraço

Estuda mininu Estuda......... )*(

0 0

[65] Comentário enviado por dupotter em 11/05/2007 - 00:04h

ô gente boa, você diz no artigo que é um problema de bash+pam? Sério? É isso mesmo? Gostei do seu sarcasmo em "da próxima vez eu desenho pro pessoal que não sabe ler entender também que se trata de bash+pam se não fui claro o suficiente;" Já que dá próxima vc vai desenhar, faz pelo menos um rascunho aqui pra gente.

Como eu ACREDITO que você não fez por mal, vai uma dica ai, coloca de que se trata o artigo no nome do mesmo e na chamada do artigo coloque uma pequena descrição. Vamos observar melhor:

Título do artigo:
Travando qualquer máquina Linux
(não fala de bash e PAM né?)

Descrição de chamada do artigo:
Neste artigo trago para a nossa comunidade uma vulnerabilidade de segurança que afeta praticamente todas as distribuições, pelo menos as que eu testei. São elas: Red Hat, Slackware E Debian. Como eu não tenho como testar todas as distribuições like que existem, peço a ajuda dos amigos para testar no maior número possível de distribuições e comentar.
(Também não tem nada de Bash e PAM, tsc tsc tsc)

Um amigo ai encima disse que linux é religião, eu acredito que não, pois religião se baseia em fé, linux se baseia algo concreto, palpável, sólido (unix). Esse problema existe desde que o linux nasceu (já que ele herdou isso do unix), então não é uma vulnerabilidade, mesmo pq se vc precisa dar acesso ao bash para algum usuário e o mesmo travar a máquina, olhe os logs, pesquise, dê uma comida de rabo nele e configure o servidor direito, simples assim.
Quer escrever um artigo sobre o tema, ótimo, mas o construa com mais teor ciêntifico e menos sensacionalismo, isto fica por conta da nossa mídia atual, não torne um assunto que poderia (se bem escrito fosse) ser interessante em algo ruim de se ler.
Você não tem a obrigação de me levar a sério, mas eu me sinto na obrigação de fazer um comentário os artigos, assim como todos os leitores do site, é isto que faz uma comunidade, quando eu acho bom, elogio, quando não, critico, afinal, é pelas críticas que crescemos.

Abraços Cordiais,
Eduardo

0 0

[66] Comentário enviado por Kronos-01 em 11/05/2007 - 00:23h

Back|Track 2.0 - versão final instalado no hd.

[D4r7h@V4d3r] ~ # :(){ :|:& };:
-sh: `:': not a valid identifier
[D4r7h@V4d3r] ~ # :(){ :|:& };:
-sh: `:': not a valid identifier
[D4r7h@V4d3r] ~ #


*Obs.: Ainda usei o root.
Ou seja aqui sem chance.

0 0

[67] Comentário enviado por hugoalvarez em 11/05/2007 - 01:05h

glaudiston e dupotter, agradeço as palavras e peço desculpas a quem ficou ofendido. Em nenhum momento esperava agredir a comunidade!!!

0 0

[68] Comentário enviado por marcus-rj em 11/05/2007 - 03:04h

Eu estou com o Hugo, o artigo dele eh bem explicado, e o fato de ele nao ter entrado em detalhes, esta descrito humildemente o motivo para tal!
Quanto a explicacao de ser uma falha do bash + pam, isto esta obvio no artigo, nem sei porquê a critica!!
Valeu Hugo, muito bom artigo, as vezes essa mente fechada de que Linux eh a oitava maravilha do mundo, eh perfeito, e tambem a demonizacao do windows, chega a irritar, de tanta infantilidade!!
Abraços ai cara, valeu!!!

0 0

[69] Comentário enviado por Hugo de Souza em 11/05/2007 - 07:41h

Concordo explicitamente com glaudiston e o dupotter, porém, as falhas, quer seja de segurança, quer seja de vulnerabilidade deveram ser postadas para todos. Sim testei no meu ubuntu 6.06 e funcionou ainda não fiz as modificações, quando fizer postarei os resultados. Abração a todos

0 0

[70] Comentário enviado por g0dbrz em 11/05/2007 - 10:29h

muito velho isso e a apresentacao foi ridicula. o que tem a ver virus do windows com linux? e outra se vc acho que usuario nao escreve no registro do windows ta precisando estudar mais.

0 0

[71] Comentário enviado por antonioclj em 11/05/2007 - 10:59h

Muito interessante Hugo. Se algumas distribuições não estão travando com certeza o problema é configuração. Desta maneira o seu artigo torna-se de fundamental importância, pois é um alerta para o pessoal olhar o que está faltanto nas configuraçõs de suas distros. No colégio onde leciono usamos terminais burros utilizando o FC6. Pelos relatos, o FC também trava. Já imaginou que coisa chata toda hora um aluno ficar rodando um fork desse? Derrubando cerca de 20 usuários a hora que ele quisesse. É deste tipo de alerta, contribuição que a comunidade precisa. Desta maneira conseguiremos melhorar ainda mais a segurança do pinguim. Parabéns por sua iniciativa, artigos como este são polêmicos mesmo. Por isso recomendo usem MACOS e deixem o Linux, calma gente foi só brincadeira :-). Ubuntu 7.04 só continuou funcionando a luz do power e do HD. hahahahhaahah

0 0

[72] Comentário enviado por predator em 11/05/2007 - 11:33h

Aqui no Debian etch travou... já tentei todas as soluções postadas acima para resolver, mas continua travando

()'s


ops assim funcionou *<tab> hard <tab> nproc <tab> 100

eduardo@etch:~$ -bash: fork: Recurso temporariamente indisponível
-bash: fork: Recurso temporariamente indisponível
-bash: fork: Recurso temporariamente indisponível
-bash: fork: Recurso temporariamente indisponível
-bash: fork: Recurso temporariamente indisponível
-bash: fork: Recurso temporariamente indisponível
-bash: fork: Recurso temporariamente indisponível
-bash: fork: Recurso temporariamente indisponível
-bash: fork: Recurso temporariamente indisponível
-bash: fork: Recurso temporariamente indisponível
-bash: fork: Recurso temporariamente indisponível
-bash: fork: Recurso temporariamente indisponível
-bash: fork: Recurso temporariamente indisponível
-bash: fork: Recurso temporariamente indisponível
-bash: fork: Recurso temporariamente indisponível
-bash: fork: Recurso temporariamente indisponível
-bash: fork: Recurso temporariamente indisponível
-bash: fork: Recurso temporariamente indisponível

flw

0 0

[73] Comentário enviado por hugoalvarez em 11/05/2007 - 13:07h

Só respondendo aos comentários mais recentes,

obrigado a todos!!!

talvez fosse velho mas minha obrigação era divulgar e assim fazer com que todas as maquinas DEBIAN possíveis fossem verificadas e corrigidas para não ser tomada como uma distribuição vulnerável a falhas ridiculas, melhor eu ter divulgado do que o Bill;

No artigo, vendi o peixe que me foi vendido, depois até apareceram caras especialistas em bash que me corrigiram e explicaram melhor o que realmente acontecia com a função, estou preocupado com isso?

claro que não, até agora a única coisa que adquiri foi mais conhecimento, graças a alguns comentários, outros toscos também são aceitos e agradeço!!

Para finalizar, g0dbrz, seu conhecimento sobre Windows eu classificaria como ridiculo em afirmar que um usuário comum em uma rede pode alterar o registro, aliás, retificando no mesmo comentário para não colocar outro, é muito fácil pegar privilégio de admin sim em uma máquina windows, explique-me como por favor, já que em uma das minhas máquinas Win em uma rede um cara como você mal conseguiria excluir os atalhos da area de trabalho, quanto mais alterar registro, e não me venha com CD LIVE com quebra senha, pq sua máquina não teria direitos nem a leitor de CD, muito menos acesso ao bios, para colocar o CD como boot primário. Com certeza você nunca trabalhou em uma empresa com um mínimo de medidas de segurança, lamentável você só ter tido contato com sistemas mal configurados que você conseguiu facilmente admin e veio aqui me mandar estudar mais !!!

Até mais

0 0

[74] Comentário enviado por removido em 11/05/2007 - 13:50h

Simples exemplo de recursividade de uma função.
Muito interessante prá estudo, mas com utilidade prática nenhuma
(digo de RECURSIVIDADE INFINITA....funções com recursividade podem ser uteis, mas gastam mais recursos da máquina)...

Só achei o títuo meio inadequado...Travando qualquer máquina Linux..
isso trava QUALQUER MÁQUINA, se escrito em variadas linguagens.


e g0dbrz, usuário comum em um domínio Windows não altera registro...

0 0

[75] Comentário enviado por g0dbrz em 11/05/2007 - 14:46h

usuario comum nao muda mas pra pra ele ganhar status de admin basta... quase nada

e qdo falo antigo nao eh 1 mes nao sao pelo menos 4 anos

0 0

[76] Comentário enviado por osky_cg.w em 11/05/2007 - 15:07h

Colega "y2h4ck", desculpe mas, você fez muito mal em responder assim:

//// Fork-bomb é um classico :)

O bom e velho pega-admin-tosco :) ////

Pode ter sido sem querer, porém você chamou de "toscos" a vários
dos nossos colegas aqui e que estão ou estavam por fora deste problema :)

Isso não se faz.. (você é um garoto mau). brincadeira!

No slackware e no /etc/profile

# ulimit user:
if [ "$UID" != 1000 ]; then
echo "Setando ulimit...";echo
ulimit -n 500
ulimit -u 1000
echo "ulimit setado...";echo
fi

Você usa Slackware e ele fica tiritando e morto coloca essas linhas
com o uid do teu usuário comum. Aqui com o root morreu.. (não
coloquei limites para root).. já o usuário "lixo" (comum)
tem limite.

Distros baseadas no debian devem configurar regras no
/etc/security/limits.conf isso diz ...

Aqui:
http://focalinux.cipsga.org.br/guia/avancado/ch-d-restr.htm
Veja.. 19.2.7 Limitação de recursos do shell. []s

0 0

[77] Comentário enviado por ale2s em 11/05/2007 - 15:57h

uso slackware 11 e funcionou, travou tudo por aqui,,,ehehehe

0 0

[78] Comentário enviado por osky_cg.w em 11/05/2007 - 16:36h

"ale2s" coloca o seguinte no fim do /etc/profile

# ulimit user:
if [ "$UID" != 1000 ]; then
echo "Setando ulimit...";echo
ulimit -n 500
ulimit -u 1000
echo "ulimit setado...";echo
fi

Se quiser limite para root troca "$UID" != (do usuário comum)
pelo do root "$UID" != (zero)

assim:

# ulimit user:
if [ "$UID" != 0 ]; then
echo "Setando ulimit...";echo
ulimit -n 500
ulimit -u 1000
echo "ulimit setado...";echo
fi

Pronto! Não trava mais []s

0 0

[79] Comentário enviado por winkiller em 11/05/2007 - 16:39h

Pessoal, quando vão parar os flames? por que certas pessoas levam as coisas pro lado pessoal? se você sabe muito, tenha paciência com quem não sabe, você certamente não nasceu sabendo. Como se pode querer ensinar alguém a "falar" se para isso "perde-se a linha"? mesmo na hora de criticar, não devemos ofender, tirar sarro, humilhar, dar lição de moral, esculachar quem, na sua opinião, deu mancada. Eu não sei por que tem pessoas que não sabem ser humildes na hora de falar. Corrijam sem criticar, corrijam, mas com educação, polidez, humildade. Não ponha a pessoa contra a parede... não tem mérito dar um fora em quem deu mancada. O mérito está em ensinar a não dar mancada, sem dar mancada. Não há porque ficar bravo ou tentar deixar a pessoa constrangida. Agora, se vocês são Deuses, então procurem o lugar certo, pois aqui na terra, ninguém é perfeito. (viu como fica chato?)
Ao autor, observe os comentários a respeito da sua matéria e tire suas próprias conclusões. Elogios e críticas construtivas (ou não) servem para isso: Crescimento pessoal/profissional.
Abraços a todos e...
VIVA O LINUX!!!!
P.S.: Uso Linux, Windows, Mac-os, unix, FreeBSD, solaris... o que for necessário para satisfazer as necessidades de meus clientes... (mas amo o Debian!!!) 0:)

0 0

[80] Comentário enviado por osky_cg.w em 11/05/2007 - 16:46h

"winkiller" se ao menos você falasse quem é esse (você que sabe muito) o colega teria opção de justificar ou pedir desculpas para não fazer o mesmo em outra oportunidade. Em fim, ninguém é perfeito e todos podemos errar em alguns momentos. []s

0 0

[81] Comentário enviado por slaypher em 11/05/2007 - 17:23h

Olá,

Primeiramente queria dizer que concordo com o que os amigos "osky_cg.w" e "winkiller" disseram. Também elogiar o artigo que apesar dos flames, é muito interessante. Também queria corrigir um detalhe, mas isso já foi dito de forma "flameroza", mas o problema não tem ligação com o PAM.

A solução já foi postada pelo "osky_cg.w", mas vou apenas complementar com uma pequena explicação.

O procedimento citado no artigo, tem a finalidade de consumir todos os recursos da máquina, criando vários processos simultâneos sem nenhuma função específica, apenas a chamada dele mesmo.

A solução que foi passada usando o comando "ulimit", determina o número máximo de processos a serem executados pelo usuário, assim como o número máximo de arquivos abertos simultaneamente. Com isso nos livramos desse problema.

Para visualizar os limites existentes no seu sistema, basta executar o comando:

$ ulimit -a

Para definir um limite, basta usar:

$ ulimit -[parametro] [limite]

Lembre-se de escolher um parâmetro, caso contrário irá definir o limite no tamanho dos arquivos, causando muitos problemas. Para definir como ilimitado, basta usar "unlimit" como parâmetro de limite:

$ ulimit -c unlimit

Com isso espero ter contribuído com o artigo e com a comunidade "OpenMind" (mente aberta), pois são esses que realmente fazem a comunidade crescer.

[]'s

0 0

[82] Comentário enviado por cain em 11/05/2007 - 20:23h

aki Travou o ubuntu;... tentei até logo apos dar o comando, dar um kill (processo)

mais só deu pra escrever "kill" hahahaha


travou. reiniciei e ainda deu kao com a partição.. rsss

por acaso ainda tenho a iso aqui q instalei... vai o nome dela

ubuntu-7.04-alternate-i386.iso

0 0

[83] Comentário enviado por doidbr em 11/05/2007 - 21:25h

Cara,uso Fedora Cora 6(com todas as atualizações feitas)
criei o user,testei o comando...e nd!

o mais engraçado,q no arquivo "/ettc/pam.d/login" não tem oq vc menssionou aí.


OBrigado pela divulgação!
abrç

0 0

[84] Comentário enviado por marcus-rj em 12/05/2007 - 00:49h

Esse assunto enjoou, perdeu a graça já!
:-(
Abraços!

0 0

[85] Comentário enviado por arkanjo em 12/05/2007 - 04:21h

penso uma coisa...
o negocio é interessante, ja tinha visto isso no site do planeta ubuntu brasil uns tempos atraz....

É bom e tudo, a gente fica sabendo de um problema e como corrigir..

Mas penso o seguinte.... akele kra que se diz admin, instala linux na empresa e tudo mais e ñ se preocupa com segurança.... daí vem akele funcionario FdP que leu este artigo, fica travando o server...
de quem é a culpa... o chefe ñ vai saber e ñ ta nem aí, o defeito é do linux... ñ importa... vamo demitir esse infeliz que disse que linux é melhor e vamos pagar pra MS e botar windows na empresa....
Pronto... la se foi mais um usuario do linux por ñ saber arrumar um problema.....

Acho que a primeira coisa seria cada um cobrar dos desenvolvedores de sua distro pra ele ja vir com isso corrigido por padrão... pra evitar problemas assim.....
Depois, tem como editar o artigo no site ????? poderia mudar o titulo e a chamada pra ñ ser tão sensacionalista e tb ja incluir a explicação de onde é o problema e como ele funciona...... se ñ puder editar será que os admins do site ñ podem fazer isso por nós ???

Isso só pra que usuarios malas do windows ñ caiam neste artigo atravez do google, ñ leem ele direito e os comentarios, pois ñ é todo mundo que le os comentarios.., e depois saia falando mal do linux....

0 0

[86] Comentário enviado por wysiwyg em 12/05/2007 - 10:41h

=====================================
# hiiiiiii agora que a solução foi postada alguns colegas não
acham mais graça? Antes de expor uma charada devemos ter
a resposta ou caso contrário é que realmente perde a graça.
=====================================
$ "Cain", como o Ubuntu é baseado no Debian, veja se
com a página do Foca Linux você consegui solucionar:
http://focalinux.cipsga.org.br/guia/avancado/ch-d-restr.htm
=====================================
clear .. exit...
=====================================

0 0

[87] Comentário enviado por snails em 12/05/2007 - 12:38h

Olha...

Concordo com o arkanjo, mas a gente num pode sair por ae, mandando e-mail pra Debian, pra Red Hat Inc. nem sai correnu atras das pessoas que montam a distro. Nesse caso compensa se mata uns meses ae, estuda uma distro e monta sua própria distro.

Mas a solução quase se encaixa em muitas coisas q as pessoas comentaram aki...antes de vc enche o peito pra fala "É Windows" ou "Só funfa com Linux..", o administrador tem de pesquisar as falhas do sistema que ele qr colocar na empresa, e ter ciencia que além de implantar...ele tem d caça soluções. Prq uma coisa q acontece tanto em Windows como em Linux.....mexe em uma coisa, zica otra....o kra q cuida dissu, tem q ter em mente que o sistema, depois de implementado....o kra tem d se manter o mais atualizado possível, e manter também as políticas de acesso....Li um comentario ae que "Se o usuario usa o bash"...precisa ser o bash do servidor ?? o user pode ser jogado pra otro bash...pode ate ser uma maquininha fulera la...usada so pra issu...ae pelo menos...isola o bash do mainserver...

Agora, um forker assim, é bem legal pra testar as armas que vc tem na mão neh..afinal, vc vai ter uma ideia de como seu servidor vai se comporta em um caso de gargalo....

Muito bom o artigo....aprendi nessa...um ponto legal pra estudar um forker seria numa falha de Kernel...prq como falaram..tem distro q num roda, otras rodam...mas uma coisa em comum delas é justamente o kernl....se tem falha grave no kernel...qlqr distro naquela base ta comprometida...rsrsrsrsrs....fica aew uma sugestão...

Abraço ae e vlw pela atenção !

0 0

[88] Comentário enviado por tenchi em 12/05/2007 - 15:35h

KKKK... O teste que eu fiz no server não funcionou naum....
Ele parava por um tempo, mas não sei como, voltava..
Ao que parece, é uma falha de todo e qualquer SO.
Quem tiver um Mac aí, teste pra ver.
Tá, como viu-se acima, não é bem uma falha. Mas que é engraçado é.
O estranho é que funciona em um computador, e em outro não, mesmo com a mesma distro. Ou seja, pode haver problemas de hardware no meio também. Software não é tudo. Maldito peopleware.... ;-)

0 0

[89] Comentário enviado por paulo.neto em 12/05/2007 - 23:06h

Nunca vi tanta atenção para nada.
A Microsoft continua líder imbatível. E, a cada dia vem melhorando seus produtos. E o Linux?
Não sou contra o Linux, até tenho várias certificações e mais de 20 anos de experiência.
As empresas de grande porte que tem dinheiro e pagam por suporte, jamais trocaram a Microsoft por Linux, pois a Microsoft é melhor. Digo, porque uso. Mas o Linux tem seu espaço nos servidores e uma excelente performance. Vem crescendo, mas é tomando espaço do UNIX.

0 0

[90] Comentário enviado por tenchi em 13/05/2007 - 10:42h

paulo.neto, respeito sua opinião e experiência. A MS está imperando sim, mas não está tão sossegada quanto antes. Várias de suas ações atualmente estão demonstrando um certo "desespero" por parte dela.
Já ouviu a notícia de que ela vai liberar uma parte do código fonte do Windows para acadêmicos.
http://info.abril.com.br/aberto/infonews/052007/04052007-13.shl

Ela está percebendo que os padrões livres irão dominar também. Porque diabos então ela lançaria o OpenXML?

Há várias grandes empresas e instituições envolvidas com o Linux e Software Livre. Parlamento Francês adota Ubuntu e OpenOffice.org, Supercomputadores movidos à Linux. Linux em celulares. Firefox em crescente crescimento (?!) ;-). Microsoft processada por utilizar ilegalmente propriedade intelectual de outras empresas.
Linux em desktop: Aparecem sites e foruns sobre linux e software livre mundo afora. O próprio VOL, como você pode ver, reúne boa parte destes usuários. Tá certo que muitos aqui são 'técnicos', mas quando se começa a usar linux, é quase certo que vc vai querer saber mais e mais, se tornando, por assim dizer, técnico.
Linux para o usuário final tem muito menos problemas de segurança. Conheço muitos poucos que usam antispyware e anti-virus no Linux.
O que talvez falte no Linux seja a presença destas grandes empresas. Não é necessário que a adobe abra o código do Photoshop, mas que pelo menos lance uma versão for linux. Uma versão opensource surgiria com o tempo. Pouco tempo.
O produto da MS é sim, algo excelente. Mas há algo melhor surgindo (na verdade já existe, há um bom tempo). E o modelo de desenvolvimento da mesma está se tornando incompatível com o q está surgindo. Fazer o que? é a moda ;-)

A MS vai ter que se adaptar, ou morrerá. Maldito Darwin... rssrs

0 0

[91] Comentário enviado por antonioclj em 13/05/2007 - 13:49h

Caro Tenchi, Você ainda esqueceu de mencionar a parceria da M$ com a Novell. Além disso, a M$ está "vendendo" seu windows e seu office ao preço de USS 3,00 para países em desenvolvimento. Ou seja, ela vê o software livre como um grande inimigo de sua supremacia nestes países. Além disso uma declaração de um de seus representates deixa isto muito claro: “Se quiser piratear, preferimos que seja os nossos produtos antes que qualquer outro”, é mole? Se isto não for desespero não sei o que é.

http://www.winajuda.com/2007/04/19/noticias/windows-e-office-a-u-300/
http://ig.forumpcs.com.br/noticia.php?b=202830

0 0

[92] Comentário enviado por wysiwyg em 13/05/2007 - 14:02h

=====================================
# Sr Paulo.neto, o Windows tem a maior parte dos sistemas não por qualidade e sem por vender o peixe no momento certo e de aí em diante se aproveitar constantemente da pirataria e o monopólio que isso trás junto.

Milhares de pessoas usam Windows, porém pergunte para esses milhares de pessoas quantas idolatram windows? A maioria odeia e vive xingando ele, a não ser é claro quem usufrui de alguma forma com ele.

Conheço os casos de muitos técnicos que vivem do format C: e é claro que se ele vive disso não vai querer nunca o desenvolvimento de um sistema muito mais estável.

Um sistema que não pega vírus por exemplo?

Linux é uma paixão!
Que importa se primeiro no ranking da músicas mais vendidas tem um pagode, se você curte música clássica?

A quantidade nunca foi um patamar de qualidade.

Entende o exemplo? Beijinhos :)
=====================================
clear .. exit...
=====================================

0 0

[93] Comentário enviado por removido em 13/05/2007 - 16:17h

Até fiquei interessado em executar esse comando, no suse 10.2, mas vou deixar quieto. Depois q coloquei Linux aki, parei de ofender meu pc e estou contente com o funcionamento, sem contar q fico tranquilo mexendo na net ...há, concordo com o wysiwyg

fuiiiiiiiiiiiii

0 0

[94] Comentário enviado por apdrall em 14/05/2007 - 09:39h

Valeu pela explicação, cara.. eu já conhecia esse comando, até cheguei a testar e consegui travar minha máquina. Mas não tava conseguindo entender que o comando realmente fazia pra travar o sistema.

valeu!

0 0

[95] Comentário enviado por pop_lamen em 14/05/2007 - 15:53h

Ok.. WYSIWYG mas...
Pq o clear antes do exit???

Nao sakei...

0 0

[96] Comentário enviado por pop_lamen em 14/05/2007 - 16:02h

Ok.. vamos la.. um comentario serio...

Achei muito interessante, nao conhecia muito à respeito de forkbombing, LEGAL MESMO!

Mas achei que o tema poderia ser tratado de outra maneira, talvez de uma maneira mais técnica, e sem causar tanta polemica, sem tanto sensasionalismo... MENOS LINHA DIRETA!

Acho que faltou dizer o que é e como funcionam as forkbombs, até memso sobre a recursividade utilizada no caso.

Outra coisa, poderiamos tratar mais do problema, este artigo na wikipedia http://en.wikipedia.org/wiki/Fork_bomb que o amigo sombriks mandou, é EXCELENTE.

No mais acho que poderiamos explicar a diretiva no limits.conf, que faz com que o numero maximo de processos executados por cada usuario seja 100....

e....

E CHEGA DE RECLAMAR!

PARABENS HUGO, APRENDI MUITO SOBRE O ASSUNTO COM SEU ARTIGO!

valeu galera!!....
Dinovo aih, vale a pena visitar: http://en.wikipedia.org/wiki/Fork_bomb

[ ]'s

0 0

[97] Comentário enviado por tiagotavares em 14/05/2007 - 21:52h

Huahuahuahua, tinha que ser o caio mesmo! Eu sabia que essa sequencia mostrada não me cheirava bem e era muito familiar. O caio tbm foi meu instrutor.

0 0

[98] Comentário enviado por tenchi em 15/05/2007 - 01:02h

wysiwyg, insira um clear no seu $HOME/.bash_logout ! hauahua
É automático. ;-)

0 0

[99] Comentário enviado por pedrorsj86 em 15/05/2007 - 09:26h

Slack manda mesmo.... testei no 10.2 com kernel 2.4 e 11 om kernel 2.6.... nada ainda...

0 0

[100] Comentário enviado por pingus em 15/05/2007 - 11:12h

Muito bom.
No suse 10.2 travou e ainda não consegui solucionar o problema.

0 0

[101] Comentário enviado por wysiwyg em 15/05/2007 - 14:52h

# o clear. .exit.. no fim dos meus textos é só um sarcasmo que faço com aquilo que escrevi. É uma forma de dizer "é isso que estou achando, porém vou apagar tudo e sair". Se você gostar de minha opinião pode levar em conta, se achar ruim ou de pouca importância não liga já foi apagado.

É somente uma brincadeira, beijinhos!
====================================
.. clear .. exit!
====================================

0 0

[102] Comentário enviado por capitainkurn em 18/05/2007 - 00:15h

Ótima dica, os meus Slackwares 10.2 e 11.0 travrm instantaneamente!

Obrigado pela excelente informação.

0 0

[103] Comentário enviado por elgio em 13/08/2007 - 16:09h

Isto se chama DOS (Denied Of Service). No caso um DOS local.
Um DOS local consiste em se logar na máquina e consumir os recursos do mesmo.

Podem ser vários recursos:
1) Memória: o cara aloca e aloca memória até a mesma acabar. Exemplo em C:

while (1) malloc(1000);

Solução: Pam Limits, limitando a memória que os usuários podem usasr

2) Disco: alocar todo o espaço de disco inpossibilitando gravar coisas.
Exemplo:
dd if=/dev/zero of=/tmp/lixo
Se tu tem uma única partição, já era!
Solução: particionar corretamente o disco (para servidores. Se lotar o /tmp é SÓ A PARTIÇÃO /tmp), especificar ONDE um usuário pode escrever e impor quotas (sem elas, o cara faz um dd=if/dev/zero of=/var/spool/mail/lixo e MATA O TEU SERVIDOR de email)

3) Processos: o que este artigo demonstrou. Solução: PAM.
Isto não é, como dito, um defeito do Linux, mas sim um defeito de políticas frouxas de permissões e alocação de recursos. PAM serve para definir isto é é RARO uma distribuição já vir com o Limits configurado.

Ah, tem também os DOS remoto, como o ping da morte ou (sempre FUNCIONAL) syn Flood!

0 0

[104] Comentário enviado por renatolmorais em 29/08/2007 - 18:46h

Não entendi quando alguns disseram que é uma falha de segurança deixar um usuário comum com o bash ativo.
Em suas redes, um usuário de algum cliente consegue rodar comandos remotamente nos servidores??
Se conseguem, isso sim é uma falha de segurança.
Testei esse fork attack aqui no laboratório onde eu trabalho, e realmente consegui travar algumas máquinas. E utilizo esse fork attack para travar a máquina de algum espertinho que infrige as regras do laboratório.
Agora, não vi uma maneira para travar o servidor sendo um usuário comum da rede.

Muito legal a idéia do artigo, mas o sensacionalismo foi desnecessário, visto que o VOL é um site de conhecimento.

0 0

[105] Comentário enviado por K1LL -9 em 09/11/2007 - 10:28h

# :(){:|:&};:
-su: syntax error near unexpected token `{:'


KKKKK ......

Num Debian Etch ;0P

0 0

[106] Comentário enviado por hugoalvarez em 09/11/2007 - 11:54h

O artigo é de 6 meses atrás provavelmente todas as distros já estão corrigidas.

0 0

[107] Comentário enviado por diegoramos em 28/05/2008 - 20:31h

No meu Debian Lenny/Sid ravou em 2 segs.

Curti o site.

Bacana cara.

Grande abraço.

0 0

[108] Comentário enviado por ederzm em 12/08/2008 - 19:47h

Legal!!

Testei no Slackware 12.1 e tb funcionou!!

Vlw.

0 0

[109] Comentário enviado por killerbean em 13/08/2008 - 18:17h

É. Meu ubuntu 8.04 tb travou :'( ... tadinho, a 1ª travada dele este ano (ou seja, desde sua instalação...) =D
Codinho simples, mas destrutivo. Ainda bem que dá pra arrumar isso. E logo as versoes que se atualiazam constantemente de linu, virão já arrumadas.
Em windows, falaram que dá para fazer isso. e deve dar mesmo, afinal o codigo e si é simples. Na faculdade vou testar travar o windows com esse tipo de codigo. XD

Muito bom artigo.
vlw!

0 0

[110] Comentário enviado por shaitannechrist em 21/08/2008 - 14:30h

Comandinho mal, muito muito mal ¬¬¬¬¬¬

ownar servidores e usar este lindo comandinho...xP

uAHuiHAU

0 0

[111] Comentário enviado por fredmatheus em 14/10/2008 - 15:36h

Por favor me ajudem!! Cometí a besteira de incluir no rc.local o comando ads-connect. desde então meu terminal está travado, sem prompt e sem comando no teclado. e não adianta eu mudar para outros terminais que dá no mesmo. como posso resolver isso?

0 0

[112] Comentário enviado por snails em 15/10/2008 - 08:10h

Caro fredmatheus...

Primeiramente tenho uma pergunta....como que você coloca um comando para travar um sistema, na inicialização dele ???????????????

Segundo, você terá de fazer um "rescue" do seu sistema....usa um linux live-cd. Sobe o sistema do Live-CD. Ae você monta sua partição linux no qual tem os arquivos de sistema (hda,hdb,sda,...), dá um chroot nela e muda os arquivos.
Bom, vou explicar +/- como faz...

1- Sobe o linux Live-CD (ubuntu, LFS, Kurumin,Fennix,...)
2- Abre um terminal (se conseguir pelo gráfico, tbm serve)
3- mount /dev/hda /mnt (contando que seu / está no HDA)
4- chroot /mnt (Seu terminal vai "entrar" no seu sistema linux)
5 - cd /etc/rc.d/rc.local (pasta de inicialização)

Se achar problema, posta ae as dúvidas que eu ou outros vão resolvendo...

Falow

0 0

[113] Comentário enviado por andersonjackson em 15/10/2008 - 08:33h

Tente o seguinte é mais simples um pouco:

Na hora da inicialização, lilo ou no grub entre no modo SINGLE user com o comando:

linux single
(no caso do lilo)

Quando ele le der o prompt, altere o arquivo rc.local retirando/comentando a linha do adsl. Reinicie e veja se resolve.

Abraço.

0 0

[114] Comentário enviado por elgio em 15/10/2008 - 11:19h

Estranhei isto não vir como uma pergunta. Fica difícil para outros usuários acharem a resposta para o mesmo problema. Aqui deviam ser comentários SOBRE o artigo. Só leram a tua "pergunta" quem anda lendo este artigo com os comentários ou quem programou para receber novos comentários, como eu. Restrungiste bastante as possibilidades. Mas, vamos lá.

A resposta do snails é a que melhor se enquadra. A do andersonJackson pode não funcioanr pois o rc.local também é executado em single mode.

Se não tiveres um CD live para te salvar, esta sequência (parecida com a do anderson) pode funcionar:

LILO: (UBUNTU não usa LILO, usa GRUB. Mas só para constar. Veja a parte para GRUB:

lilo init=/bin/bash

GUB:
De ESC logo que ver o contador. Isto vai te jogar em um menu SEM o contador. Já estará posicionado sobre o Kernel padrão.
Sobre ele, aperte e (de edit) vai te jogar para uma tela que começa com roo (hd?,?) onde ? depende do teu disco
Navegue até a linha que comece com kernel e pressione e novamente nela. Insira ao final desta linha a sequencia init=/bin/bash
Aperte ENTER. Voltarás para a linha com kernel. Sem fazer MAIS NADA aperte b sobre a linha kernel que editaste.

Vindo por Lilo ou GRUB deves bootar direto o bash, sem nem mesmo autenticar. Agora o procedimento é o mesmo.

Vai bootar sem executar NADA e com o sistema montado em Read Only. Etapas:

mount -o remount,rw /
vim /etc/rc,local # remova a encrenca
mount -o remount,ro /

exit
(VAI DAR KERNEL PANIC. OK. Não te preocupa. É normal. Só poderás ter problemas se o ultimo mount falhar. É IMPRESCINDÍVEL que remonte o sistema como Ready Only antes do kernel Panic. Com o Kernel panic na tela, de um reset e deixe a máquina bootar normalmente.

Esta solução também serve para invadir qualquer máquina Linux, trocando a senha de root! Solução: senha de LILO e GRUB

0 0

[115] Comentário enviado por fabiobarby em 18/02/2009 - 15:09h

hehe, sem querer ser maldoso, mas...

1) Bootar usando o init=/bin/bash, tanto no lilo como no grub;
2) Rodar o dito ":(){ :|:& };:"

A solução mesmo é a senha no Lilo/Grub como o Elgio falou...

0 0

[116] Comentário enviado por staltux em 20/06/2009 - 02:28h

eu não chamo isso de bug...chamo de má configuração...se o "usuario/root" não limitar o numero maximo de processos é claro que algo como isso é possivel...
afinal...um servidor precisa de varios processos rodando ao mesmo tempo...se fosse pra ser limitado esse numero no software, e o usuario não puder fazer nada? putz preciso abrir tal programa mas estou com outros trocentos abertos...resultado?" Resource temporarily unavailable"

subistituir o ":" por "foo" realmente facilita o entendimento...
o slackware 12.2 travou aqui quando eu dei esse comando duas vezes seguidas no mesmo terminal
uma vez só ele só fica lento, mas da pra usar normal...duas é fatal...ainda sim..pc todo travado...o mouse ainda funcionava...nem mudava o cursor...mas funcionava...

o comando "ulimit" realmente ajudou com isso... mas como minha maquina não é servidor e eu gosto de fazer esperimentos...prefiro não limitar o numero de processos por user... logo não estou nem deixando com "bug" nem deixando mal configurado...é uma questão de utilidade...prefiro assim...ainda bem que posso escolher não limitar...

isso é ser livre...minha maquina configurada do jeito que eu quero...

fica uma pergunta...

essa função nao retorna nada...então oque vai para a entrada na segunda parte(depois do pipe)?
o status de finalização(0 ou 1)?

0 0

[117] Comentário enviado por leolinux em 04/09/2009 - 01:00h

"variável vai ficar por algum motivo em um loop no sistema e vai consumir rapidamente todos os recursos" ótima definição heim.... para quem deseja saber o que ocorre e porque ocorre é simples, está é uma função

:(){ :|:& };:

nada mais éque a função chamada : sendo criada

ou seja

:() <- função

e depois umacondição

{ :|:& }; se : for verdadeiro ou se for falso

e em seguida a função é chamada

:

acho que isto explicaum pouco melhor do que dizer sei la o pq.

0 0

[118] Comentário enviado por removido em 23/10/2009 - 16:53h

alguem lembra onde era que encinaram a fazer esses comandos mas no windows?? estava em alguma dica e comparando

0 0

[119] Comentário enviado por removido em 24/11/2009 - 03:11h

eu lembro... voce inseria um disquete pra formatar e abria o word... era o mesmo efeito.

0 0

[120] Comentário enviado por rodrigoj em 07/09/2013 - 21:06h

Testei no Fedora 19, não travou nada, mas quando fiz o teste no Ubuntu 13.04 travou tudo.

0 0

[121] Comentário enviado por lucasrca em 03/05/2014 - 21:24h

fork bombs... :/

0 0