Uma verificação primária dos logs do kernel confirmaram load elevado, com consumo de processador ou memória em 100% momentos antes do reboot.

A princípio achamos que foi causado por algum tipo de aumento na carga do Apache junto com o PHP. Todo dia primeiro e quinze do mês nosso relatório de checagem é executado no servidor e além das checagem ele faz também a atualização do kernel e demais componentes através do yum. Consideramos a hipótese de que algum componente tinha sido atualizado e passou a causar a instabilidade, já que todos os servidores haviam mostrado a instabilidade aproximadamente no mesmo horário.

Um acompanhamento foi feito nestes servidores durante a manhã e derrubando a primeira hipótese, não houve instabilidade em nenhuma das máquinas afetadas. Partindo ainda do horário muito próximo em todas as máquinas e sendo este horário próximo à execução do relatório executamos testes nas funções do relatório separadamente. Os testes acusaram a causa da instabilidade nos servidores e confirmamos.

Há duas semanas implementamos uma série de testes novos para garantir a checagem e integridade dos discos do servidor, onde os testes nos informam o tempo de vida do disco, verifica badblocks, status da “saúde” dos discos, desempenho, entre outros. Por algum motivo estes procedimentos, que em nosso ambiente de testes foram bem sucedidos, entraram em loop chamando a si mesmos dentro do próprio processo o que acabou por consumir memória e processamento do hardware.

Não foram afetados todos os servidores, a maioria conseguiu executar os testes normalmente sem qualquer erro ou instabilidade no sistema, porém ainda não identificamos quais as diferenças entre os dois grupos de servidor que podem ter causado tal erro, todos rodam no mesmo SO, na mesma versão, mesmo kernel.

Tais funcionalidades foram removidas do script, serão reavaliadas e passarão por novos testes. O script já foi atualizado em todos os servidores, afetados ou não.

Peço desculpas em nome da equipe a todos os clientes e colaboradores afetados pelo nosso erro.

Thiago Voltolini

WideCom Brasil

Nosso colaborador Ricardo Lobo da Seu Site Imobiliário nos deu o alerta.

Ele aparece ao declarar uma variável com o valor 2.2250738585072011e-308 ou próximo que, segundo o autor do bug report, é o maior número ponto flutuante.
Ao declarar atribuir o valor a uma variável o script entra em um loop e pode permanecer em processamento até o tempo de timeout ser atingido ou pode vir a consumir todo o processamento do servidor, o que é o ponto preocupante.

No dia 30 de dezembro o bug foi reportado ao PHP, no dia 06 de janeiro uma nova atualização do PHP para correção do bug foi lançada e ontem, dia 10, a correção foi confirmada pelos desenvolvedores.
No dia 06 foram lançadas as versões 5.2.17 e 5.3.5 e um script que realiza o teste, indicando se o servidor apresenta ou não o bug, na página de notícias do PHP

Todos os servidores gerenciados pela WideCom Brasil foram testados. Se você não recebeu nenhuma notificação significa que seu servidor não apresentou erro no teste e não apresenta o bug.

Em nossos testes nenhum servidor com PHP na versão 5.2 apresentou o problema, apenas servidores rodando a versão 5.3.x equipados com processadores Intel 32bits.

[Update]

Nos servidores WHM/cPanel as novas versões do PHP ainda não estão disponíveis mas todas as versões 5.x do PHP disponibilizadas no EasyApache foram atualizadas com um patch de correção do bug.
Se seu servidor apresenta o problema, basta compilar sua build novamente, sem necessidade de nenhuma atualização.

Forum cPanel

Maiores detalhes nos links abaixo:
Notícias PHP
PHP :: Bug
Exploring Binary

Uma vulnerabilidade foi encontrada no Exim, o MTA usado pelo cPanel. Um patch de correção já foi aplicado e a versão corrigida liberada para atualização.

De acordo com notícia divulgada pelo desenvolvedora o exploit é um buffer overflow que explora capacidades relacionadas a alteração das configurações em tempo de execução. Isso permite que comandos sejam executados com o usuário que executa o Exim. O problema é que o usuário retém permissões de root quando executado com os parâmetros -D ou -C.

Para solucionar o problema, a nova versão disponibilizada trava os arquivos de configuração em /etc/exim* e também impede que o Exim seja executado com as flags -D e -C

Para conferir a versão atual em seu servidor, utilize o comando:
rpm -qa exim

Todos os servidores WHM/cPanel gerenciados pela WidecomBrasil já foram atualizados com a nova versão do MTA (Exim 4.69-25).

Fonte: Blog Cpanel

Segue o log de mudanças:

• Corrigido URL’s no relatório do Server Check para cPanel se os Security Tokens estiverem habilitados na versão v11.25+.
• Adicionada explicação ipv6 de que a informação é determinada a partir da saída do ifconfig and exibidos os endereços ipv6 encontrados.
• Adicionada a habilidade de utilizar declarações Include nos arquivos csf.deny e csf.allow. Veja o readme.txt para informações e restrições.