Depois de executar os scripts Perl do apt-get dist-upgrade não irão mais ignorar certificados SSL inválidos em 14.04

Depois de executar os scripts Perl do apt-get dist-upgrade não irão mais ignorar certificados SSL inválidos em 14.04

Bom Dia a todos,

Na semana passada, decidi executar os comandos para atualizar pacotes em meu servidor 14.04 para garantir que fui corrigido para as vulnerabilidades Bash encontradas recentemente. De acordo com as informações aqui (http://www.ubuntu.com/usn/usn-2362-1/) Executei um apt-get dist-upgrade. Para referência, executei o apt-get update, o apt-get dist-upgrade e depois o apt-get upgrade para tentar e ter certeza de que tinha tudo atualizado (no entanto, eu executo rotineiramente o apt-get upgrade).

Depois de fazer isso com sucesso, descobri que vários dos meus scripts Perl não estavam mais funcionando. Para referência, eu uso este servidor para o Nagios monitorar todos os meus outros servidores. Os scripts em questão que agora estão falhando se conectam a um sistema via https, fazem login no host e consultam várias informações.

Antes da atualização, consegui adicionar uma linha a cada um dos meus scripts Perl para ignorar o SSL:

$ENV{PERL_LWP_SSL_VERIFY_HOSTNAME} = 0 } 

No entanto, após a atualização, isso parece não ter efeito, e todos os scripts falham porque não conseguem verificar os certificados SSL (todos autoassinados).

Aqui estão alguns trechos do que estou vendo:

execução do script:

    nagios@nagios:/usr/local/nagios/libexec$ ./check_esx.pl -H 192.168.22.18 -u root -p password -l cpu
CHECK_ESX.PL CRITICAL - Can't connect to 192.168.22.18:443 (certificate verify failed)

LWP::Protocol::https::Socket: SSL connect attempt failed error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed at /usr/share/perl5/LWP/Protocol/http.pm line 41.

Este script Perl específico utiliza o "VMware Infrastructure (VI) Perl Toolkit" para funcionar. O script que estou chamando, check_esx.pl está disponívelaqui

Aqui está um trecho do arquivo http.pm em torno da linha referenciada no erro acima; a linha 41 é a linha "matriz".

sub _new_socket
{
    my($self, $host, $port, $timeout) = @_;

    local($^W) = 0;  # IO::Socket::INET can be noisy
    my $sock = $self->socket_class->new(PeerAddr => $host,
                                        PeerPort => $port,
                                        LocalAddr => $self->{ua}{local_address},
                                        Proto    => 'tcp',
                                        Timeout  => $timeout,
                                        KeepAlive => !!$self->{ua}{conn_cache},
                                        SendTE    => 1,
                                        $self->_extra_sock_opts($host, $port),
                                       );

    unless ($sock) {
        # IO::Socket::INET leaves additional error messages in $@
        my $status = "Can't connect to $host:$port";
        if ($@ =~ /\bconnect: (.*)/ ||
            $@ =~ /\b(Bad hostname)\b/ ||
            $@ =~ /\b(certificate verify failed)\b/ ||
            $@ =~ /\b(Crypt-SSLeay can't verify hostnames)\b/
        ) {
            $status .= " ($1)";
        }
        die "$status\n\n$@";
    }

    # perl 5.005's IO::Socket does not have the blocking method.
    eval { $sock->blocking(0); };

    $sock;
}

Então, acho que o que estou procurando aqui é uma de duas coisas

Ou: (A) Existe uma maneira nova/melhor/mais correta de fazer o Perl ignorar os certificados SSL? ou (B) Existe uma maneira de importar um certificado SSL autoassinado de outro host para o Ubuntu para que o script Perl reconheça e confie nele? Alternativamente: (B-2) Existe uma maneira de fazer o Ubuntu reconhecer a Autoridade de Certificação do Active Directory do Windows, de modo que eu possa emitir certificados SSL da minha CA para os sistemas em questão e reconhecê-los pelos scripts Perl?

Agradecemos antecipadamente a todos!

Responder1

$ENV{PERL_LWP_SSL_VERIFY_HOSTNAME} = 0

Este foi um bug no LWP (CVE-2014-3230) que foi corrigido em versões mais recentes. PERL_LWP_SSL_VERIFY_HOSTNAME é usado apenas para omitir a verificação do nome do host no certificado, não na cadeia de certificados. Mas, como você está usando uma verificação da cadeia de certificados autoassinada, falhará.

Esta opção foi introduzida apenas para a migração do antigo backend Crypt::SSLeay para o novo backend IO::Socket::SSL. Crypt::SSLeay não suporta verificação do nome do host (e, portanto, está aberto para ataques man-in-the-middle), enquanto IO::Socket::SSL suporta. Com o LWP versão 6, o backend padrão é IO::Socket::SSL.

Para desabilitar completamente a verificação do conjunto de certificados SSL_verify_mode => SSL_VERIFY_NONE(você precisa use IO::Socket::SSLter acesso à constante SSL_VERIFY_NONE, ou apenas usar 0) no ssl_opts do LWP. Não há variável de ambiente para fazer isso.

Exemplo:

use LWP::UserAgent;
use IO::Socket::SSL;
my $ua = LWP::UserAgent->new(..., ssl_opts => { SSL_verify_mode => SSL_VERIFY_NONE });
$ua->get(...); # or $ua->post(...) or $ua->request(...)

Infelizmente, não consigo ver nenhum uso de LWP no script que você mencionou, então não vejo onde corrigi-lo.

Quanto às suas opções B:

(B) Existe uma maneira de importar um certificado SSL autoassinado de outro host para o Ubuntu para que o script Perl o reconheça e confie nele? Alternativamente: (B-2) Existe uma maneira de fazer o Ubuntu reconhecer a Autoridade de Certificação do Active Directory do Windows, de modo que eu possa emitir certificados SSL da minha CA para os sistemas em questão e reconhecê-los pelos scripts Perl?

Você deve ser capaz de usar a variável de ambiente PERL_LWP_SSL_CA_FILE para especificar um arquivo quais CAs ou certificados autoassinados você aceita como confiáveis.

Responder2

Acho que é um problema de versão Perl, verifique qual versão Perl você usou anteriormente para executar esse script.

O que tenho certeza é que o Ubuntu instala a versão estável mais recente de cada software. Tomemos, por exemplo, se você tem um script python3 que roda no ubuntu 12.04, ele pode não funcionar no ubuntu 14.04, e a razão para isso é que o primeiro tem python 3.2, quando o último tem a versão python 3.4.

Presumo que o mesmo aconteça com seu script Perl, verifique a versão Perl e a nota de lançamento da nova versão.

informação relacionada