Vulnerabilidades do kernel Linux não patches [fechadas

Question

Recentemente, descobri que existem várias vulnerabilidades no kernel Linux que permitem a escalada de privilégios, que ainda não foram corrigidas nas principais distribuições e têm explorações públicas nas fontes usuais. Por exemplo, eu poderia se enraizar em qualquer um dos meus sistemas completamente atualizados do Ubuntu 10.04 usando isto Exploração muito simples.

Isso meio que me preocupa. Surgem duas perguntas:

• Por que o kernel Linux não foi remendado para uma exploração que existe há 2 semanas? Isso parece uma situação muito perigosa para mim.

• Existe uma maneira segura de dar a alguém uma conta de convidado na minha máquina, dada essa situação? Ou devo assumir que uma conta de convidado é mais uma segurança simbólica e apenas dar contas às pessoas em que eu realmente confio.

Answer 1

Na verdade, um patch foi escrito em 14 de setembro e pode ser encontrado aqui e aqui. No entanto, esse patch não foi fundido para a linha principal. A programação do kernel é muito difícil. Um patch pode quebrar a compatibilidade ou fazer com que o sistema se comporte incorretamente. A Microsoft geralmente leva 1 mês para escrever um patch para qualquer coisa, mesmo no bloco de notas.

Muitas vezes, um invasor pode comprometer um processo no nível do usuário, como um de seus daemons (irrealircd ou sendmail). Ou ainda mais provavelmente um aplicativo da Web como o WordPress ou o PHP-NUKE. Nesse ponto, o invasor possui uma conta de usuário e pode obter root se precisar. Portanto, a exploração de escalada de privilégios como essa é frequentemente usada em uma corrente com outras façanhas.

Em uma nota mais preocupante, Toravolds é notório por remendos silenciosos. Este também é um passatempo que A Microsoft gosta.

Answer 2

A maior parte do mais - por falta de uma palavra melhor - distribuições de hardcore como Gentoo e Slackware foram corrigidas por uma semana ou mais. Além disso, certas configurações não eram vulneráveis, e outras eram tecnicamente vulneráveis, mas não com as façanhas publicadas.

Para os ultra-paranóides, aqui estão algumas coisas que você pode fazer:

• Patch seu próprio kernel direto do ramo Git. Isso é algo bastante difícil de descobrir a primeira vez, mas na verdade fácil de manter quando for configurado. Sua distração preferida provavelmente mantém suas próprias filiais públicas para seus kernels, que provavelmente se fundiram na filial correta publicada há quase duas semanas para testes. Mesmo que eles estejam esperando que ele entre na liberação oficial a montante, o GIT facilita a mesclagem de ramos de muitas fontes diferentes, para que você não precise esperar.
• Configure seu kernel para o mínimo de recursos que você realmente precisa. Entendo que essa vulnerabilidade não é um problema se certas opções necessárias para a virtualização estiverem desativadas. Por outro lado, os kernels de distro -estoque permitem que tudo seja capaz de atender a todos. Além disso, a exploração publicada depende da tabela de símbolos do kernel disponível em /proc /kallsyms. Essa opção pode ser desligada e não há razão para que todos os todos precisem.
• Use o controle de acesso obrigatório para fornecer aos usuários de seus convidados e aplicativos expostos à Internet os privilégios mínimos necessários necessários.

A desvantagem de toda essa precaução é que você é mais provável que você quebre seu sistema, e é por isso que a maioria das distribuições orientadas para o usuário leva seu tempo com os testes.

Answer 3

De acordo com LWN.NET :

Para as distribuições mais orientadas para a comunidade (Debian, Fedora, OpenSuse, Ubuntu e outros), a resposta foi um pouco misturada. Ubuntu, Debian e Fedora se consertaram 17 de setembro Para ambos os bugs (ou, no caso do Debian, apenas um, pois sua distribuição estável ("Lenny") é baseada em 2.6.26 e, portanto, não é vulnerável CVE-2010-3301). O OpenSUSE ainda não lançou uma correção e nenhuma das distribuições secundárias que rastreamos (Gentoo, Mandriva, Slackware etc.) também lançou uma correção.

Portanto, se o seu Ubuntu estiver realmente atualizado, deve estar seguro muito cedo. Além disso, lembro -me de ver a atualização relativamente logo após o anunciado o bug.

Portanto, a correção está incorreta ou seu sistema não é atualizado corretamente e não foi por algo como duas semanas. As atualizações do kernel precisam de uma reinicialização do seu sistema.

Onde está a pergunta de programação, a propósito?