Vulnerabilidade do Ghost - recompilar programas C / C ++?

Question

Eu tenho CentOS 6.0 server com glibc-2.12-1.7.el6.x86_64 executando muitos serviços de código aberto e alguns dos meus próprios programas em C.

Para corrigir a vulnerabilidade fantasma, preciso atualizá-lo para glibc-2.12-1.149.el6_6.5 .

Como a diferença de versão parece grande.

Eu queria saber se eu preciso recompilar meus aplicativos C / C ++ ou até mesmo alguns dos serviços de código aberto?
Como faço para testá-los? Os testes de bcos são quase impossíveis?

Eu li que algumas pessoas tiveram que reverter os bcos de atualização que enfrentavam segfaults em seus aplicativos.

    

Answer 1

As aplicações Linux quase sempre usam links dinâmicos para a biblioteca C, o que significa que elas não são compiladas nelas - elas são ligadas em tempo de execução. Isso significa que, se você tiver atualizado a biblioteca C, não precisará fazer mais nada.

No entanto, embora seja muito incomum, não é impossível que as coisas sejam construídas com um glibc vinculado estaticamente. A melhor coisa a fazer é apenas olhar a documentação para o aplicativo em questão. Se esta é a prática, é quase certamente explícito.

Você pode verificar os executáveis com file . Deve dizer "dinamicamente ligado" na saída. Eu acho que ainda é possível que um binário assim incorpore um glibc estático - mas isso seria incrivelmente obtuso. A maneira de checar seria:

ldd whatever | grep libc.so

Onde whatever é o binário que você deseja verificar. Você deve obter alguma saída. Se não, deixe um comentário aqui para que eu possa comer meu chapéu porque não acredito que alguém criaria uma coisa dessas.

Se você encontrar um binário estático real, isso não significa que necessariamente utilizou o glibc. Você teria que confirmar isso consultando a árvore de fontes, a documentação ou os desenvolvedores.

I've read that some people had to revert the update bcos they faced segfaults in their apps.

Eu vi essa segunda e terceira mão também. Eu não vi realmente uma descrição concreta de tal caso embora. Eu acho que é muito improvável, para ser honesto.

    

Answer 2

Primeiro, o Red Hat Enterprise Linux mantém a base de seus pacotes o quanto for humanamente possível e mantém uma compatibilidade binária rigorosa. Se você analisar as versões de glibc , 2.12-1.7.el6.x86_64 vs 2.12-1.149.el6_6.5 (suponho que uma .x86_64 está faltando aqui), você tem a versão upstream 2.12 para ambos, local (RHEL) versão é de 1,7 contra 1,149 (ou seja, cerca de 142 conjuntos de patches). Um é para el6 (isto é, RHEL 6) e o outro para el6_6.5 (isto é, a quinta rodada de atualizações agrupadas em uma "nova versão" do RHEL 6). Eles devem estar muito próximos, sem diferenças visíveis ao usuário (exceto para correções de bugs, obviamente).

A esmagadora maioria dos programas vincula-se dinamicamente às suas bibliotecas (apenas uma cópia da biblioteca no disco e na memória, símbolos comumente usados estarão disponíveis para todos, proporcionando melhor desempenho), de modo que, em particular, uma correção para uma biblioteca é pegou na próxima vez que o programa for iniciado após a atualização. Apenas em casos muito raros, isso pode exigir uma recompilação do programa em si (se, por exemplo, uma função inline ou uma macro em um cabeçalho for incorreta de maneira prejudicial).

Programas estaticamente vinculados contêm o código da biblioteca (algo cada vez mais raro!) poderia ser vulnerável se acontecer de eles usarem o código corrompido na biblioteca.