Falhas no KSMBD: confirme o servidor SMB antes de tratar todo Linux como exposto

Duas falhas de execução remota no KSMBD foram divulgadas publicamente antes de haver correções no kernel principal, segundo a reportagem, com nota 9,0 atribuída pela Zero Day Initiative.[7] O componente afetado é o servidor SMB implementado no kernel, não qualquer máquina Linux nem automaticamente o Samba em espaço de usuário.[7] Essa diferença deve ser o primeiro filtro da resposta.

O que muda para quem desenvolve

A ZDI-CAN-33774 possui um caminho anterior à autenticação em um servidor KSMBD acessível pela porta 445, relacionado a uma condição de corrida na atribuição de handlers e ao processamento de mensagens SMB1 e SMB2.[7] A mesma descrição inclui uma escrita fora dos limites quando o atacante já tem acesso a um compartilhamento.[7]

A ZDI-CAN-33549 depende de SMB Direct, interface RDMA, inclusive por meio do driver de software rxe, e compartilhamento gravável com esse transporte negociado.[7] Nesse caso, descritores inconsistentes podem provocar underflow em um contador e cópia além do espaço alocado.[7]

Minha análise é que há duas decisões operacionais diferentes. Uma trata da exposição de rede de um serviço anterior à autenticação. A outra exige conferir também transporte e permissões. Agrupar tudo em um único alerta de Linux vulnerável elimina justamente as informações necessárias para conter o risco.

Como aplicar

Faça a triagem por host ou imagem de appliance, registrando quatro respostas: KSMBD está presente, está em execução, quem alcança a porta 445 e quais compartilhamentos são graváveis. Depois acrescente a situação de SMB Direct e RDMA.

Use inventário e configuração efetiva para distinguir componente disponível de serviço ativo. Caso o serviço não seja necessário, avalie desativá-lo de forma controlada. Se for necessário, proponho restringir a conectividade aos consumidores indispensáveis enquanto se acompanha a correção da distribuição.

Um teste de contenção não precisa enviar mensagens de exploração. A partir de uma origem não autorizada, verifique que o acesso ao serviço é negado. De uma origem autorizada, valide uma operação legítima e confirme que a mudança não interrompeu o consumidor esperado.

Registre a contenção como contenção, com escopo de rede e data. Isso permite revisá-la depois sem confundi-la com instalação de patch.

Cuidados e limites

Havia notícia de proposta de correção para um dos casos, mas não confirmação suficiente de proteção amplamente disponível.[7] Uma discussão de patch não equivale ao kernel instalado e carregado no ambiente.

A divulgação foi contextualizada pela política do kernel para problemas encontrados por ferramentas de IA, tratados como públicos nas listas dos subsistemas.[7] O ponto prático é acompanhar a janela entre divulgação, correção na origem e distribuição efetiva, sem prometer que essas etapas já terminaram.

Fonte

[7] Fonte: The Hacker News