Os bastidores do fortalecimento do Firefox com Claude Mythos Preview
(hacks.mozilla.org)- A Mozilla construiu um pipeline para encontrar bugs de segurança reais em larga escala no Firefox, aumentando o sinal e reduzindo o ruído dos relatórios de segurança gerados por IA com melhorias no desempenho dos modelos e no harness
- No Firefox 150 release, foram corrigidos 271 bugs identificados pelo Claude Mythos Preview, e 149.0.2, 150.0.1 e 150.0.2 também incluíram correções relacionadas
- Entre os principais bugs divulgados estão um primitive de objeto falso causado pela remoção da inicialização de structs WebAssembly GC no JIT, um UAF no processo pai via condição de corrida em IPC, um problema de desserialização de NaN, um bug de rehash de 20 anos no XSLT e um overflow de bitfield de layout de 16 bits usando
rowspan=0 - Uma parte significativa dos bugs divulgados envolve escape de sandbox, assumindo um processo de conteúdo já comprometido que eleva privilégios para o processo pai com privilégios, cobrindo com análise por IA uma superfície de ataque difícil de encontrar apenas com fuzzing
- A Mozilla colocou um harness agêntico sobre sua infraestrutura de fuzzing existente para descartar suposições que não se reproduziam e validar hipóteses com casos de teste, e planeja integrar isso à integração contínua para escanear patches quando entrarem na tree
A mudança nos bugs de segurança do Firefox revelada por modelos de IA
- Até alguns meses atrás, relatórios de bugs de segurança gerados por IA enviados para projetos open source muitas vezes pareciam plausíveis, mas estavam errados, criando um custo assimétrico para os mantenedores
- No Firefox, a situação mudou drasticamente em pouco tempo, e a principal razão foi a melhora no desempenho dos modelos e nas técnicas de controlar, estender e combinar modelos com um harness para aumentar o sinal e filtrar o ruído
- A Mozilla normalmente mantém relatórios detalhados de bugs em sigilo por alguns meses mesmo após publicar avisos de segurança e distribuir correções, mas desta vez decidiu divulgar alguns relatórios considerando a urgência e o interesse em todo o ecossistema
- Os relatórios divulgados foram escolhidos entre vários subsistemas do navegador e, embora a seleção seja até certo ponto arbitrária, a profundidade e a diversidade dos relatórios mostram por que defensores precisam aplicar essa técnica
Principais bugs divulgados
- 2024918
- Por causa de uma verificação de equivalência incorreta, o JIT removeu por otimização a inicialização de uma struct WebAssembly GC viva, o que poderia criar um primitive de objeto falso ligado a leitura e escrita arbitrárias potenciais em código que já havia passado por amplo fuzzing interno e externo
- 2024437
- Um bug de 15 anos no elemento
<legend>, acionado por uma combinação sofisticada de casos de borda em áreas separadas do navegador, como limite de profundidade da pilha recursiva, propriedades expando e cycle collection
- Um bug de 15 anos no elemento
- 2021894
- Explorando de forma confiável uma condição de corrida em IPC, um processo de conteúdo comprometido podia manipular a contagem de referências do IndexedDB no processo pai, causando UAF e potencial escape de sandbox
- 2022034
- Um NaN bruto podia parecer um ponteiro de objeto JS com tag ao atravessar um limite de IPC, permitindo que a desserialização de double levasse a um primitive de objeto falso no processo pai e a escape de sandbox
- 2024653
- Um caso de teste complexo combinando loops de evento aninhados, listener de
pagehidee coleta de lixo causava UAF no setter de atributo do elemento<object>
- Um caso de teste complexo combinando loops de evento aninhados, listener de
- 2022733
- Ao empurrar milhares de hashes de certificado para o WebTransport, era possível ampliar uma condição de corrida em um loop de cópia com alta contagem de referências e provocar UAF no processo pai via IPC a partir de um processo de conteúdo comprometido
- 2023958
- Interceptando chamadas de função DNS da glibc para simular um servidor DNS malicioso e reproduzir um caso de borda no fallback de UDP para TCP, foi possível causar leitura além do buffer e vazamento de memória da pilha do processo pai durante o parsing de HTTPS RR e ECH
- 2025977
- Um bug de 20 anos no XSLT em que uma chamada reentrante de
key()causava rehash da tabela hash, liberava o backing store, mas o ponteiro bruto da entrada continuava sendo usado; era um entre vários problemas sec-high de XSLT corrigidos
- Um bug de 20 anos no XSLT em que uma chamada reentrante de
- 2027298
- Após modificar o color picker para simular uma seleção do usuário difícil de automatizar, um loop de evento aninhado era executado com eventos de entrada síncronos, reentrando no teardown do actor e fazendo com que ele fosse liberado durante o unwind do callback, causando UAF no processo de conteúdo
- 2023817
- Um processo de conteúdo comprometido podia enviar uma imagem de papel de parede arbitrária para ser decodificada no processo pai, o que, combinado com uma vulnerabilidade hipotética no decodificador de imagem, poderia levar a escape de sandbox
- Isso exigia um raciocínio difícil de automatizar no processo pai para determinar o nível de confiança da entrada
- 2029813
- No RLBox, tecnologia de sandboxing granular do Firefox 95, foi possível contornar o sandbox explorando uma brecha na lógica de validação que copia valores do lado não confiável para o lado confiável
- 2026305
- Um caso de teste muito pequeno que explora a semântica especial de
rowspan=0em tabelas HTML adicionou mais de65535linhas para contornar o clamping e causar overflow em um bitfield de layout de 16 bits, passando anos sem ser pego por fuzzers
- Um caso de teste muito pequeno que explora a semântica especial de
Escape de sandbox e camadas de defesa
- Uma parte considerável dos bugs divulgados envolve escape de sandbox, e para resultar em comprometimento completo da cadeia do Firefox eles precisariam ser combinados com outros exploits
- Esses relatórios assumem uma situação em que o processo em sandbox que renderiza conteúdo de sites já foi comprometido por outro bug, e código de máquina controlado pelo atacante tenta elevar privilégios para o processo pai com privilégios
- Ao criar escapes de sandbox, o modelo pode fazer patch no código-fonte do Firefox desde que o código modificado seja executado apenas dentro do processo em sandbox
- Esse tipo de bug é difícil de encontrar com fuzzing, e a Mozilla vem desenvolvendo técnicas como fuzzing de IPC com snapshots, mas a análise por IA conseguiu cobrir essa superfície importante de forma muito mais abrangente
- O que o modelo não encontrou também foi importante
- Nos últimos anos, pesquisadores de segurança enviaram vários relatórios sobre escapes de sandbox por meio de prototype pollution no processo pai com privilégios
- Em vez de corrigir os problemas um a um, a Mozilla aplicou uma mudança de arquitetura que congela prototypes por padrão
- Nos logs do harness havia muitos sinais de tentativas dessa rota de escape bloqueadas pelo design, confirmando o efeito direto do trabalho anterior de fortalecimento
Construindo um pipeline de fortalecimento de segurança com harness
- Nos últimos anos, a Mozilla conduziu internamente experimentos de auditoria de código com LLMs para analisar estaticamente código de alto risco com modelos como GPT 4 e Sonnet 3.5
- Os experimentos iniciais mostraram potencial, mas a taxa de falsos positivos era alta demais para escalar
- A situação mudou com o surgimento de harnesses agênticos capazes de detectar problemas de segurança de forma confiável
- Eles conseguem encontrar bugs reais
- Conseguem descartar suposições que não se reproduzem
- Com a interface e as instruções certas, conseguem criar e executar casos de teste reproduzíveis para validar dinamicamente hipóteses de bugs no código
- Depois de corrigir os problemas iniciais enviados pela Anthropic em fevereiro, a Mozilla construiu seu próprio harness sobre a infraestrutura de fuzzing existente
- No início, foram feitos experimentos em pequena escala com Claude Opus 4.6 para procurar escapes de sandbox
- Só esse modelo já identificou um número considerável de vulnerabilidades antes desconhecidas que exigiam raciocínio complexo sobre código de um engine de navegador multiprocesso
- No começo, o processo era acompanhado diretamente no terminal, com ajuste em tempo real de prompts e lógica
- Depois que o funcionamento se estabilizou, o trabalho foi paralelizado em várias VMs efêmeras, cada uma procurando bugs em arquivos-alvo específicos e registrando os resultados em buckets
- O subsistema de descoberta por si só não era suficiente
- Era necessário integrar todo o ciclo de vida do bug de segurança, incluindo o que procurar, onde olhar e como tratar os resultados
- Isso incluía deduplicação com problemas existentes, rastreamento de bugs, triage e distribuição de correções
- O modelo é o primitive central que move o harness, mas para ser útil em escala é preciso o pipeline inteiro
- O harness pode ser reutilizável entre projetos, mas o pipeline varia de projeto para projeto conforme o significado da codebase, as ferramentas e os processos
- Foi necessário bastante trabalho iterativo com um loop de feedback estreito junto ao processo pelo qual os engenheiros do Firefox tratam os bugs recebidos
Claude Mythos Preview e o efeito da troca de modelo
- Quando o pipeline end-to-end está pronto, trocar para outro modelo quando um novo aparece se torna simples
- A Mozilla já havia encontrado vários bugs graves com modelos abertos, e graças a esse pipeline pôde aproveitar imediatamente a chance de avaliar o Claude Mythos Preview
- O upgrade do modelo aumentou a eficácia de todo o pipeline
- Encontra melhor bugs potenciais
- Cria melhor casos de teste de prova de conceito para demonstrar o bug
- Organiza melhor a patologia e o impacto
- Além de corrigir 271 bugs identificados pelo Claude Mythos Preview no Firefox 150 release, correções relacionadas também foram incluídas em 149.0.2, 150.0.1 e 150.0.2
- Internamente, bugs continuam sendo encontrados também por outros métodos, e, como em outros projetos, os relatórios externos também aumentaram bastante nos últimos meses
- Todos os bugs exigiram atenção cuidadosa para serem corrigidos adequadamente, e os últimos meses envolveram muito trabalho e longas jornadas para acompanhar uma escala sem precedentes
- Mais de 100 pessoas participaram com contribuições de código para entregar o Firefox mais seguro possível, incluindo não só escrita e revisão de patches, mas também construção e expansão do pipeline, triage, testes das correções e gestão do processo de release de cada bug
Principais lições
- Qualquer pessoa que desenvolva software hoje pode usar modelos modernos e harnesses para encontrar bugs e fortalecer código
- É possível começar com prompts simples, observar e iterar
- O prompt inicial não era muito diferente do método mostrado neste vídeo
- Ao longo das iterações, foram adicionadas muitas ferramentas e orquestração para otimizar e expandir o pipeline, mas o núcleo do loop interno era: “há um bug nesta parte do código; encontre-o e crie um caso de teste”
- O Firefox ainda não esgotou todos os bugs potenciais, mas a Mozilla está satisfeita com a trajetória atual
- Atualmente, o escaneamento se concentra em áreas específicas de código, como arquivos e funções, escolhidas em geral por uma mistura de julgamento humano e sinais automáticos
- Num futuro próximo, o plano é integrar essa análise ao sistema de integração contínua para escanear patches quando entrarem na tree
- Os modelos se adaptam com flexibilidade ao formato de contexto fornecido, e espera-se que o escaneamento baseado em patches funcione tão bem quanto ou melhor do que o escaneamento baseado em arquivos
- O momento atual é arriscado, mas também cheio de oportunidades, e é preciso agir em conjunto para tornar a internet mais segura
Perguntas frequentes
-
Por que “271 bugs” é diferente do número nos avisos de segurança
- Na página de avisos de segurança, bugs reportados internamente são agrupados em CVEs “rollup”, sob os quais vários bugs ficam reunidos
- A página é gerada a partir do yaml no repositório foundation-security-advisories, que é o local oficial de atribuição de CVEs
- Alguns navegadores não criam identificadores CVE para problemas encontrados internamente, mas a Mozilla os divulga para fornecer informação da forma mais transparente possível
- O Firefox 150 tinha 3 rollups internos
- CVE-2026-6784: 154 bugs
- CVE-2026-6785: 55 bugs
- CVE-2026-6786: 107 bugs
- A soma dos três rollups internos é 316, maior do que os 271 bugs anunciados como encontrados com Claude Mythos Preview
- A razão é que a equipe de segurança da Mozilla ataca o Firefox todos os dias e encontra novos bugs com uma combinação de sistema de fuzzing, inspeção manual e novo pipeline agêntico usando vários modelos
- Na release de abril, foram corrigidos 423 bugs de segurança no total
- Os 271 bugs anunciados duas semanas antes
- 41 bugs reportados externamente
- Os 111 restantes foram encontrados internamente e se dividem aproximadamente em três categorias
- Bugs encontrados por esse pipeline usando Claude Mythos Preview, mas corrigidos em outras releases e não no Firefox 150
- Bugs encontrados por esse pipeline usando outros modelos
- Bugs encontrados por outras técnicas, como fuzzing
- A Anthropic recebeu crédito direto por 3 CVEs, separados deste trabalho mais recente
- CVE-2026-6746
- CVE-2026-6757
- CVE-2026-6758
- Eles correspondem a correções de bugs que a Anthropic Frontier Red Team enviou para a Mozilla alguns meses antes, e cada um recebeu um CVE próprio segundo o procedimento normal
-
O significado das classificações de gravidade de segurança
- A Mozilla aplica security severity ratings, de critical a low, para indicar a urgência dos bugs
- sec-critical e sec-high são atribuídos a vulnerabilidades que podem ser acionadas por comportamentos comuns do usuário, como visitar uma página web
- Não há diferença técnica entre sec-critical e sec-high, mas sec-critical é usado apenas para problemas já divulgados publicamente ou conhecidos por terem sido explorados em ataques reais
- sec-moderate é atribuído a vulnerabilidades que normalmente seriam avaliadas como sec-high, mas exigem etapas anormais e complexas por parte da vítima
- sec-low é atribuído a bugs incômodos mais distantes de causar dano ao usuário, como um crash seguro
- As classificações dos 271 bugs anunciados no Firefox 150 foram as seguintes
- 180 sec-high
- 80 sec-moderate
- 11 sec-low
- A Mozilla considera bugs critical/high os mais importantes, mas também costuma priorizar bugs de segurança moderate e low para corrigir problemas de correção e aprofundar a defesa
-
A diferença entre sec-high ou sec-critical e um exploit real
- Um bug sec-high ou sec-critical não significa automaticamente um exploit prático
- Na maioria dos casos, um único bug critical/high não é suficiente para comprometer o Firefox
- O Firefox tem uma arquitetura de defesa em profundidade; por exemplo, mesmo explorando um bug no JIT, o resultado seria execução remota de código em um processo em sandbox e isolado por site
- Na prática, atacantes geralmente precisam encadear vários exploits para atravessar uma ou mais camadas de sandboxing e mitigações no nível do sistema operacional, como ASLR, até elevar privilégios
- A Mozilla normalmente não desenvolve exploits para verificar se um bug pode de fato ser usado por atacantes reais
- A classificação sec-high se baseia em sintomas previsíveis de crash, como use-after-free ou problemas de memória out-of-bounds relatados pelo AddressSanitizer
- O modelo de ameaça assume que, com esforço suficiente, esses bugs podem ser exploráveis
- Essa abordagem reduz o risco de falsos negativos na análise de explorabilidade e permite concentrar recursos em encontrar e corrigir mais vulnerabilidades
2 comentários
Comentários do Hacker News
Reforçando: bug é bug. “Potencial vulnerabilidade” também é bug, e uma vulnerabilidade precisa ter impacto de segurança validado por uma prova de conceito ou evidência equivalente
As palavras importam, e bugs também importam. Corrigir muitos bugs sempre foi importante e é algo que de fato já se faz há muito tempo, e isso por si só já é impressionante
O Mythos não escreveu provas de conceito para 271 vulnerabilidades nem demonstrou alcançabilidade de caminhos de código com impacto de segurança. O Mythos encontrou 271 bugs válidos, e isso já basta
Como contexto adicional, a Mozilla aplica severidade de segurança de critical até low para indicar a urgência do bug. sec-critical e sec-high são atribuídos a vulnerabilidades que podem ser disparadas por ações normais do usuário, como visitar uma página web; tecnicamente eles não distinguem entre os dois, mas sec-critical fica reservado para problemas já divulgados ou com exploração real conhecida
sec-moderate é para vulnerabilidades que normalmente seriam sec-high, mas exigem passos anormais e complexos da vítima, e sec-low é para bugs incômodos mais distantes de dano ao usuário, como crashes seguros
Dos 271 bugs anunciados no Firefox 150, 180 eram sec-high, 80 eram sec-moderate e 11 eram sec-low
Logo abaixo, a Mozilla diz que isso não significa o mesmo que exploit prático, mas ainda assim usa a palavra “vulnerability” também para sec-high. Na página de definições, até sec-low é classificado como “vulnerabilities” [2]
Palavras são ferramentas, e sua utilidade vem do significado coletivo. Fico curioso sobre de onde vem esse sistema de significado, se bate com o da Mozilla ou se é diferente
[1] https://hacks.mozilla.org/2026/05/behind-the-scenes-hardenin...
[2] https://wiki.mozilla.org/Security_Severity_Ratings/Client
Pelos nossos critérios, isso já é evidência prática suficiente para considerar uma vulnerabilidade de segurança, a menos que haja prova em contrário, e sempre tratamos bugs de fuzzing assim
Minha fonte é só experiência pessoal, e não posso compartilhar evidências
Eu tinha descartado o post anterior, não técnico, como propaganda descarada de produto para a Anthropic. O post vinculado no Mozilla Hacks é uma fonte melhor do que este artigo e é uma divulgação bem-vinda
Agora parece difícil negar que houve resultado real. A definição interna de “vulnerabilidade” da Mozilla aparentemente é mais ampla do que muita gente imagina intuitivamente, mas é bom que esses problemas sejam levados a sério e corrigidos
O Mythos é real, sim, mas parece que seria possível fazer o mesmo com Deepseek pro ou GPT 5.5
Fonte original: https://news.ycombinator.com/item?id=48051079
É melhor porque lista parte dos relatórios reais do Bugzilla que foram tornados públicos. Esse tema já tinha sido discutido antes, mas a parte sobre os relatórios de bug terem sido publicados é totalmente nova
A discussão anterior foi há 2 semanas e teve 36 comentários: https://news.ycombinator.com/item?id=47885042
Espero que chegue o dia em que os LLMs fiquem tão bons em encontrar e corrigir bugs que os engenheiros do Firefox possam se concentrar apenas em adicionar novos recursos
Não é sarcasmo. O Firefox merece ser mais usado. A maioria ao meu redor não usa Firefox porque “o Chrome faz quase tudo melhor”, e o Firefox tem dificuldade para competir com o roadmap dos outros navegadores
Às vezes também escrevo para o suporte dizendo que Firefox não é suportado ou que algum recurso não funciona direito. Quase nunca acontece nada, mas sinto que é algo que posso fazer para manter o navegador de algum modo no campo de visão
Se a IA corrigir todos os bugs, o que sobra além de manter compatibilidade de sintaxe com várias linguagens de build? Parece que no fim vão voltar a bagunçar o navegador
Se a Mozilla criasse um LLM ou harness proprietário, de uso interno, e com isso passasse o Chrome, seria outra história, mas isso também não parece muito realista
Minha esposa também usa Firefox como navegador principal depois que entendeu, com alguma explicação, como a experiência na internet pode ser diferente
Então eu preferiria que isso não fosse colocado como “monopólios são ruins e o Google é meio maligno, então use o azarão inferior”. Em tudo que joguei para ele, o Firefox foi uma experiência de primeira classe, e no mobile isso vale umas três vezes mais. De longe a melhor experiência de navegador móvel realmente útil
Os tickets vinculados são só alguns, então talvez a história mude ao ver os 271 itens individuais de fato, mas os que examinei eram todos bugs graves em código C++
O Firefox é escrito em várias linguagens e C++ representa só cerca de 25%, mas todos esses problemas parecem mexer com C++
Ainda falta ver se problemas mais sutis vão exigir verificadores mais específicos ou se o LLM vai conseguir imaginar sozinho outras condições de risco para validar
Na minha visão, boa parte desses bugs não é tanto algo exclusivo de C++, e sim algo que por acaso ocorreu em código C++. Mesmo Rust, por mais seguro que seja, não vai magicamente detectar problemas como TOCTOU
Ler isso junto com a postura do pessoal do Zig, que nem quer olhar bugs gerados por LLM para revisão, muda minha forma de ver quais tecnologias vou colocar na minha toolchain daqui para frente
Alguns projetos estão sendo inundados pelo primeiro caso, então são necessárias proteções para que isso não vire praticamente um ataque de negação de serviço contra os mantenedores
Quando eu estava na PalmSource, tentei conseguir orçamento para ferramentas de análise estática de código como CoVerity e Fortify, mas a gestão dizia que “era caro demais”
Passei mais 1 ano reduzindo o custo e montando uma proposta limitada ao scan da stack de rede, e aí disseram que “é baseado em BSD e BSD é inerentemente seguro”. Nenhuma das duas coisas é verdade
Acabei saindo da empresa e indo para a Mozilla, e havia comentários
/* flawfinder ignore */espalhados pelo códigoMeu palpite é que o Mythos simplesmente ignorou as diretivas
flawfinder ignoree reportou vulnerabilidades já conhecidas no códigoFico curioso sobre o impacto disso em ferramentas de análise estática. A natureza é bem diferente, mas às vezes elas atingem o mesmo objetivo
Ferramentas de análise estática podem ser lentas e gerar muitos falsos positivos. Se esses modelos ficarem bons e baratos o suficiente, fico pensando se as pessoas quase vão parar de procurar análise estática
Usar ferramentas de coding com LLM para ir limpando a saída de análise estática funciona muito bem, e também é uma boa ideia adicionar guardrails que forcem a não deixar problemas para trás. Como uma checagem de CI para confirmar que está tudo limpo
Falsos positivos variam conforme a ferramenta. Eu costumo evitar ferramentas que só geram ruído, e normalmente elas permitem desligar regras muito barulhentas. Ou você pode simplesmente pedir ao LLM para corrigir todos os problemas. Se corrigir sair mais barato do que discutir com as regras, então é só corrigir. Antes isso era muito caro porque exigia trabalho humano direto, mas agora não é mais
Usei isso recentemente ao atualizar uma codebase em Ansible que não era mexida havia anos. Havia centenas de problemas do ansible-lint, a maioria avisos de depreciação e alertas não fatais, e 10 minutos depois eram 0. Não eram problemas gravíssimos, mas eram uma espécie de dívida técnica. Eu provavelmente não corrigiria centenas de alertas manualmente, mas se uma varinha mágica pode fazê-los sumir de uma vez, não há motivo para não fazer. Agora ajustei os guardrails para sempre rodar ansible-lint e corrigir os problemas, e isso só leva alguns segundos a mais
Não há dúvida de que ferramentas de análise estática são mais rápidas e baratas, então escalam melhor em codebases enormes e talvez consigam generalizar o método do LLM
[0] https://lwn.net/Articles/1068968/
Eu mantenho as ferramentas de análise estática usadas no CI do Firefox. Para colocar um patch na nossa árvore, você precisa corrigir todos os casos, sejam falsos positivos ou verdadeiros positivos, ou marcá-los como não problemáticos. Em outras palavras, você precisa tolerar 0 positivos, o que é um padrão bem rígido
Isso é um trade-off consciente. Para manter uma relação sinal-ruído alta o bastante a ponto de as pessoas não ignorarem, não comentarem tudo para sumir ou simplesmente não deixarem de executar a ferramenta, é preciso enfraquecer a análise e aceitar alguns falsos negativos. Quase toda ferramenta de análise estática precisa equilibrar isso
Em contraste, as IAs de uso comum recebem muito mais liberdade. É quase fundamental permitir que alucinem falsos positivos, e isso também é parte importante do poder delas. Por isso são necessárias várias camadas de validação e verificação por cima. Pode ser lento e você não pode dizer “isso pega 100% dessa forma específica de erro”, mas ainda assim encontra muita coisa
Tenho um dado pontual: minha análise assumiu erroneamente que um caso tinha baixa chance de gerar bug real e também parecia incômodo de implementar, então não o cobri. Não sei se foi o Opus ou o Mythos, mas ele começou a reportar vulnerabilidades originadas nesse caso, e eu corri para expandir a análise e cobrir a lacuna. Levou bastante tempo para implementar e, quando escaneei a árvore inteira, o Claude já tinha encontrado todos os problemas importantes que havia reportado. A análise estática encontrou alguns a mais, mas honestamente ainda não sei se algum deles é de fato acionável
Ainda assim, acho que análise estática tem valor. Algumas ocorrências do padrão de problema talvez ainda sejam alcançáveis por caminhos complicados demais para a IA montar hoje. Elas também podem virar problemas reais quando outro código mudar. Vale a pena corrigir tudo agora por essas duas razões, e também por uma razão menos importante: evitar que a IA perca tempo tentando explorá-las. Ao mesmo tempo, também é verdade que o equilíbrio entre custo e benefício claramente mudou
Os dois podem cooperar. Eu poderia relaxar meus critérios para que a ferramenta de análise emitisse relatórios adicionais sobre problemas suspeitos, deixando explícita a expectativa de que podem ser falsos positivos, e então passar essa lista para a IA validar. Essencialmente, alimentar uma máquina de slop com slop para que ela filtre de forma não determinística as pepitas no meio
Dá o que pensar
No Mission Impossible mais recente, para salvar o mundo é preciso recuperar de um submarino russo afundado o software original de uma AGI super-humana que escapou
O Luther, ao receber o código-fonte original, escreve imediatamente uma “poison pill” que mata a IA de uma vez só. Eu me perguntava como esse código mágico tinha sido escrito, mas agora entendi. O Luthor simplesmente jogou o código-fonte no prompt do Mythos e pediu um exploit fatal imutável
Fico curioso sobre como as pessoas veem se os LLMs vão tornar o software mais seguro ou menos seguro daqui a 5 anos
Já existia uma tendência de portar manualmente para Rust antes do surgimento dos LLMs. Agora, com LLMs, isso deve ficar mais fácil e rápido. O valor de longo prazo vai vir de atacar a montanha de dívida técnica representada pelas codebases legadas em C/C++. Esses códigos respondem pela esmagadora maioria dos exploits de memória, buffer overflows e outros problemas, e continuam aparecendo em codebases importantes apesar de décadas de atenção
O fato de a Mozilla ter encontrado esses problemas se apoia no trabalho de engenheiros muito competentes que passaram 25 anos tentando fazer a coisa certa e evitar esse tipo de falha com todas as ferramentas disponíveis. Tenho enorme respeito por essa equipe e pelo que contribuíram ao longo dos anos para melhorar ferramentas, testes e práticas de verificação. O problema não é a dedicação nem a competência deles
Pegar um sistema existente com bom conjunto de testes, boa documentação e boa especificação e produzir uma implementação substituta drop-in virou algo revisável. Há alguns anos isso implicaria custo e risco enormes de projeto, mas agora é algo que você pode tentar numa tarde de sexta-feira. No pior caso, falha; no melhor, você ganha uma implementação muito melhor
Ainda estamos no começo e código gerado por LLM ainda tem muitos problemas de qualidade. Mas a taxa de acerto e de erro provavelmente vai melhorar com o tempo
Quando mais gente tem acesso a mais ferramentas, mais coisas são produzidas, em uma faixa mais ampla
Mas isso também significa que, em projetos que não aplicarem essas ferramentas, black hats terão mais facilidade para encontrar oportunidades de exploração
Opiniões no Lobste.rs
Seria bom se também publicassem os prompts e outros recursos usados nesse trabalho
Seria útil incluir os prompts nos relatórios de bugs ou nos registros de correção para que isso possa ser reproduzido
Como também mencionaram modelos não-Mythos, parece que parte desse trabalho poderia ser imediatamente útil para outras pessoas
Basicamente, basta dizer “revise este projeto sob a perspectiva de problemas de segurança, começando por (arquivo), e liste todos os caminhos possíveis”, e depois continuar com “verifique este relatório e crie uma prova de conceito” para cada item
Hoje em dia, usando o Opus, está mais difícil não encontrar algo desse jeito
Independentemente de como se diga, isso é realmente impressionante
Encontraram 271 problemas de segurança com o Mythos e 423 no total
Desses, 180 eram de alta gravidade, e alguns dos problemas de segurança tinham 20 anos
Fica implícito algo como o resultado de que o Mythos encontrou “271 bugs” em código que já havia sido escaneado da mesma forma antes com o 4.6, mas o texto não diz exatamente isso
Fico me perguntando se também houve mudanças simultâneas no harness de pesquisa
A parte “um dos vários problemas sec-high que corrigimos estava relacionado a XSLT” parece ter sido incluída por causa da polêmica sobre a remoção do XSLT
O que mais me deixa curioso aqui é quantos falsos positivos também foram reportados
Fico pensando se o modelo reportou algo como o dobro de vulnerabilidades potenciais, e se o que aparece aqui são apenas as confirmadas
Também não sei se o modelo chega a reproduzir os problemas antes de reportá-los
Pelos problemas tornados públicos, dá para ver comentários que parecem tentar reproduzi-los, mas também pode ser algo feito por um bot que já existia
Não conheço bem como o Firefox costumava lidar com esse tipo de trabalho nem como está fazendo isso agora com IA, então uma explicação mais detalhada seria muito interessante