O apocalipse de bugs de IA já começou oficialmente

Autoria: Better Stack · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: The AI Bug Apocalypse Has Officially Started · Canal: Better Stack · 08:48 · Assistir no YouTube

Tópicos: Cibersegurança e segurança de software, Open source e ecossistemas de software

Resumo

Um erro da Trend Micro’s Zero Day Initiative expôs relatórios de vulnerabilidades ainda não corrigidas na lista pública do Linux, incluindo dois bugs críticos no código SMB com possibilidade de execução remota de código. O episódio acontece em meio a uma onda de divulgações de falhas chamada de Black October, que também inclui vulnerabilidades no PHP, GitLab e Node.js. A IA está acelerando a descoberta de bugs, mas isso transfere o gargalo para a triagem, a correção e a distribuição de patches — e também pode ajudar atacantes a agir mais rápido. A recomendação prática é manter atualizações contínuas, priorizar sistemas expostos à internet e substituir o que não puder mais ser corrigido.

Pontos-chave

Relatórios de vulnerabilidades do Linux foram enviados por engano à lista pública, antes de as falhas receberem correções.
Dois bugs no código SMB do kernel Linux receberam gravidade 9,0 e podem permitir execução remota de código.
A onda de divulgações conhecida como Black October inclui falhas no PHP, GitLab e Node.js, entre outras.
A IA pode encontrar vulnerabilidades em grande escala, fazendo a triagem e a aplicação de correções se tornarem novos gargalos.
Relatórios citados no vídeo apontam centenas de falhas encontradas em SharePoint e mais de mil corrigidas em versões do Chrome.
A divulgação de patches também ajuda atacantes a identificar mudanças e reduz o tempo entre uma correção e a exploração da falha.
Organizações devem tratar a aplicação de patches como uma atividade contínua, priorizando o que está exposto à internet.
O vídeo recomenda atualizar PHP, acompanhar as correções de SMB no kernel, desativar KSMBD se não for usado e atualizar GitLab e Node.js.

Capítulos

Início	Capítulo	Resumo
00:00	Exposição de vulnerabilidades do Linux	Um envio equivocado expõe relatórios de falhas do kernel Linux, incluindo dois bugs graves no código SMB.
03:04	Black October e a onda de divulgações	O vídeo contextualiza o incidente em meio a falhas recentes e discute o papel crescente da IA na descoberta de bugs.
05:10	A onda de patches impulsionada por IA	A descoberta acelerada de vulnerabilidades cria um gargalo na triagem, na correção e na distribuição de patches.
07:43	Como responder à avalanche de correções	O vídeo recomenda atualizações contínuas e destaca quais produtos devem receber atenção imediata.

Citações

Dois desses bugs receberam nota 9,0 de 10 na escala de gravidade CVSS, e ambos podem levar à execução remota de código. — 00:00

Os bugs encontrados por IA devem ser relatados publicamente porque, como diz Linus, por definição, eles não são secretos. — 03:36

Encontrar bugs costumava ser a parte lenta e cara; agora, isso é barato. — 06:12

Trate a aplicação de patches como algo que acontece o tempo todo, não como uma tarefa trimestral. — 07:43

Conceitos e entidades

Zero Day Initiative (empresa): Iniciativa da Trend Micro que enviou relatórios de vulnerabilidades do Linux à lista pública por engano.
Linux kernel (ferramenta): Kernel cujas listas de segurança e código SMB estão no centro do caso relatado.
SMB (conceito): Protocolo usado por computadores para compartilhar arquivos e pastas pela rede.
WannaCry (conceito): Surto de ransomware de 2017 que se espalhou por uma falha na implementação de SMB do Windows.
Black October (conceito): Nome usado pela comunidade de segurança para se referir à concentração de divulgações de vulnerabilidades naquele período.
PHP (ferramenta): Linguagem cuja vulnerabilidade mencionada no vídeo levou organizações a tirar sites do ar.
National Cyber Security Centre (empresa): Órgão britânico que alertou organizações para se prepararem para ondas de correções de vulnerabilidades.
Mythos (modelo): Modelo da Prophecy que, segundo documentos internos citados no vídeo, encontrou centenas de bugs no SharePoint.
Chrome (ferramenta): Navegador cujas versões 149 e 150 corrigiram, segundo o vídeo, 1.072 vulnerabilidades.
KSMBD (ferramenta): Servidor SMB integrado ao kernel Linux, envolvido em uma das falhas descritas.

Tradução completa (pt-BR)

00:00 Em 22 de outubro, a Zero Day Initiative da Trend Micro enviou um lote de relatórios de vulnerabilidades do kernel do Linux para a lista de discussão errada. Em vez de irem para a lista privada de segurança, onde os bugs deveriam permanecer em sigilo até que uma correção estivesse pronta, eles foram parar na lista pública de discussão do kernel do Linux, onde qualquer pessoa no mundo pode lê-los. Dois desses bugs têm classificação 9,0 de 10 na escala de gravidade CVSS, e ambos podem levar à execução remota de código. E,

00:30 por mais surpreendente que isso seja, essa nem sequer é a maior notícia de segurança da semana. Esta é a mesma semana em que duas falhas no PHP levaram governos e empresas a tirar seus sites do ar, e as pessoas da comunidade de segurança começaram a chamar todo esse período de Outubro Negro. Há muito o que abordar, então vamos começar. Em 22 de outubro, o Phoronix noticiou que a Zero Day Initiative da Trend Micro enviou vários relatórios de vulnerabilidade para

01:01 a lista pública de discussão do kernel do Linux, em vez da lista privada de segurança. Greg Kroah-Hartman, que é basicamente o segundo no comando do Linux, respondeu a cada um deles, perguntando à Zero Day Initiative por que os tinha enviado para a lista pública. Pesquisadores de segurança normalmente mantêm um bug em sigilo até que haja uma correção, e esses bugs ainda não tinham sido corrigidos. Então, parece que a Zero Day Initiative simplesmente os enviou para a lista errada por engano, em vez de torná-los públicos de propósito. Há várias vulnerabilidades nessa lista, mas as

01:31 duas piores estão no código SMB do kernel. SMB, sigla de Server Message Block, é o protocolo que os computadores usam para compartilhar arquivos e pastas pela rede. É isso que está em funcionamento quando você abre uma unidade compartilhada no escritório ou se conecta a um dispositivo de armazenamento conectado à rede em casa. O motivo pelo qual bugs no SMB são tão perigosos é que a função de um servidor SMB é aceitar e processar dados recebidos de outras máquinas pela rede. Então, alguém que nunca fez login nessa máquina pode alcançar um bug nesse código.

02:03 E, se isso parece familiar, é porque o surto do ransomware WannaCry, em 2017, se espalhou exatamente assim, por meio de um bug na implementação do SMB do Windows. O primeiro bug dessa lista é uma vulnerabilidade de execução remota de código no SMB Direct, causada por um underflow de inteiro, que acontece quando um número fica abaixo de zero em um tipo que não pode ser negativo e dá a volta, assumindo um valor enorme. Com isso, o código acaba copiando muito mais dados do que o buffer consegue armazenar. O segundo é uma condição de corrida no

02:33 KSMBD, o servidor SMB integrado ao kernel, em que duas threads acessam os mesmos dados em uma ordem que ninguém planejou. Ambos têm pontuação de gravidade 9,0, e os demais bugs da lista são vulnerabilidades locais de escalonamento de privilégios na pilha de rede e no driver gráfico da VMware. Além disso, há também um vazamento de informações no código do destino NVMe. Então, quando o Phoronix publicou a lista, nenhum desses bugs tinha sido corrigido, embora alguns já tivessem correções na fila. Isso provavelmente já é bastante estressante

03:04 se acontece numa sexta-feira, e, infelizmente, essa é a nova realidade em que estamos vivendo. Para sermos justos, os responsáveis pela manutenção do kernel já previam isso havia algum tempo. Em março, Willy Tarreau disse que as listas de segurança regulares passaram de dois ou três relatórios por semana para cinco a dez por dia. E, em maio, Linus Torvalds chamou a situação de quase totalmente impossível de gerenciar, porque pessoas diferentes estavam usando as mesmas ferramentas de IA no mesmo código e reportando os mesmos bugs. E um dos bugs vazados nesta semana já tinha sido reportado por outra pessoa uma

03:36 semana antes. Agora, a documentação do kernel diz que bugs encontrados por IA devem ser reportados publicamente porque, como diz Linus, eles praticamente não são secretos por definição. Não sabemos de fato se a Zero Day Initiative usou IA para encontrar esses bugs específicos, mas o momento é interessante, porque o próprio projeto do kernel agora diz que bugs encontrados por IA não devem ser mantidos em sigilo. Então, embora esse vazamento provavelmente tenha sido um acidente, ele está de acordo com a direção que as próprias regras do kernel já estão tomando. Mas, de modo geral, este não tem sido

04:07 um bom mês para a cibersegurança. Pode-se dizer que o pior bug de todo esse Outubro Negro foi o PHP 2 Shell, sobre o qual James já fez um vídeo muito detalhado, então confira para saber mais. E esse foi apenas um dos acontecimentos de uma semana bastante cheia. Também houve a confusão dos certificados da eMudhra, que abordei no meu último vídeo; um bug do GitLab com CVSS 10 que remonta a 2014; uma correção para execução remota de código no Node.js; e um relatório da Axios sobre agents de IA não autorizados aparecendo em contas bancárias dos EUA.

04:40 Agora, antes de começarmos a entrar em pânico, vale dizer que boa parte do Outubro Negro foi uma onda de divulgação, e não uma onda de ataques. Muitos desses bugs foram encontrados semanas ou meses atrás e simplesmente se tornaram públicos nos mesmos poucos dias. E a OpenAI afirma que, até onde sabe, a IA encontrou os bugs do PHP antes dos atacantes. Até agora, a maioria das organizações parece ter aplicado as correções a tempo. Mas esta semana também é uma prévia de como será a segurança daqui para a frente, então vamos falar sobre para onde isso

05:10 está caminhando. Em maio, o National Cyber Security Centre do Reino Unido alertou as organizações para que se preparassem para o que se chama de onda de aplicação de correções de vulnerabilidades. A ideia é que toda empresa e todo projeto acumulam anos de dívida técnica, e a IA agora é boa o bastante para vasculhar tudo isso de uma vez. Então, em vez de um fluxo constante de correções, teremos surtos de atualizações urgentes em toda a pilha, de projetos open source a software comercial e produtos SaaS. E já podemos ver isso nos

05:41 números. Segundo documentos internos noticiados pela ProPublica, o modelo Mythos da Anthropic encontrou 90 bugs críticos e 141 importantes apenas no SharePoint, em abril, mais rápido do que a Microsoft conseguia corrigi-los. E a Patch Tuesday de julho da Microsoft acabou lançando correções para mais de 600 bugs. No Google, o Chrome 149 e o 150 corrigiram 1.072 bugs de segurança, mais do que as 23 versões anteriores do

06:12 Chrome juntas. E um deles era uma fuga do sandbox que estava no código havia mais de 13 anos. Por causa disso, o Google está até testando atualizações de segurança duas vezes por semana. O que isso significa é que agora temos um novo gargalo. Encontrar bugs costumava ser a parte lenta e cara, mas agora é barato. A parte difícil passou a ser fazer a triagem, corrigir e lançar patches com rapidez suficiente. E é exatamente isso que está sobrecarregando a lista de segurança do Linux agora, e é por isso que empresas de IA começaram a financiar auditorias de segurança de projetos open source, como a auditoria financiada pela OpenAI que revelou o PHP 2 Shell.

06:42 Ao mesmo tempo, os atacantes têm acesso aos mesmos modelos, e cada patch publicado mostra exatamente qual código mudou. Então, o intervalo entre o lançamento de uma correção e o surgimento de um exploit continua ficando cada vez menor. Também está surgindo uma nova superfície de ataque em torno dos próprios agents de IA. A notícia sobre os bancos, da Axios, é um bom exemplo disso, porque os bancos nem sempre conseguem saber se um agent dentro da conta de um cliente está agindo em nome desse cliente ou fazendo outra coisa.

07:13 Por isso, a maioria deles está caminhando para permitir que os agents leiam informações da conta, mas sem deixá-los realizar ações. Mas o lado esperançoso é que os defensores têm o mesmo acesso e as mesmas ferramentas. A equipe de segurança do Chrome do Google disse à Wired que, em um produto maduro como o Chrome, a quantidade de novas descobertas começa a cair depois que a maioria dos bugs que a IA consegue encontrar já foi corrigida. Então, a enxurrada talvez acabe diminuindo

07:43 pelo menos no caso dos softwares que acompanham esse ritmo. A conclusão prática é tratar a aplicação de patches como algo contínuo, e não como algo que se faz uma vez por trimestre. O NCSC recomenda ter uma política de atualização por padrão e começar pelo que está exposto à internet. Então, faça um levantamento honesto do que está rodando nos seus servidores, automatize as atualizações sempre que puder e planeje substituir tudo o que já não pode mais receber patches. E, especificamente nesta semana, atualize o PHP, fique de olho nas correções de SMB do kernel e desative o KSMBD se

08:17 você não o usa, e atualize o GitLab e o Node.js enquanto faz isso. Então, basicamente, o resumo é que há muitas coisas que você precisa atualizar. A caça a bugs com IA vai tornar o software mais seguro a longo prazo ou estamos caminhando para um estado permanente de emergência, com correções intermináveis e segurança reforçada? O que você acha? Conte o que pensa nos comentários abaixo. E, pessoal, se vocês gostam desse tipo de análise técnica, mostrem isso clicando no botão de curtir abaixo do vídeo. E também não se esqueçam de se inscrever no nosso canal. Este

08:48 foi Andras, da Better Stack, e nos vemos nos próximos vídeos. Fiquem em segurança por aí. >> [música] [música]

Transcrição original

[00:00] On October 22nd, Trend Micro’s Zero Day Initiative sent a batch of Linux kernel vulnerability reports to the wrong mailing list. Instead of going to the private security list where bugs are supposed to stay quiet until a fix is ready, they landed on the public Linux kernel mailing list where anyone in the world can read them. Two of those bugs are rated 9.0 out of 10 on the CVSS severity scale, and both of them can lead to remote code execution. And as

[00:30] wild as that is, this isn’t even the biggest security story of the week. This is the same week that two flaws in PHP pushed governments and companies to pull their websites offline, and people in the security community have started calling this whole stretch Black October. There’s a lot to cover, so let’s dive into it. So, on October 22nd, Phoronix reported that Trend Micro’s Zero Day Initiative sent several vulnerability reports to

[01:01] the public Linux kernel mailing list instead of the private security list. Greg Kroah-Hartman, who is basically the second in command of Linux, replied to every one of them asking Zero Day Initiative why it had sent them to the public list. Security researchers normally keep a bug private until there is a fix, and these bugs weren’t patched yet. So, it looks like Zero Day Initiative simply sent them to the wrong list by mistake rather than going public on purpose. And there are a bunch of vulnerabilities in that list, but the

[01:31] worst two are in the kernel’s SMB code. SMB, which stands for server message block, is the protocol computers use to share files and folders over a network. So, that is what’s running when you open a shared drive at an office or connect to a network-attached storage at home. The reason SMB bugs are so dangerous is that an SMB server’s whole job is to accept and process data coming in from other machines over the network. So, a bug in that code can be reachable by someone who has never logged into that

[02:03] machine. And if that sounds familiar, it’s because the WannaCry ransomware outbreak back in 2017 spread exactly like that through a bug in Windows’ SMB implementation. And the first bug in this list is a remote code execution bug in SMB Direct caused by an integer underflow, which is when a number drops below zero in a type that can’t go negative and wraps around to a huge value. So, the code ends up copying far more data than the buffer can hold. And the second one is a race condition in

[02:33] the KSMBD, the SMB server built into the kernel, where two threads touch the same data in an order nobody planned for. Both of them are rated at a 9.0 severity score, and the rest of the bugs in the list are local privilege escalation bugs in the networking stack and the VMware graphics driver. Plus, there’s also an information leak in the NVMe target code. So, when For Honor published the list, none of these bugs were fixed yet, although some had patches queued up. So, this is probably already very stressful

[03:04] if it’s going out on a Friday, and this is sadly the new reality we’re living in. And to be fair, kernel maintainers have seen this coming for a while now. In March, Willy Tarreau said that regular security lists went from two to three reports a week to five to 10 reports a day. And in May, Linus Torvalds called it almost entirely unmanageable because different people were running the same AI tools on the same code and filing the same bugs. And one of this week’s leaked bugs had actually been reported by someone else a

[03:36] week earlier. And the kernel docs now say that AI-found bugs should be reported publicly because, as Linus puts it, they’re pretty much, by definition, not secret. Now, we don’t actually know whether Zero Day Initiative used AI to find these particular bugs, but the timing is interesting because the kernel project itself is now saying that AI-found bugs shouldn’t be kept secret at all. So, even though this leak was most likely an accident, it fits where the kernel’s own rules are already heading. But in general, this has not

[04:07] been a good month for cybersecurity. Arguably, the worst bug of this whole Black October has been the PHP 2 shell, which James already did a highly detailed video about, so go check that out for more information. And that was only one item in a very crowded week. There was also the eMudhra certificate mess that I covered in my last video, a CVSS 10 GitLab bug going back to 2014, a remote code execution fix in Node.js, and an Axios report about unauthorized AI agents showing up inside US bank

[04:40] accounts. Now, before we start panicking, it’s worth saying that a lot of Black October has been a disclosure wave rather than an attack wave. Many of these bugs were found weeks or months ago, and they simply went public in the same few days. And OpenAI says that to its knowledge, AI found the PHP bugs before attackers did. And so far, most organizations seem to have patched it in time. But this week is also a preview of what security is going to look like from now on, so let’s talk about where that

[05:10] is heading. So, back in May, the UK’s National Cyber Security Centre warned organizations to get ready for what is called a vulnerability patch wave. The idea is that every company and every project carries years of technical debt, and AI is now good enough to dig through all of that at once. So, instead of a steady trickle of patches, we’re going to get surges of urgent updates across the whole stack, from open source to commercial software to SaaS products. And we can already see this in the

[05:41] numbers. According to internal documents reported by ProPublica, and Prophecy’s Mythos model found 90 critical and 141 important bugs in SharePoint alone in April, which was faster than Microsoft could fix them. And Microsoft’s July Patch Tuesday went on to ship fixes for more than 600 bugs. Over at Google, Chrome 149 and 150 fixed 1,072 security bugs, which is more than the previous 23

[06:12] Chrome releases combined. And one of them was a sandbox escape that has been sitting in the code for over 13 years. Google is now even testing security updates twice a week because of this. So, what this means is that now we have a new bottleneck. Finding bugs used to be the slow and expensive part, but now it’s cheap. So, now the hard part is triaging, fixing, and shipping patches fast enough. And that’s exactly what’s breaking the Linux security list right now, and that’s why AI companies have

[06:42] started funding security audits of open source projects like the OpenAI funded audit that turned up PHP to shell. And at the same time, attackers have the same access to the same models, and every published patch shows them exactly which code changed. So, the window between a fix going out and an exploit showing up keeps getting shorter and shorter. And there’s also a new attack surface forming around AI agents themselves. The bank story from Axios is a good example of this because banks can’t always tell whether an agent

[07:13] inside a customer’s account is acting for that customer or doing something else. So, most of them are moving towards letting agents read account information without letting them take any actions. But the hopeful thing is that the defenders have the same access and the same tools. And Google’s Chrome security team told Wired that for a mature product like Chrome, new findings start to drop off once most of the bugs that AI can find have been fixed. So, the flood might eventually settle down

[07:43] at least for the software that keeps up with it. So, the practical takeaway is to treat patching as something that runs all the time rather than a thing you do once in a quarter. The NCSC recommends having a policy to update by default and start with whatever is exposed to the internet. So, take an honest look at what’s running on your servers and automate updates wherever you can and do plan to replace everything that can’t be patched anymore. And for this week specifically, update PHP, watch for the kernels SMB fixes, and unload KSMBD if

[08:17] you don’t use it, and update GitLab and Node.js while you’re at it. So, basically the gist is there’s a lot of things you need to update. So, is AI bug hunting going to make software safer in the long run or are we heading into a permanent state of emergency with endless patching and heightened security? What do you think? Let me know your thoughts in the comments section down below. And folks, if you like these types of technical breakdowns, please let me know by smashing that like button underneath the video. And also, don’t forget to subscribe to our channel. This

[08:48] has been Andras from Better Stack, and I’ll see you in the next videos. Stay safe out there. >> [music] [music]