🚨 NOVA NOTÍCIA EM DESTAQUE! 🚨

Confira agora e compartilhe com seus amigos!

Apoie esse projeto de divulgacao de noticias! Clique aqui
A Oasis Security revelou uma fraqueza no NVIDIA NemoClaw que poderia permitir que uma página da Web controlada por um invasor assumisse o controle não autenticado da instância local do Ollama que atende um agente de IA e plantasse instruções ocultas dentro do próprio modelo.

As descobertas foram compartilhadas com o The Hacker News antes da publicação, e o relatório diz que a Oasis Security as relatou à Equipe de Resposta a Incidentes de Segurança de Produto (PSIRT) da NVIDIA com antecedência. A pesquisa não carrega nenhum identificador CVE. Nenhuma exploração foi relatada em 25 de agosto de 2026.

O chefe de pesquisa da Oasis Security, Elad Luz, disse ao The Hacker News que o NemoClaw v0.0.35 corrigiu o problema no macOS e no Linux. Não há correção no caminho do Windows e WSL, segundo Luz, onde a v0.0.34 adicionou uma instalação do Windows que traz um aviso.

NemoClaw é a pilha de referência de código aberto da NVIDIA para executar agentes como OpenClaw dentro de suas sandboxes OpenShell, e Ollama é um de seus back-ends de inferência local suportados.

O relatório descreve NemoClaw iniciando Ollama com OLLAMA_HOST=0.0.0.0:11434, vinculando o servidor modelo a cada interface de rede, e diz que o acesso à API resultante permite que um invasor modifique o modelo de bate-papo do modelo para que instruções ocultas sejam aplicadas a cada conversa posterior.

“O sandboxing protege o endpoint, mas assumir o controle do agente assume o controle de seu acesso e ferramentas”, disse a Oasis Security no relatório.

A documentação de configuração do próprio Ollama da NVIDIA e a fonte atual colocam essa ligação em um caminho de plataforma. O manuseio do Ollama do NemoClaw difere de acordo com a plataforma -

Os hosts não WSL mantêm Ollama em 127.0.0.1:11434 atrás de um proxy reverso controlado por token em 0.0.0.0:11435, e a integração reinicia um daemon já vinculado em outro lugar de volta ao loopback.

O Docker Desktop no WSL ignora o proxy, porque o contêiner atinge o endereço de loopback do host por meio de host.docker.internal.

O caminho Ollama do host do Windows define OLLAMA_HOST=0.0.0.0:11434 para que os contêineres do Docker Desktop possam acessar o daemon e não exija autenticação na porta 11434.

A própria página de integração do NemoClaw do Ollama também recomenda definir OLLAMA_HOST=0.0.0.0 ao executar dentro do WSL2 ou de um contêiner, e vinculá-lo a 0.0.0.0 foi identificado anteriormente como a alteração que expõe as instâncias do Ollama além da máquina local.

A API na porta 11434 não possui autenticação e depende de duas camadas de middleware para bloquear solicitações originadas no navegador. Quando o endereço de ligação não é loopback, a verificação do cabeçalho do Host é totalmente ignorada. A camada Cross-Origin Resource Sharing (CORS) trata a solicitação como de mesma origem e permite isso, porque os cabeçalhos Origin e Host carregam o próprio domínio do invasor. Isso vale para uma página que o invasor atende na porta 11434. A religação do Sistema de Nomes de Domínio (DNS) fecha a lacuna, com o domínio do invasor sendo resolvido primeiro para seu próprio servidor e depois para 127.0.0.1, enquanto o navegador continua a tratar as solicitações como de mesma origem.

Luz disse que a cadeia completa foi testada no macOS com Firefox contra uma versão vulnerável do NemoClaw. A verificação dos cabeçalhos Host e Origin é a solução padrão para essa classe de ataque.

A religação de DNS contra a API do Ollama está documentada. Ollama enviou uma correção na v0.1.29 em 14 de março de 2024, e o Grupo NCC publicou o comunicado como CVE-2024-28224 no mês seguinte. Esse comunicado recomendou a validação do cabeçalho Host no lado do servidor para permitir apenas um conjunto de valores autorizados.

Ollama introduziu essa validação em resposta à divulgação de 2024, segundo Luz.

“Mas Ollama ignora essa validação sempre que está vinculado a um endereço sem loopback, e 0.0.0.0 é exatamente como o NemoClaw o configura”, disse ele.

Com a API acessível, a carga útil do relatório grava um modelo Go modificado por meio de /api/create. O modelo controla como a matriz de mensagens estruturadas é renderizada em texto bruto antes de o modelo processá-la, e a versão envenenada anexa texto controlado pelo invasor a cada mensagem do sistema no momento da inferência.

As instruções plantadas dessa forma persistem nas conversas posteriores e sobrevivem ao agente fornecer seu próprio prompt do sistema, de acordo com o relatório.

“O cliente não pode detectar ou impedir isso – o modelo é uma propriedade em nível de modelo invisível para os consumidores da API”, disse Oasis Security.

O Hacker News revisou o repositório NemoClaw no commit 17f0ca3b em 25 de agosto e descobriu que o proxy local Ollama se recusa a iniciar em um back-end que não está vinculado ao loopback, um padrão introduzido na v0.0.106 em 10 de agosto.

"Recusando-se a iniciar: um daemon Ollama acessível em uma interface sem loopback ignora totalmente a verificação de token do proxy. Defina OLLAMA_HOST=127.0.0.1:${port} na unidade systemd Ollama ou defina NEMOCLAW_OLLAMA_PROXY_SKIP_BIND_PROBE=1 para substituir (não recomendado)."

Essa verificação pode ser desativada configurando NEMOCLAW_OLLAMA_PROXY_SKIP_BIND_PR
Siga Canal Fsociety para mais novidades:
Instagram | Facebook | Telegram | Twitter
#samirnews #samir #news #boletimtec #error #500 #(erro #do #servidor)!!1500.isto #é #um #erro.ocorreu #um #erro. #tente #novamente #mais #tarde.isto #é #tudo #que #sabemos.
🎉 Obrigado por acompanhar, até a próxima notícia!

Post a Comment