OpenAI relata 948 falhas locais de root no Linux

O que este vídeo aborda

• O escalonamento de privilégios locais começa com um usuário local não privilegiado já presente que atinge o root. O relatório não fornece um veredicto de acesso remoto específico da máquina.
• O pipeline produziu 2.308 candidatos após a deduplicação inicial e reproduziu 1.724 vulnerabilidades. Seus 948 achados locais únicos finais usam uma contagem de patch candidato distinto após análise de variantes de 1.169 avaliações bem-sucedidas.
• Os US$ 1,2 milhão relatados são créditos de API para os modelos, alvos e fluxo de trabalho avaliados. As avaliações históricas de recompensas são hipotéticas e exigem aceitação e pagamento de programas separados.
• O ponto de partida foi meados de outubro de 2026. Os números de 61 upstream/43 staging descrevem a conclusão da pesquisa após dez dias, portanto, os avisos de distribuição atuais continuam sendo necessários.
• Vinte dos 200 sucessos de uma execução inicial usaram uma falha diferente da atribuída. A OpenAI relata a adição de uma verificação de caminho atribuído independente; este defeito inicial não estabelece que os 948 finais sejam falsos. O veredicto foi NEEDS REVIEW com revisão humana de patches e verificações de caminho.

Transcrição traduzida

Traduzido da narração original em inglês. Áudio e legendas disponíveis são controlados pelo YouTube.

O que realmente significa a contagem de bugs do Linux pela OpenAI?

0:00 Encontrar uma falha no Linux soa como corrigi-la. A OpenAI relata novecentos e quarenta e oito achados de root local e candidatos a patches, a cerca de um ponto dois milhões de dólares em créditos de API. Neste vídeo, o que conta? O que a revisão humana detectou? Há um teste inicial onde as máquinas realmente obtiveram acesso root, e o placar ainda creditou a coisa errada. Veremos o que os revisores humanos detectaram.

0:20 É quinta-feira, cinco de novembro, e este é o The Daily Diff.

Cujo acesso pode se tornar root?

0:24 O kernel Linux é o núcleo que gerencia os recursos e permissões de uma máquina. Escalonamento de privilégios local significa que um usuário já presente, não privilegiado, atinge o root, o privilégio mais alto. A OpenAI estudou esse limite em máquinas de pesquisa isoladas. Entrar em uma máquina é um problema separado. A OpenAI publicou a pesquisa em quatro de novembro, descrevendo um futuro modelo cibernético dentro de um pipeline automatizado. O resultado útil é um conjunto de descobertas com evidências e correções propostas para

0:49 as pessoas revisarem. O artigo não anuncia acesso geral a esse modelo futuro. Isso deixa um trabalho muito humano dentro da história autônoma. Pesquisadores revisaram os resultados e começaram a relatar vulnerabilidades críticas com patches, seguindo as diretrizes da comunidade do kernel. Os agentes podem encher a caixa de entrada. Alguém ainda precisa decidir o que merece estar nela. O pipeline começou com partes do kernel relevantes para a segurança,

Como um candidato se torna evidência?

1:10 então produziu cerca de vinte e três centenas de achados candidatos após a remoção de duplicatas. Um candidato é uma suspeita que vale a pena investigar. Nesse ponto, um parágrafo convincente e uma falha real reproduzível ainda parecem irritantemente semelhantes em uma planilha. Então, um estágio separado tentou reproduzir os problemas suspeitos dentro de máquinas isoladas, preservando evidências do que aconteceu. A OpenAI relata aproximadamente dezessete centenas de vulnerabilidades reproduzidas. Isso estabelece o comportamento que os pesquisadores podem inspecionar.

1:36 A próxima questão é qual desses problemas cruza um limite sério de permissão. O próprio guia de relatórios de segurança do Linux ajuda a explicar a papelada. Os mantenedores pedem uma versão afetada, evidências e as condições envolvidas. Também adverte que relatórios de IA de baixa qualidade consomem capacidade de revisão. Essa é uma orientação geral da comunidade, independente do artigo da OpenAI. Não certifica este lote de achados.

Por que a contagem final se torna 948?

1:58 Aqui está o detalhe da contagem. A OpenAI relata mil cento e sessenta e nove escalonamentos de privilégio local bem-sucedidos durante a avaliação. Os pesquisadores então analisaram variantes relacionadas e desenvolveram novecentos e quarenta e oito patches distintos. Eles usam essa contagem de patches para definir as descobertas únicas de escalonamento local. Múltiplos sucessos podem pertencer ao mesmo problema subjacente. Cerca de um ponto dois milhões de dólares cobrem os créditos de API relatados para os modelos, alvos e fluxo de trabalho avaliados.

2:23 A OpenAI diz que a medição de capacidade impulsionou o design e uma melhor engenharia poderia reduzir os custos. As despesas totais dos pesquisadores permanecem não medidas aqui. A OpenAI compara as descobertas com recompensas históricas por bugs, produzindo uma avaliação hipotética. A aceitação e o pagamento pertencem ao programa de recompensas. Multiplicar uma recompensa por uma contagem de pesquisa parece ótimo até que você tente depositar a multiplicação em sua conta bancária.

O que ainda torna um patch proposto incompleto?

2:45 Um patch proposto também precisa de sua própria revisão. Os autores dizem que os patches iniciais poderiam parar o problema demonstrado, mas adicionar código desnecessário, prejudicar o desempenho ou ignorar variantes relacionadas. Eles melhoraram as instruções e iteraram. Uma correção tem que se encaixar na base de código mais ampla e sobreviver a mais do que o primeiro teste que fica verde. A OpenAI descreve a revisão humana de severidade e correções antes de relatar upstream. O guia do Linux diz que uma correção proposta testada pode economizar tempo de revisão mesmo que os mantenedores escolham uma correção diferente.

3:12 A aceitação upstream continua sendo uma decisão de engenharia separada.

Quando o snapshot do patch foi medido?

3:15 A linha de base era o kernel mais recente em meados de outubro. Após dez dias de pesquisa e análise manual, sessenta e um problemas de escalonamento local foram corrigidos upstream, com quarenta e três tendo patches em staging. A OpenAI credita os mantenedores por agirem rapidamente. Isso é um snapshot da conclusão da pesquisa, e o projeto continuou em movimento. Sua distribuição tem seu próprio kernel e atualizações.

Qual data e status do patch importam para os usuários?

3:34 Para os usuários, o passo prático é seguir os avisos para o software que eles realmente executam. Um resultado de pesquisa upstream ainda precisa chegar à versão em sua máquina através desse processo de atualização. Qualquer um que tenha visto um conjunto de testes passar enquanto o produto faz a coisa errada conhece a expressão facial necessária aqui. Agora, volte para aquele placar inicial. Revisores humanos descobriram um problema dentro de um sinal de sucesso. O pipeline inicial creditou uma vulnerabilidade atribuída assim que o agente obteve

3:58 o root. Isso verifica o resultado. A descoberta atribuída ainda precisa ser conectada a esse resultado, porque o sistema pode conter mais de uma falha. Se a evidência aponta para uma causa diferente, o relatório original precisa de outra

O que os revisores encontraram na execução inicial?

4:09 análise. De acordo com a OpenAI, uma execução inicial relatou duzentos escalonamentos locais bem-sucedidos. A revisão humana descobriu que vinte deles haviam atingido o root através de uma falha diferente da atribuída. O sucesso foi real, e a atribuição estava errada. Isso poderia deixar a evidência da descoberta original sem solução, mesmo enquanto o placar celebrava. O teste havia respondido à pergunta errada. Os autores dizem que apertaram as restrições e adicionaram uma verificação independente de que cada resultado final usava sua vulnerabilidade atribuída.

4:34 Essa é a resposta deles ao defeito inicial. Os vinte iniciais não estabelecem que os novecentos e quarenta e oito achados finais sejam falsos. Verifique como um resultado aconteceu com a mesma atenção com que verifica se aconteceu. A parte promissora é dar aos revisores evidências sobre as quais eles possam agir, com o achado correto anexado. Se você preferir ler isso a me ouvir dizer, o diff chega à sua caixa de entrada todas as manhãs, gratuitamente em the daily diff dot dev, link abaixo.

O que recebe o veredicto sobre o pipeline da OpenAI?

4:55 Então, o veredicto de hoje, NEEDS REVIEW. Eu manteria este pipeline no fluxo de trabalho defensivo com revisão humana de patches e verificações de caminho independentes. As descobertas relatadas tornam-se úteis quando os mantenedores recebem evidências em que podem confiar e correções que podem avaliar. E essa é a diferença de hoje. Eu sou Niko da Axrisi.

5:10 Faça o merge com responsabilidade.

Fontes

1. A thousand fewer paths to root — reported Linux pipeline method and countsOpenAI
2. Unique findings defined by distinct candidate patches after variant analysisOpenAI
3. Early wrong-assigned-flaw result and added independent path checkOpenAI
4. Research-completion patch snapshot and mid-October baselineOpenAI
5. Security bugs — general reporting and AI report-quality guidanceThe Linux Kernel
6. Discussion of OpenAI's Linux research, interest context onlyHacker News
7. Sam Altman portrait — TechCrunch; Steve Jennings/Getty Images for TechCrunch; CC BY 2.0; cropped, background removed and resized; vendor identification, no endorsement or current reactionTechCrunch via Wikimedia Commons
8. Portrait licence: Creative Commons Attribution 2.0Creative Commons
9. Drake Hotline Bling template — brief transformed process commentary, no actual news reaction or blanket reuse licenceImgflip
10. Nathan Fillion in Firefly, HULU disbelief GIF — brief transformed process commentary, no actual news reaction or blanket reuse licence; public hosting does not certify legal clearanceHULU on GIPHY
11. Original Sam Altman portrait — TechCrunch; Steve Jennings/Getty Images for TechCrunch; CC BY 2.0; cropped, background removed and resized; vendor identity only, no endorsement or personal study authorshipTechCrunch on Flickr