gutocarvalho.net

Ontem fiz a atualização do meu wordpress através do plugin instant-upgrade.

Esta atualização está disponível desde o dia 25 de Abril de 2008.

Nesta versão 2.5.1 temos mais de 70 correções e muitas melhorias.

Dentre as principais novidades estão:

- Correções no arquivo wp-includes/pluggable.php
- Correções no arquivo wp-admin/includes/media.php
- Correções no arquivo wp-admin/media.php
- Melhorias de performance no Painel, Edição de páginas, Edição de Comentários.
- Melhorias de performance para quem tem muitas categorias
- Ajustes no envio de arquivos de mídia (media uploader)
- Atualização do TineMCE para versão 3.0.7
- Ajustes na administração dos Widgets
- Várias melhorias em usabilidade do wordpress

Mais informações em:

http://www.wordpress.org
http://wordpress.org/development/2008/04/wordpress-251/
http://trac.wordpress.org/query?status=closed&milestone=2.5.1&resolution=fixed&order=priority

Atualize já!

[]’s
Guto

Foi lançado no dia 30 de Março a versão 4.9 do OpenSSH e no dia 03 de Abril a versão 5.0 da implementação livre, opensource do protocolo SSH.

O OpenSSH permite administração remota de sistemas unix like, é uma ferramenta fundamental para qualquer administrador de sistemas, eu o uso todos os dias, o tempo todo, não sei viver sem ele ;)

Na versão 4.9 novos e importantes recursos foram adicionados ao OpenSSH, dentre eles o suporte CHROOT nativo (finalmente!), ajustes no ConnecTimeout, melhorias na integração do ssh com seu sub-sistema sftp-server, melhorias no controle PermitRootlogin, agora você pode especificar por exemplo que o root só pode se logar a partir da rede interna e muitas correções de segurança.

Site do projeto:
http://www.openssh.org

Notas de lançamento desta versão:
http://www.openssh.com/txt/release-4.9

Após o lançamento da versão 4.9, foi descoberta uma vulnerabilidade no OpenSSH que afetava todas as versões a partir da versão 4.3, a vulnerabilidade está ligada a diretiva X11Forwarding a qual permitia que conexões remotas do servidor X fossem interceptadas.

Relatório CVE deste bug no link abaixo:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1483

Após esta descoberta em apenas 4 dias o bug foi corrigido e uma nova versão do OpenSSH foi liberada.

Notas do lançamento:
http://www.openssh.org/txt/release-5.0

Isso demonstra a velocidade da comunidade SL em resolver bugs e disponibilizar as correções para a comunidade de usuários.

O projeto no “release notes” da versão 5.0, pede desculpas aos usuários por terem lançado um novo release tão perto da versão 4.9, mas foi uma atualização de segurança realmente necessária.

Para aqueles entusiastas que acharam estranho o projeto ter lançado uma major version “5.0″ ao invés de uma minor version “4.9.1″,  a explicação é que o projeto OpenSSH não utiliza a nomenclatura de versões mais comuns dos projetos open-source. Geralmente uma major version traz grandes mudanças na estrutura do projeto, enquanto minor versions trazem apenas correções e ajustes de segurança, mas parece que com o OpenSSH não é assim que funciona, então fiquem tranqüilos.

[]’s
Guto

O Evento

Durante a CanSecWest 2008, uma conferência que tem foco em segurança digital, foram testados 3 notebooks durante o OWN Contest, são eles:

1. VAIO VGN-TZ37CN rodando o Ubuntu 7.10
2. Fujitsu U810 rodando o Vista Ultimate SP1
3. MacBook Air rodando o OSX 10.5.2

Todos os equipamentos foram atualizados com os últimos patchs de segurança disponíveis.

O Desafio

O OWN Contest consistia em descobrir em 3 dias uma nova vulnerabilidade e após isto criar um hack/exploit para explorar a falha nos sistemas oferecidos para o teste. Os participantes que conseguissem encontrar uma falha e explorá-la seriam premiados, os prêmios diminuíam conforme o tempo passava, no primeiro dia o prêmio tinha o valor de 20 mil dólares, no segundo dia o valor do prêmio era de 10 mil dólares e no terceiro dia o valor pago seria de apenas 5 mil dólares.

As regras

No primeiro dia as regras do desafio consistiam em tentativas de invasão através da rede, sem contato direto com os notebooks. No segundo dia já era possível interagir com os notebooks e tentar utilizar técnicas que envolviam acesso com privilégios de usuários comuns. Nestes testes eles podiam acessar sites maliciosos com o navegador ou abrir e-mails com arquivos maliciosos. Se no terceiro nenhum dos notebooks fosse invadido, os participantes estariam liberados para testar softwares de terceiros, eles poderiam tentar instalar o skype por exemplo e através deste software tentar comprometer o sistema.

Os Testes

No segundo dia de testes Charlie Miller conseguiu em menos de 2 minutos encontrar uma vulnerabilidade no navegador web SAFARI (navegador do OSX da apple) e criar um hack para explorá-la, com isto ele acabou ganhando então um prêmio de 10 mil dólares da 3COM, uma das patrocinadoras do evento.

No terceiro dia de testes Shane Macaulay conseguiu encontrar uma vulnerabilidade no windows vista sp1 e elaborou um hack para se aproveitar dela, ele fez isto com uma pequena ajuda de seu amigo Alexander Sotirov (pequisador e membro da equipe de desenvolvimento do vmware) e seu colega de trabalho Derek Callaway.

Segurança

Infelizmente segundo as regras do desafio Miller e Macaulay não podiam revelar detalhes das vulnerabilidades descobertas, mas Miller deu uma dica, segundo ele foi graças a plataforma JAVA instalada no sistema que ele encontrou a possibilidade de burlar algumas proteções de segurança do windows vista SP1, inclusive em entrevista ele afirmou que a mesma vulnerabilidade pode ser explorada no OSX ou Ubuntu.

Ninguém dentre os 400 participantes conseguiu encontrar uma vulnerabilidade e explorá-la no Vaio com o Ubuntu 7.10 nos 3 dias do desafio.

O Ubuntu foi o OS vencedor do desafio no quesito segurança :)

Após o evento, pode-se encontrar na internet muitas especulações sobre a falta de empenho dos hackers em encontrar vulnerabilidades no Ubuntu comparado com o mesmo empenho para encontrá-las no windows vista sp1 e OSX da Apple, mas como disse é tudo especulação.

Especulação & Raciocínio

Eu particularmente acredito que foi bem mais simples investir tempo contra tecnologias proprietárias do que contra tecnologias livres, nas tecnologias proprietárias são olhos de no máximo uma centena de desenvolvedores cuidando do código, nas tecnologias livres são olhos de milhares de desenvolvedores cuidando do código e desenvolvendo soluções de forma coletiva, penso que na cabeça dos participantes a a questão era ganhar o prêmio, então pela lógica eles deveriam atacar o sistema com uma maior probabilidade de falhas, e comparando as diferenças de auditoria, testes homologação entre projetos livres e proprietários, a qual é uma questão ligada diretamente ao número de desenvolvedores, colaboradores e usuários, eu ficaria com as opções MACOXS e VISTA com toda a certeza. Isso não significa que sistemas GNU/Linux são imunes, na minha opnião significa que a resposta a falhas e sistemas livres é mais rápida que em sistemas proprietários.

Conclusão

Parabéns ao Ubuntu e principalmente parabéns aos sistemas GNU/LINUX, pois o Ubuntu apesar de não ser o mais querido entre os usuários avançados, representou muito bem a família GNU/LINUX no evento, dando um bom “olé” nos concorrentes, demonstrando sua qualidade, estabilidade e a qualidade do método de desenvolvimento colaborativo.

Referências:
http://cansecwest.com/
http://dvlabs.tippingpoint.com/blog/2008/03/19/cansecwest-pwn-to-own-2008
http://www.linuxworld.com/news/2008/032908-with-vista-breached-linux-unbeaten.html?fsrc=rss-linux-news
http://www.networkworld.com/news/2008/032708-gone-in-2-minutes-mac.html
http://www.networkworld.com/news/2008/032708-hacker-super-bowl-pits-mac.html?page=2
http://www.noticiaslinux.com.br/nl1206930518.html

Se você atualizou o kernel do ubuntu gusty para versao 2.6.22-14.47 e seu som não funciona mais, somos dois.

Bom, uso um notebook toshiba, modelo A105-S4334, para resolver o problema adicionei a seguinte linha ao arquivo /etc/modprobe.d/alsa-base

options snd-hda-intel model=auto

Após um reboot o som voltou a funcionar normalmente.

Se não funcionar você pode tentar reinstalar os pacotes alsa-lib, alsa-utils e alsa-driver, talvez resolva.

Se não der certo, siga o tutorial anterior e customize um kernel para você, é simples, o 2.6.23.13 já vem com ALSA 1.0.15 com várias correções que podem lhe ajudar.

[]’s
Guto

O problema do ano 2038 é uma falha na representação de datas em computadores, que pode causar erros em alguns programas de computador no ano de 2038.

O problema afeta os programas que utilizam a representação de tempo POSIX, em que a data é calculada através do número de segundos (ignorando os segundos bissextos) desde 1 de janeiro de 1970. Esta representação é padrão nos sistemas operacionais do tipo Unix e afeta a maioria dos sistemas, pois grande parte deste software foi desenvolvido na linguagem C. Na maioria dos sistemas de 32 bits, o tipo de dados time t, utilizado para armazenar esta contagem de segundos, é um inteiro de 32 bits do tipo signed (considera o sinal). O último registro de tempo que pode ser representado por este formato, seguindo o padrão POSIX, é 03:14:07 na terça-feira 19 de janeiro de 2038 (UTC). Após este momento a data será representada por um número decimal negativo que, dependendo da implementação, corresponderá ao ano 1970 ou 1901. Este valor para a data corrente certamente resultará em erros de cálculo e de funcionamento na maior parte dos programas em execução pelo sistema.

Leia mais na wikipedia: http://pt.wikipedia.org/wiki/Problema_do_ano_2038

Há alguns dias escrevi no blog sobre alguns bugs encontrados no Ubuntu 7.10, dentre eles falei de um problema com o debmirror e até postei uma solução que resolveu os problemas temporariamente.

Bom a questão é que os developers do debian (distro mãe) avaliaram mais a fundo e o BUG na verdade está no pacote libcompress-zlib-perl, veja o trecho do código que afeta o debmirror.

The corresponding debmirror code is here:

 851     my $gunzf = gzopen($file, "rb") or die "$file: $!";
 852     my $line;
 853     my $res;
 854     my $loop = 1;
 855     while ($loop) {
 856       my $buf = "";
 857       while(($res = $gunzf->gzreadline($line) > 0)
 858             && !($line =~ /^$/)) {
 859         $buf = $buf . $line;
 860       }
 861       if ($res <= 0) { # <--------  THIS IS ALWAYS TRUE AFTER THE UPGRADE
 862         $loop = 0;
 863         next;
 864       }

O pacote já foi refeito e colocado no repositório proposed do ubuntu, se atualizarem o pacote não precisarão alterar o código do debmirror como citado anteriormente, quem alterou pode ficar tranquilo que funciona também.

Referências:
https://bugs.launchpad.net/bugs/136634
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=435656

Estive lendo sobre esse suposto BUG matador de HDs, especificamente na distro Ubuntu na SLASHDOT.NET e PLANET.UBUNTU.COM, e isto está tomando a internet, eu acredito que seja mais um problema de hardware do que de software, o que pode caracterizar FUD, “queimando” indevidamente o ubuntu e o bom trabalho de sua comunidade.

O que se fala deste bug é o seguinte, quando você estiver usando mobile devices (notebooks) em modo bateria, e se o script laptop-mode estiver habilitado (por padrão vem desligado) os load cycles de seu disco podem ocorrer de forma continua e desnecessária, muito ciclos podem diminuir a vida do disco e até danificá-lo. Em alguns casos as pessoas podem escutar ticks contínuos. Isso pode acontecer quando o disco estiver em idle.

O que faz o script laptop-mode?

Quando você inicia o notebook através da bateria o script laptop-mode, caso esteja ativado, carrega o arquivo de configuração /etc/default/acpi-support , o qual tem configurações que dirão como o ACPID vai se comportar.

O que é ACPI, ACPID e APM?

ACPI significa Advanced Configuration and Power Interface, em bom português interface avançada de configuração de energia, ela foi criada pela HP, Toshiba, Intel e Microsoft para ser o novo padrão de gerenciamento de energia em computadores, o padrão usual é o APM, que significa Advanced Power Management, que foi inicialmente desenvolvido para controlar o uso de energia em dispositivos portáteis, porém acabou sendo incorporado em computadores de mesa.

A diferença básica entre os dois é o seguinte, o APM deixa a BIOS cuidar do gerenciamento de energia e no caso do ACPI quem cuida disto é o software.

O ACPID é um daemon que implementa o APCI no ambiente linux, ele funciona como uma camada de abstração entre o OS e o hardware, permitindo o envolvimento independente da BIOS.

Como verificar seu sou acometido por este problema?

Instale o pacote smartmontools e faça o seguinte teste.

root@defiant:/home/gutera# smartctl -a /dev/sda | grep Load_Cycle_Count
193 Load_Cycle_Count 0×0012 099 099 000 Old_age Always - 10229

Veja, no meu caso o valor do load-cycle-count é de 10229, se ele aumentar em pouco tempo e continuar aumentando você pode ter um hardware que tem um tratamento agressivo em relação ao consumo de energia. No meu caso esse valor não mudou nas últimas horas, existem depoimentos de que este valor pode subir em minutos.

Isso é um problema do Ubuntu?

Não, isso é um problema dos fabricantes dos discos, que implementam em suas controladoras de disco um tratamento radical para o controle de energia.

Isso pode danificar seu disco?

Pode, caso você use laptop-mode e os ciclos estejam aumentando muito rápido, isso vai diminuir a vida útil do seu disco e pode até danificá-lo em pouco tempo. Existem casos de danos sérios reportados.

Como resolver?

Existem várias abordagens para vários tipos diferentes de hardware, existem depoimentos diversos com abordagens diversas e soluções diferentes, algumas soluções funcionam em alguns hardwares e não funcionam em outras. Vou passar algumas genéricas neste post.

Lembro sempre que essas configurações agressivas de consumo de energia ou são características da BIOS ou do firmware do disco rígido.

Soluções propostas, vou traduzi-las do launchpad.

https://launchpad.net/ubuntu/+source/acpi-support/+bug/59695/comments/10

1)Eu adicionei as seguintes linhas em meu hdparm.conf:
/dev/sda {
apm = 255
}

2) Eu criei o arquivo /etc/acpi/resume.d/99-stop-hitachi-madness.sh
com o seguinte conteúdo:
#!/bin/sh
hdparm -B 255 /dev/sda

Eu espero que tenha ajudado.

https://launchpad.net/ubuntu/+source/acpi-support/+bug/59695/comments/14

Aqui esta a forma como eu corrigi definitivamente o problema:

1) crie um arquivo com o nome “99-hdd-spin-fix.sh”. É importante que o nome começe com “99″.
2)tenha certeza que ele contenha apenas as duas linhas abaixo, corrija isto caso seu disco seja PATA HDD:

#!/bin/sh
hdparm -B 255 /dev/sda

3) copie esse arquivo para 3 locais, ou crie links simbólicos:
/etc/acpi/suspend.d/
/etc/acpi/resume.d/
/etc/acpi/start.d/

Voila! após este ajuste o seu disco não vai mais ter baixas rotações quando for ligado (aparentemente acontece quando se esta usando a bateria do notebook apenas).

https://launchpad.net/ubuntu/+source/acpi-support/+bug/59695/comments/19

Uma alternativa a correção “99-hdd-spin-fix.sh” é instalar e habilitar o pacote laptop-mode-tools, e customizar o arquivo /etc/laptop-mode/laptop-mode.conf confor me abaixo:

CONTROL_HD_POWERMGMT=1

Bom como disse o Ubuntu Developer Matthew Garret, o Ubuntu não afeta ou danifica seu disco, pelo contrário através dele você pode proteger seus discos com as otimizações já citadas. Tanto não é um BUG que no launchpad o problema foi marcado com prioridade whishlist (um tipo de solicitação de ajuste), é menor que a prioridade low (baixa).

Surgiram alguns comentários sobre os ajustes, falaram que os ajustes desligam completamente o gerenciamento de energia do disco, ou seja de uma forma você preserva o HD em relação aos excessivos load-cycles porém em outro aspecto o disco pode superaquecer sem gerenciamento de energia. Supõe-se que os discos mais modernos aguentam altas temperaturas, veja esses comentários nos links abaixo:

https://launchpad.net/ubuntu/+source/acpi-support/+bug/59695/comments/16
https://launchpad.net/ubuntu/+source/acpi-support/+bug/59695/comments/18

Bom caso seu disco seja acometido pelo problema, faça ajustes por sua conta e risco, pequisa bastante e verifique possíveis soluções.

Referências:

https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/59695
http://www.linux-hero.com/rant/explanation-ubuntu-hard-drive-wear-and-tear
http://www.advogato.org/person/mjg59/diary/82.html
http://www.linux-hero.com/rant/explanation-ubuntu-hard-drive-wear-and-tear
http://ubuntudemon.wordpress.com/2007/10/30/ubuntu-is-not-causing-aggressive-power-management/
http://ubuntudemon.wordpress.com/2007/10/26/laptop-hardrive-killer-bug/
http://ubuntudemon.wordpress.com/2007/10/28/laptop-hardrive-killer-bug-how-to-discover-whether-you-are-affected/
http://ubuntudemon.wordpress.com/2007/10/29/laptop-hardrive-killer-bug-should-get-critical-status/
http://pt.wikipedia.org/wiki/ACPI
http://pt.wikipedia.org/wiki/APM
http://acpi.sourceforge.net/
http://paul.luon.net/journal/hacking/BrokenHDDs.html
http://www.thinkwiki.org/wiki/Problem_with_hard_drive_clicking

Se você usa o debmirror para sincronizar seus mirrors cuidado, o debmirror do gutsy esta quebrado.

Ele baixa apenas os release files e depois apaga todos os pacotes do seu mirror, eu acabo de perder todo o meu repositório do feisty, 17 gigas…. :(

A solução abaixo foi proposta pelo marcolino (https://bugs.launchpad.net/~mas-marco)

Edite o arquivo /usr/bin/debmirror

Vá até a linha 793

local $/=”\n\n”;

altere para :

local $/=”\n”;

Agora o debmirror funcionará corretamente..

Bug aberto e confirmado…
https://bugs.launchpad.net/ubuntu/+source/debmirror/+bug/136634

É bom testar antes em um local separado…. segue um exemplo a seguir.

# debmirror -v -p –arch=i386 –host=archive.ubuntu.com –root=ubuntu –section=main,multiverse,restricted,universe –dist=gutsy,gutsy-updates,gutsy-security,gutsy-backports,gutsy-proposed -e http –ignore-release-gpg –nosource –progress /local/do/seu/mirror/distros/ubuntu/gutsy

[]’s
Guto