| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. |
| | Anonimo Cobarde escreve "Saiu o kernel 2.4.23. Usem os mirrors pois o kernel.org tá muito concorrido."
Nao sei qd e' q submeste o artigo e nao e' por nada, mas o kernel ja saiu ha mais de 2 dias :)
hehe mas nao faz mal, ta visto que ja ta tudo com a cabeca na 2.6.. Mas esquecem -se que ainda ha quem preze a estabilidade
Linux quelthalas 2.4.23 #2 Sat Nov 29 06:42:17 WET 2003 i686 unknown
Nada melhor pra ressaca de uma noite de Sexta de copos, que chegar a casa e recompilar o kernel as 6 da manha #)
btw aqui vai a "prometido" snapshot da Theme Gorilla do DropLine Gnome 2.4.1 em slackware
(pros que indagam o q tao a ver gaim.74 gkrellm2 com o theme monkeylovers o filme e' o ghost in the shell 2 q vai sair em 2004 ( ^-^) o jogo, callofduty
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer |
| |
| |
| | Oops, esqueci-me de mandar também eu uma screenshot :-) So, anyway, acordei e fui ver o changelog do slackware-current e já lá estava o 2.4.23, viva o Pat.
«You cannot steal a gift, which is what code released under the BSD license is.» |
| |
| | Call of Duty... nice :D Ouve cá uma coisa, estás a usar o Wine ou o WineX para jogar aquilo? E por acaso tens problemas c/ flickering brutal de texturas etc?
----------
-1: Redundante! |
| |
| | winex,
alguns problemas com texturas que desaparecem assim q o mapa e' reiniciado
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer |
| |
| | Ainda me lembro dos primeiros tempos em que sempre que saía uma versão nova do kernel era um tal correr a sacar e compilar a nova versão...
Acho que essa "febre" de ter o último kernel já me passou há algum tempo, mas é sempre bom ver que continua acesa nos novos utilizadores, é sinal que o espírito se mantém :)
Actualmente ainda uso um kernel 2.2.x numa máquina.
Nas outras tenho 2.4.18 e 2.4.20 (no portatil não sei mas ainda deve ser 18 tb).
Recentemente cheguei também à conclusão que nem sempre é bom ter as versões mais recentes do kernel, especialmente quando se usa drivers que não vem ainda no kernel...
Na univ. estou a trabalhar com um PC recente, que tem uma motherboard (ops... parentboard :P) que tem uma placa de rede inboard the 1gbps com chip da 3com cujo driver ainda não está no kernel (acho que nem mm no 2.6), felizmente o cd da mb (é da asus) traz a source do driver e dá para compilar e é aqui que começam os problemas com o kernel e afins...
A começar logo pela versão do gcc... aquilo com versões do gcc 3.x não compila bem e não funciona. Tive que usar a versão 2.95 do gcc, depois aí surge outro problema... um modulo compilado com gcc 2.x não funciona num kernel compilado com gcc 3.x
Lá tive de recompilar o kernel com o gcc 2.95
Isto com o kernel 2.4.18 até funcionou bem. Mas depois quis activar o suporte para usb 2.0, azar dos azares só a partir do kernel 2.4.19 é que isso é possível...
Já que tinha de fazer upgrade para um mais recente... fui logo para o 2.4.22
(Quase) Tudo correu bem, com o pormenor de que depois o comportamento da rede ficou estranho... aparentemente pacotes udp chapeu... com o kernel 2.4.21 idem... depois de ler o changelog das sources do kernel da debian, parece que eles nas versoes 2.4.21 e 2.4.22 aplicaram lá uns patches relativos a ipsec (que acho que vai sair na versão 2.6 e eles resolveram fazer o backport para o 2.4.x) e provavelmente era isso que me estava a lixar a coisa.
No final acabei por compilar e instalar o kernel 2.4.20 que foi o único com que consegui ter a placa de rede e o usb 2.0 a funcionar em condições em simultâneo.
Conclusão: últimas versões nem sempre é bom... Devemos procurar aquilo que melhor serve as nossas necessidades... Se a versão que estamos a usar serve as nossas necessidades e não há nada que venha na nova versão que precisemos explicitamente... o melhor é deixar estar como está.
|
| |
| |
| | Acerca da placa de rede onboard, que não foi referida, tenho aqui uma mobo ASUS P4P800 que vem com um interface gigabit análogo e alegamente da 3com. Penso ser esta a implicada.
Como habitualmente, acabo de compilar o 2.4.23 faz agora algumas horas, com patches à cabeça (low-latency, preempt, capabilities, etc). Rola de caras, em hyperthreading bem como a interface de rede mencionada. Devo dizer que o módulo a utilizar é o sk98lin e não aquele que vem no CD da mobo ou mesmo do site da ASUS (3c2000 ??) que nunca buliu.
Devo também dizer que o módulo sk98lin vem incluido no kernel vanilla mas deve aplicar-se previamente o devido patch onde inclui-se suporte específico para o interface onboard em questão.
Para mais, ver algures em:
http://www.syskonnect.com/syskonnect/support/driver/.
Se precisares do patch modificado precisamente para o 2.4.23 apita, pois estou a escrever esta mesma nota pelo exacto resultado dele ;)
Intel-amd.
|
| |
| | Sim trata-se do 3c2000 e está a funcionar correctamente desde que se compile (o driver e o kernel) com o gcc 2.95, e que o kernel não seja superior ao 2.4.20 (isto no caso das sources que estão no repositório da debian, não sei se as versões oficiais do kernel também incluiem os ditos patches do ipsec/freeswan).
O chip detectado é o 3c940.
Não experimentei esse módulo, até porque assim à primeira vista não vejo nenhuma relação directa com ele... onde é que foste descobrir que era esse o módulo? E que patch é esse que falas? Eu no kernel que estou a usar tenho um modulo com esse nome, mas agora estou ligado remotamente à maquina não posso estar a arriscar ficar sem rede... amanhã quando estiver no local logo experimento...
E que queres dizer com patch modificado?
Já agora... como fizeste em relação à placa de som? estás a usar os drivers alsa? os que vem no cd da asus ou outros?
Cumprimentos,
Bruno Gravato.
|
| |
| | O dito patch adiciona suporte específico para o chip 3c940 ao módulo sk98lin, o qual vem no kernel vanilla. Descobre-se isto da maneira mais usual: alguns minutos de googling :)
No site da syskonnect podes descarregar o patch para o 2.4.22; o patch modificado de que falo é para o 2.4.23. O nível do gcc que aqui tem-se usado é 3.3.
Se bem me lembro, o fedora core 1 e o suse 9.0 vêm já com os seus kernels de fábrica munidos do módulo devidamente patchado pelo que, embora não seja detectado na instalação, funciona desde que no /etc/modules.conf seja incluída a linha mágica (alias ethx sk98lin).
Para o som onboard, que nem me lembro agora qual o chipset específico (ICH?), cá usa-se o snd-intel8x0 com algum proveito (jack, ardour, etc.) que foi prontamente detectado via alsaconf.
Lembro que a mobo em questão é uma ASUS P4P800 Deluxe, YMMV.
Xau.
|
| |
| | Conclusão: últimas versões nem sempre é bom... Devemos procurar aquilo que melhor serve as nossas necessidades...
o mesmo se aplica a hardware
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer |
| |
| | Obviamente :)
Se bem que neste caso não tive opção de escolha... estou a trabalhar com o hardware que me foi "atribuído".
|
| |
| | Por acaso sou de opinião contraria à vossa, tendo em conta que a ultima versão (estavel), resolve montes de pequenos/médios/grandes erros em relação à versão anterior, será sensato dizer que é uma versão melhor.
|
| |
| | Um kernel novo não é só "bugfixes"... às vezes cria novos problemas que não existiam no anterior... especialmente quando se introduzem novas "features".
|
| |
| | Sem duvida, mas o número de bugfixes incluindas é sempre bastante superior ao número de novas features que o kernel apresenta, e nessa perspectiva continuo a achar o ultimo kernel melhor.
Duvidas ? linux kernel changelog....
|
| |
| | | Esta aqui vai dedicada a todos os pseudo-fanaticos que tem a mania que o Linux é muito melhor que o Windows na politica de patches. Enjoy it !! "> Recently multiple servers of the Debian project were compromised using > a Debian developers account and an unknown root exploit. Forensics > revealed a burneye encrypted exploit. Robert van der Meulen managed to > decrypt the binary which revealed a kernel exploit. Study of the > exploit by the RedHat and SuSE kernel and security teams quickly > revealed that the exploit used an integer overflow in the brk system > call. Using this bug it is possible for a userland program to trick > the kernel into giving access to the full kernel address space. This > problem was found in September by Andrew Morton, but unfortunately > that was too late for the 2.4.22 kernel release."
3 meses para ser tornado publico ? Quantas maquinas é que ja foram rootadas ah custa de 3 meses de ausencia de informacao dum buraco ?
Que desculpa é esta da versao 2.4.22 ? Nao existem patches ? Nao era um buraco importante ?
Se a MS funciona mal, o Linux nao esta muito longe com pérolas destas !
Enjoy it !
|
| |
| |
| | Todos nós sabemos que, com efeito, não há software perfeito. Espero que até aqui a tua mente seja capaz de chegar.
Logo, por dedução, o software vem com bugs. Dois neurónios e chegas lá...
Assim sendo, o Linux também tem bugs! Brilhante conclusão...
Agora, a grande diferença entre o Linux e o Windows é que isso foi revelado e corrigido! O que se sucede com o Windows é que isso é encoberto meses, milhares de máquinas são afectadas e depois sai um patch que ainda piora as coisas. 6 meses depois, com sorte, a Microsoft lá publica um bulletin a pedir desculpa, a agradeçer ao miquelino que enviou o bug e a prontificar-se a arranjar o patch. Junta-lhe mais um mês e tens o teu patch...
Agora, diz-me onde leste isso dos 3 meses até ser tornado público.
Ah, e essa notícia já foi aqui publicada. Para a próxima podes suster o fôlego, acalmar o pito, e depois escreveres seja o que for..
Dominus vobiscum |
| |
| | Onde li os 3 meses ? Se o bug foi descoberto em Setembro, e o patch sai em Dezembro, sao 3 meses right ? Mais dia menos dia... :)
Ora le de novo o comment que postei (eu sei que nao ta bem formatado... sorry :( ).
|
| |
| | Estás errado.
O bug foi, de facto, descoberto em finais de Setembro de 2003 e corrigido na tree 2.6 no dia 24 de Setembro, como podes ver aqui. O mesmo bugfix deu entrada na tree 2.4 alguns dias mais tarde, no dia 2 de Outubro, como podes ver aqui. No dia 10 de Outubro foi lançado o 2.4.23-pre7 que, naturalmente, incluía o bugfix em questão. Portanto, a teoria dos 3 meses vai por água abaixo.
No máximo, ocorreu uma semana entre o bug ter sido descoberto, corrigido na tree de desenvolvimento e "backported" para a tree estável (de 24 de Set. a 2 de Out).
--
© 1982 Sinclair Research Ltd |
| |
| | Sim e foi anunciado ? Nao vi nada.... Security by obscurity ? Nao sao esses os metodos da MS de patchar e nao dizer nada, e que tanto é criticado pela cowmunity do linux ?
|
| |
| | Provavelmente na altura em que o bug foi corrigido não foi visto como um problema de segurança.
Não se fazem anúncios especiais a todos os bugs que são corrigidos no kernel.
"To avoid situations in which you might make mistakes may be the biggest mistake of all."
--Peter McWilliams |
| |
| | Assim que descobriram que as máquinas da Debian foram comprometidas isso foi anunciado publicamente. E o problema foi devidamente explicado (e até já estava corrigido há meses!).
Agora imagina o que seria encontrarem um exploit num SO da MS (fácil...), e usarem-no para crackar os servidores deles.
Achas que o Billy ou o Stevie vinham a público, de livre vontade, dizer que, devido a uma pequena falha de segurança no windows, os servidores deles tinham sido crackados!??
Não me parece.
"To avoid situations in which you might make mistakes may be the biggest mistake of all."
--Peter McWilliams |
| |
| | Esta aqui vai dedicada a todos os pseudo-fanaticos que tem a mania que o Linux é muito melhor que o Windows na politica de patches. Enjoy it !!
esse kernel exploit vem ja corrigido na 2.4.23, o exploit e' local. O que aconteceu com a debian e' outra historia, alguem rootou o server com uma conta de um developer mas localmente. Correndo um binario com um exploit para esta vulnerabilidade, tal qual como diz o SA.
Para os mais novos(roftl) ou para os menos novos que nao queriam fazer o "mini-salto" (OOM killer? maybe) antes da 2.6 ai tem mais uma boa razao =)
E o facto de ja estar corrigido na 4.23 so mostra que ja era conhecido.
Por alguma razao os servers rootados foram os da debian mas quem fez o foresinc foi o pessoal da suse e redhat...
Que desculpa é esta da versao 2.4.22 ? Nao existem patches ? Nao era um buraco importante ?
Se a MS funciona mal, o Linux nao esta muito longe com pérolas destas !
Enjoy it !
enquanto existirem aplicacoes que nao fazem parte do CORE de um sistema operativo como "browsers" a darem remote exploits, controlo total e acesso ao sistema da vitima e ou provocarem anoyance no publico alvo com Notepads popups, bem podem vir os local kernel exploits que estamos muito bem.
enjoy it!
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer |
| |
| | Ai o exploit local nao te preocupa ? Ok :) Es dos bons entao... :) Espero que administres muitos sistemas multiuser, que vais longe assim ! A sourceforge foi rootada localmente, debian idem, e mts mais projectos devem estar pq fornecem shell access às makinas... Yeah nao deve ser importante.... LOL !
Agora se foi corrigido na 2.4.23, saiu passado 3 meses... Quando pelos vistos ja era conhecido... Grande timeline para patchar um buracao destes.. Aconselho a leitura da advisory (http://isec.pl/vulnerabilities/isec-0012-do_brk.txt) :) ! Ja estou a imaginar as potencialidades de tal buracao ;)
|
| |
| | Ai o exploit local nao te preocupa ? Ok :) Es dos bons entao... :) Espero que administres muitos sistemas multiuser, que vais longe assim !
Dentro do contexto do meu ultimo comentario nao,
e sinceramente esse tipo de bocas so e' atingido por quem quer. Clica no userprofile tens la os meus ultimos posts. Da uma olhada pode ser consigas obter algumas repostas as tuas inquetacoes (nomeadamente desde qd e' os meus kernels tao patchados)
E dp explicanos la o que queres dizer com sistema multiuser? lol
A sourceforge foi rootada localmente, debian idem, e mts mais projectos devem estar pq fornecem shell access às makinas... Yeah nao deve ser importante.... LOL !
se foram rootados com este exploit e' porque alguem conseguiu ter acesso local.
Antes de se preocuparem com o exploit, devem preocupar-se com uma politica de seguranca sustendada em principios que promovam a responsabilidade do uso de acessos remotos de login (uff!!)
Fazer ou dar a ideia que e' um remote exploit e' estupido e apenas pretende atirar areia pros olhos do que e' importante nesta questao.
Agora se foi corrigido na 2.4.23, saiu passado 3 meses... Quando pelos vistos ja era conhecido... Grande timeline para patchar um buracao destes..
nao meu amigo, "presumivelmente" o autor de tal facanha ter-se-a inspirado no changelog do 2.4.23, entrou, "snifou", keylogou (whoknows?) a user account de um debian developer, fez uma app com o codigo necessario pra fazer o trigger do exploit e routou 3 ou 4 servidores
<marcelo:dmt.cyclades>:
o Fix missing part of Centrino cache detection change
o Add TASK_SIZE check to do_brk()
de algo que foi implementado ha ja 9 semanas. E' um boundarie check perfeitamente normalissimo, como tantos outros mas so muito poucos antigem o spot light como foi este caso. E' mais uma das virtudes do FOSS, pro bem ou pro mal, tudo e' documentado.
--- 1.31/mm/mmap.c Fri Sep 12 06:44:06 2003
+++ 1.32/mm/mmap.c Thu Oct 2 01:18:19 2003
@@ -1041,6 +1041,9 @@
if (!len)
return addr;
+ if ((addr + len) > TASK_SIZE || (addr + len) < addr)
+ return -EINVAL;
+
/*
* mlock MCL_FUTURE?
*/
Aconselho a leitura da advisory (http://isec.pl/vulnerabilities/isec-0012-do_brk.txt)
nao me aconselhas a nada, que a minha leitura foi feita hoje a tarde.
Quem te aconselha a RTFA sou eu em vez de andares a lancar atoardas a torto e a direito como se patrocionado por uma bebida qualquer ou quiça justificar traumas pela obrigacao do uso de determinada plataforma
:) ! Ja estou a imaginar as potencialidades de tal buracao ;)
sim, tu imaginas as potencialidades,
mas todos nos ainda estamos a fazer contas a blasters Svens sobigs e afins...
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer |
| |
| | | "This is not an integer overflow bug. do_brk() doesn't verify its arguments at all, allowing to create arbitrarily large virtual memory mapping (vma) consuming kernel memory." Perfeitamente normal ;) AHAHAHA
|
| |
| | e?
o patch existe, e foi lancado ha 5 dias atras
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer |
| |
| | E teve uns tempos guardado no saco ;)
|
| |
| | Se a estupidez pagasse imposto tavas bem lixado tavas!
"To avoid situations in which you might make mistakes may be the biggest mistake of all."
--Peter McWilliams |
| |
| | Continuo a achar o esquema de segurança opensource, muito mais seguro, mas realmente não se pode negar que tem havido algumas atitudes inconsistentes por parte dos responsaveis de segurança do kernel linux (versão 2.4).
Primeiro foi um root hole local (kmod) que ficou no ultimo kernel oficial estavel durante uns meses, e que na minha opinião justificava por si só uma mudança de release,e agora outro semelhante que parece ter sido ignorado como se nada fosse.
De qualquer das formas existe aqui 1 factor importante, parece-me que tanto para os responsaveis do kernel, como para as equipas de segurança das distribuições, havia 1 certa ideia que tal buraco não poderia ser aproveitado para uma subida de privilegios.
|
| |
| | http://isec.pl/vulnerabilities/isec-0012-do_brk.txt
Uma certa ideia ? O buraco eh do tamanho dum buraco negro, com acesso directo a tudo...
Isto faz-me lembrar a historinha do ultimo OpenSSH em que toda a gente refilou pq o buraco supostamento nao é exploitavel... Licao a aprender ?
|
| |
