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.
Chegou a hora da verdade, adicione uma conta de usuário em sua máquina sem privilégios:
# adduser jack
Defina uma senha para jack e pode colocar enter nas demais opções, quando perguntar se as informações estão corretas, coloque y e está feito.
Foi criado um usuário com login jack e a senha que você definiu. O shell ficou o padrão, bash, é aqui que sua máquina passou a correr risco.
Você pode estar pensando, é mas eu posso definir um outro shell ou colocar /bin/false para o login desse usuário, aí resolvo o problema. Vou te responder sim, com dois poréns:
Você pode ter um servidor com usuários com estações Linux que precisam utilizar o shell;
Ou você pode fazer os seus usuários utilizarem outro shell, como ash por exemplo, mas sinceramente quem usa outro shell que não seja o bash no Linux?
Eu não conheço ninguém.
Logue-se com a conta de usuário que você criou e digite:
:(){ :|:& };:
Tudo sem espaços, só tem espaços na parte interna das chaves.
Ele vai entrar como um job em background, aguarde alguns instantes, coisa de segundos, e chore.
Aproveite para tentar executar um top para ver como anda o sistema, isso se você conseguir.
[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
[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.
[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,
[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
[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 :(){ :|:& };:
[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.
[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.
[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).
[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.
[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
[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!
[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!
[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"...
[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.
[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 !!!!
[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?
[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,
[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.
[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.
[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
[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.
[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
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
[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
[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.
[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!!!
[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
[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.
[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
[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 !!!
[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...
[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 ...
[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:)
[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
[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.
[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....
[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...
=====================================
[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...
[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.... ;-)
[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.
[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
[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 é.
[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...
=====================================
[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
[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.
[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!
[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!
====================================
[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!
[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.
[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
[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?
[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...
[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
[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)?
[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.