Você é afetado pela CVE-2019-14899? Uma lista de verificação para o kernel

Um scanner marca a CVE-2019-14899 numa máquina que usa uma VPN há anos, e o primeiro impulso é declarar a VPN quebrada. É o enquadramento errado. O problema divulgado diz respeito a um atacante na rede local da vítima que infere informações sobre certas conexões TCP, não a um site que descriptografa o seu túnel.

Percorra as quatro verificações abaixo em ordem. Cada uma ou estreita o problema ou encerra a investigação.

Verificação 1: o aviso cobre o seu kernel

Consulte o registo da sua própria distribuição, não o resumo da data de lançamento de um blog. A página de segurança do Ubuntu para esta CVE lista o pacote linux genérico para 18.04 LTS como vulnerável com a correção adiada, e acompanha outros pacotes do kernel em linhas separadas. Faça corresponder a versão em execução e o pacote do kernel à linha correta. Um número de versão que parece familiar não é uma correspondência.

Um achado do scanner significa que o identificador se aplica a algo no seu inventário. Não significa que um dispositivo vizinho tenha explorado a máquina.

Verificação 2: quem é o atacante no modelo

O modelo de ameaça assume um atacante adjacente que pode interagir com a rede de acesso da vítima. É uma posição concreta, não um serviço remoto qualquer a quem desagrada o seu nó de saída. Se os utilizadores se ligam de um café, a suposição é realista; se estão atrás de uma LAN corporativa gerida, é outra conversa.

Mantenha aberta a questão da confiança na rede local mesmo quando o túnel está cifrado. A cifra responde a uma pergunta diferente da adjacência.

Verificação 3: em que camada confia

Um HTTPS validado corretamente fornece a sua própria proteção para os registos de aplicação, e o TLS 1.3 autentica esses dados de ponta a ponta. Não promete que um atacante não possa interromper a conexão TCP subjacente. Uma aplicação pode, portanto, ser segura de ler e ainda assim interrompível, e a interrupção não é o mesmo resultado que a revelação. Separe as duas antes de avaliar o risco.

Essa distinção importa para o relatório. Converte uma afirmação vaga de que a VPN é insegura numa declaração delimitada sobre o que um atacante adjacente poderia observar ou interromper.

Verificação 4: que mitigação implementou realmente

A divulgação discute mitigações de encaminhamento e filtragem e é explícita quanto aos seus limites, incluindo a filtragem de caminho inverso e as rotas assimétricas. Não cole um valor sysctl em cada host VPN e diga que está resolvido. A filtragem de caminho inverso interage com o encaminhamento, pelo que um valor que ajuda uma topologia pode quebrar outra.

A verificação é um comando, não uma caixa de seleção. sysctl net.ipv4.conf.all.rp_filter mostra o valor global, e sysctl net.ipv4.conf.tun0.rp_filter mostra o valor por interface que realmente se aplica. Leia ambos antes e depois de qualquer alteração.

Use as orientações da distribuição e o seu próprio desenho de encaminhamento, e depois confirme a definição na interface que transporta o túnel, não num ficheiro que ninguém carregou.

O que anotar

Anote a suposição do atacante adjacente, o pacote do kernel em execução, a linha do aviso que correspondeu, a mitigação implementada e onde se aplica, e as proteções de aplicação existentes. Acrescente a data em que verificou o aviso, porque essas páginas mudam. Essa combinação é uma avaliação defensável.

Uma data de lançamento do sistema operativo e uma ligação VPN a funcionar não são uma avaliação. São dois factos que por acaso são fáceis de recolher.