| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | Nenhum SO está isento de falhas, o que acontece é que ao contrário de certas outras empresas os patches estão disponíveis quase imediatamente (como se pode ler na notícia) e antes de alguém ter tido tempo de explorar essas mesmas falhas. Além disso os sysadmins de *nixes (Linux) tendem a ser um pouco mais paranóicos (e mais capazes) e a instalar esses mesmos patches imediatamente (ao contrário dos point and click sysadmins de outros SOs).
-- Carlos Rodrigues
- "I think we can handle one little penguin!"
- "No, Mr. Gates, your men are already dead!"
|
| | | | | | Além disso os sysadmins de *nixes (Linux) tendem a ser um pouco mais paranóicos (e mais capazes) e a instalar esses mesmos patches imediatamente (ao contrário dos point and click sysadmins de outros SOs). Apesar disso, devo admitir que ferramentas mais automatizadas para actualizar o Linux em casos como este ajudariam. Só tenho instaladas poucas máquinas linux, mas consigo imaginar o que seria ter que fazer actualizações em dezenas ou centenas destas máquinas. Coisas como o Red Hat Network ajudam, mas ainda não são a solução.
JB |
| | | | | ao contrário dos point and click sysadmins de outros SOs E mehor é que nem sequer sabem se estão realmente a instalar um patch ou mais uma "camioneta" de bugs :) Czar.
|
| | | | (...)Sai o melhor possível... (para tentares garantir a tal rapidez) e isto sim já parece preocupante,(...)
Não é "sai o melhor possível", a maioria das falhas de segurança por mais graves que sejam resumem-se no código da aplicação em falta a algumas poucas linhas, normalmente são coisas que se resolvem (bem) em 5 minutos (como a maioria dos buffer overflows).
A desculpa da verificação dos patches é típica da Microsoft e é, desculpem a expressão, uma desculpa de merda. É melhor lançar rapidamente um patch (mesmo que não seja a solução mais elegante) e depois lançar outro do que demorar montes de tempo (o rapidamente da Microsoft é rapidamente depois da falha já ter sido explorada e não rapidamente depois de ter sido encontrada) a lançar seja o que for.
(...)por isso é que aqueles relatórios dos especialistas do Gartner Group são uma verdadeira treta.(...)
Também não me fio muito em relatórios desses mas a verdade é que a Microsoft já tem um "cadastro" deveras impressionante de falhas, o que eles disseram foi apenas constatar o óbvio.
-- Carlos Rodrigues
- "I think we can handle one little penguin!"
- "No, Mr. Gates, your men are already dead!"
|
| | | | Bem... até ao kernel 2.4.10 tenho um problema que pode fazer com que o pessoal me roote a maquina, a partir do kernel 2.4.10 tenho um problema que pode fazer com que os meus discos percam uns quantos dados importantes...
Pela primeira vez estou assustado com o Linux!
"A mais louca das mulheres consegue dominar o mais inteligente dos homens" |
| | | | | | "Pela primeira vez estou assustado com o Linux!"
Porquê ?
Julgavas que o Linux era feito por Deuses na Terra que não erravam ?
Anyway... o problema, se bem percebi o texto que foi lido à pressa, só afecta as máquinas em hajam utilizadores com acesso à shell e suficientemente espertos para se meterem por estes caminhos (coisas cada vez mais raras).
Já li comparações destes bugs com o nimda e não me parece que tenham nada a ver um com o outro.
De um worm que se propaga sozinho sem que a maioria dos incautos se dê sequer conta, a um bug que requer prévio acesso à shell de uma máquina Linux e conhecimentos do SO, vai um grande passo.
Mário Gamito
educação, ensino |
| | | | | Nao é uma questão de ser perfeito, mas julgava que a produção de bugs em serie era uma patente da microsoft... ;)
"A mais louca das mulheres consegue dominar o mais inteligente dos homens"
|
| | | | Ai, ai. Um bug ou dois(independentemente da gravidade dos mesmos) não é a mesma coisa que uma dezena ou mais, cujos patches muitas vezes provocam piores. Agora, dizer-se em série é uma alarvidade. É não ter mais o que comentar não é? Faz-me lembrar quando aparece um pouquinho de nevoeiro a malta fica logo excitada porque vai poder ligar aquela luzinha, carregar naquele botãozinho mágico...mas fico descansado. As correções são rápidas e normalmente eficazes.
"Os meus 2 Duh!" Gimp zZzZz
|
| | | | | Um bug ou dois estamos todos à espera. Bugs obscuros sao perfeitamente compreensíveis, falhas de segurança aparecem em todo o lado. E não me parece que o Linux seja particularmente propenso a estas coisas. O que eu pessoalmente acho que não se deve tolerar são bugs perigosos que surgem por não se testar convenientemente cada versão do kernel, antes de ser lançada (parece-me a mim que, para o Linus, "testar" significa lançar uma versão nova do kernel e esperar pelos bug reports), e problemas introduzidos por mudanças drásticas em versões "estáveis" do kernel (por exemplo, as mudanças de VM pelo meio do 2.4), que apenas deviam acontecer no branch instável. Na minha opinião, devia-se aproveitar algumas ideias do processo de desenvolvimento dos BSDs, que resulta muito melhor do que o que se faz actualmente em Linux. A desvantagem é que o desenvolvimento se torna mais lento, mas pessoalmente troco de bom grado velocidade por estabilidade. Agora, perder ficheiros por causa de problemas num kernel "estável" é que não pode ser...
|
| | | | Bem, pessoalmente só mudo para um novo kernel ou para uma nova versão de um programa passado quase um ano, tipo equipa vencedora não se mexe. E isto nos sistemas não críticos. Se bem lembro, sempre que há uma nova versão os conselhos do costume são não usar em máquinas de produção até haver uma certeza de que as coisas estão ok. O modelo do linux sempre foi assim ou de repente fiquei amnésico? Quanto ao Sr. Linus acho que anda ocupado com coisas a mais e realmente faz cagada.
"Os meus 2 Duh!" Gimp zZzZz
|
| | | | | Se o teu problema é o bug do kernel 2.4.10, a RedHat incorporou as correcções ao bug do ptrace (o que está a ser referido aqui) no 2.4.9. Podes ir buscar as sources aqui (estão em RPM, se usares debian tens de usar o alien). Como sempre, a RedHat utiliza um kernel que não é o do Linus, mas sim uma variação do do Alan Cox. No entanto, para todos os efeitos, não me parece pior.
JB |
| | | | para comecar, lembra-te que esta ataque e' local, os piratas ja' precisam de ter acesso a uma shell
bem,para resolver isto podes simplesmente fazer chmod 711 /usr/bin/newgrp para retirar o suid deste ficheiro ou as permisoes de executar para o group e all
ja' resolve uma data de problemas...
pelo que o bugtrack:
In order to exploit this kernel vulnerability, one needs a setuid
root binary which execs an user-defined binary (or a shell). Newgrp is
appropriate on most distributions. On default install of slackware it does
not work (the password fields in /etc/group are empty, and newgrp demands a
password). However, one can use "su" on this distribution. "su"
binary is compiled without PAM support on slackware, therefore it execs an
user shell.
bem, a slackware nao e' directamente vulneravel pelo newgrp, mas pode ser pelo su
logo para a slackware teras de retirar tambem o suid ou as permicoes de executar para todos (usa o group wheel no su e da' apenas permicoes de executar para o root e o group wheel)
assim o sistema ja' estara minimamente seguro (nao totalmente, pois poderam haver mais programas suid vulneraveis)
quando sair o novo 2.4.13 ou patchs que corrigam os problemas do 2.4.12 (e nao metam novos) fazes o upgrade
Higuita |
| | | | para comecar, lembra-te que esta ataque e' local, os piratas ja' precisam de ter acesso a uma shell Já não és o primeiro a notar isto, mas da maneira como tem sido feito parece indicar que não há razões para alarme. Ora, isso não é verdade. O trabalho dos crackers passa a ser simplesmente: - encontrar maneira de executar um comando setuid na tua máquina ->
- usar o bug ->
- obter uma shell root.
É verdade que a maior parte dos sistemas operativos Unix-like possuem diversos mecanismos de escalação de privilégios (ou seja, de passar de utilizador normal a root). No entanto, não é por serem comuns estes problemas que deixam de ser sérios. O principal problema deste bug é que está presente em MUITOS kernels diferentes de MUITAS distribuições diferentes, etc. Com a massa critica de Linux que já existem por aí, a motivação para criar um root-kit que use este bug fica aumentada significativamente em relação a um exploit que ocorra apenas numa distribuição e numa versão do kernel. O pior que pode acontecer ao Linux é uma atitude de complacencia em relação aos problemas de segurança. Enquanto o número de máquinas existentes era pequeno, criar mecanismos automáticos de exploração de vulnerabilidade era pouco compensador, mas agora provavelmente já não é o caso. Se não tivermos cuidado, o proximo "Ramen" pode atingir dimensões de um "Code Red" ou de um "Nimda".
JB |
| | | | Eu nunca disse que isto nao e' grave, exige actualizacao do kernel, mas nao e' uma vulnerabilidade de rede, directa para root!!
para sistemas que nao tenham utilizadores locais nao e' razao para entrar em panico
para sistemas com utilizadores, isto e' uma falha muito grave e, ai sim, alarmante, mas mesmo assim, ja' deveriam ter cuidado para disponibilizar o minimo de programas suid para os utilizadores (mesmo ping e traceroute sao de utilidade questionavel para utilizadores) pois qualquer programa suid pode ser um trampolim para root (assim como deamons em root)
para os sistemas com utilizadores, as dicas das permissoes e' apenas para ganhar tempo ate' aplicarem o patch
para sistemas sem utilizadores locais, devem tambem corigir o problema e pelo menos limitar as permissoes, nao e' tao grave pois para haver perigo e' preciso ja' haver algum servico vulneravel na maquina para obter a shell, algo tao inaceitavel como deixar este bug por corrigir
1. encontrar maneira de executar um comando setuid na tua máquina
pois, aqui e' que esta' a questao das permissoes, nao serve qualquer programa suid, precisa de algo que durante o carregamento do programa execute outro comando no disco, retirando as permissoes do newgrp e do su na slackware elimina-se os ataques dos scriptkids e das rootkits
quem souber, pode procurar novos programas suid, mas isso ja' vai consumir tempo e dar oportunidade para corrigir o problema
para administradores sem tempo pode ser uma solucao temporaria, e ja' agora limita tambem futuros ataques usando estes programas
isto tudo tambem porque veio acontecer numa altura ma' para o kernel, o 2.4.12 com problemas graves e ser o kernel que corrige o problema... duvida de qualquer administrador: ficar com o sistema mais fraco ou ficar com um sistema que pode apagar uma particao?(o 2.2.19 e' outra historia)
a dica serve para dar uma 3º solucao, ainda que temporaria ate' os problemas do 2.4.12 desaparecerem, sempre e' melhor que ficar com os kernels com o bug a' espera sem fazer nada
este problema nao pode ser ignorado, ira' ser incluido nos rootkits com certeza, mas para ter uma utilizacao automatica (ie: worm) precisa de um outro servico de rede ja' vulneravel
entre este problema ou um do bind, ftp, ou apache, prefiro mil vezes este 8)
Higuita |
| | | | Em relacao ao que dizes de que o comando tem que ter o sid bit, permisoes de execucao, e uid de root, nao e o newgrp o unico.
Provavelmente existem N executaveis que satisfacem esses requisitos.
So assim de cor:
mount
umount
su
traceroute
...
Com um find +- elaborado descobrem-se todos.
Portanto nem pensar que para ficar protegido 'e so trocar as permisoes no newgrp hmmm.
Quem pensar isso 'e basico!
Z
|
| | | | le o bugtrack...
nao basta qualquer programa suid
precisa de ser um que cumpra certos requesitos
julgo que tem que ser um que execute um outro programa conhecido durante o seu arranque
o newgrp a shell, o su na slackware directamente a shell
deve haver varios, mas tratando do newgrp e do su elimita logo a partida os ataques dos scriptkids e dos rootkits
mas como disse, isto e' apenas para ganhar tempo ate' o 2.4.12 estabilizar, nunca devera' ser tomado como a solucao definitiva
Higuita |
| | | | Quer-me parece que em vez de andar a tirar suid root a esses progs ( ja agora corre o bastille e tiras suid a montes deles) mais vale fazer um chmod 700 ptrace temporariamente!
|
| | | | nao sei que sistema tens, mas no meu o ptrace e' uma chamada de sistema, nao um comando
Higuita |
| | | | | Não precisas fazer upgrade, ou colocas o patch, ou recompilas um destes kerneis que já têm o patch. noc.
|
| | | | Eu apenas acho que o Linus e todo o seu núcleo duro, anda um pouco apressado para lançar releases do kernel, eu acho que nunca vi tamanha pressa para lançar releases do kernel como agora, é quase de mês a mês dias que sai uma evolução no kernel.
Eu acho que se devia estar mais tempo a auditar o código para que não aparecessem mais bugs como este. Devia ser mais ao estilo dos BSD's, mais lento no lançamento mas com menos bugs, e com um código mais maduro.
|
| | | | |
|
