OpenAI informa de 948 fallos locales de root en Linux

Qué cubre este vídeo

• La escalada de privilegios locales comienza con un usuario local no privilegiado ya presente que alcanza la raíz. El informe no da un veredicto de acceso remoto específico de la máquina.
• La pipeline produjo 2.308 candidatos después de la deduplicación inicial y reprodujo 1.724 vulnerabilidades. Sus 948 hallazgos locales únicos finales utilizan un recuento de parches candidatos distintos después del análisis de variantes de 1.169 evaluaciones exitosas.
• Los 1,2 millones de dólares reportados son créditos de API para los modelos, objetivos y flujo de trabajo evaluados. Las valoraciones históricas de recompensas por fallos son hipotéticas y requieren la aceptación y el pago por separado del programa.
• La línea de base fue a mediados de octubre de 2026. Las cifras de 61-upstream/43-staging describen la finalización de la investigación después de diez días, por lo que las advertencias de distribución actuales siguen siendo necesarias.
• Un éxito de 20 de 200 en una ejecución temprana utilizó un fallo diferente al asignado. OpenAI informa de la adición de una verificación de ruta asignada independiente; este defecto temprano no establece que los 948 finales sean falsos. El veredicto fue NEEDS REVIEW con revisión humana de parches y verificaciones de ruta.

Transcripción traducida

Traducido de la narración original en inglés. El audio y los subtítulos disponibles están controlados por YouTube.

¿Qué significa realmente el recuento de errores de Linux de OpenAI?

0:00 Encontrar un fallo de Linux suena a arreglarlo. OpenAI informa de novecientos cuarenta y ocho hallazgos de root local y candidatos parches, con un coste aproximado de un millón doscientos mil dólares en créditos de API. En este vídeo, ¿qué cuenta? ¿Qué detectó la revisión humana? Hay una prueba temprana en la que las máquinas realmente obtuvieron root, y el marcador seguía atribuyendo lo incorrecto. Veremos qué detectaron los revisores humanos.

0:20 Es jueves, cinco de noviembre, y esto es The Daily Diff.

¿El acceso de quién puede convertirse en root?

0:24 El kernel de Linux es el núcleo que gestiona los recursos y permisos de una máquina. La escalada de privilegios locales significa que un usuario ya presente y no privilegiado alcanza la raíz, el privilegio más alto. OpenAI estudió ese límite en máquinas de investigación aisladas. Acceder a una máquina es un problema aparte. OpenAI publicó la investigación el cuatro de noviembre, describiendo un próximo modelo cibernético dentro de una pipeline automatizada. El resultado útil es un conjunto de hallazgos con evidencia y soluciones propuestas para

0:49 que la gente los revise. El artículo no anuncia el acceso general a ese próximo modelo. Eso deja un trabajo muy humano dentro de la historia autónoma. Los investigadores revisaron los resultados y comenzaron a informar de vulnerabilidades críticas con parches, siguiendo las directrices de la comunidad del kernel. Los agentes pueden llenar la bandeja de entrada. Alguien todavía tiene que decidir qué merece estar en ella. La pipeline comenzó con partes del kernel relevantes para la seguridad,

¿Cómo se convierte un candidato en evidencia?

1:10 luego produjo unos dos mil trescientos hallazgos candidatos después de eliminar duplicados. Un candidato es una sospecha que merece ser investigada. En ese momento, un párrafo convincente y un fallo reproducible real todavía se ven molestamente similares en una hoja de cálculo. Así que una etapa separada intentó reproducir los problemas sospechosos dentro de máquinas aisladas, conservando la evidencia de lo que sucedió. OpenAI informa de aproximadamente mil setecientas vulnerabilidades reproducidas. Esto establece un comportamiento que los investigadores pueden inspeccionar.

1:36 La siguiente pregunta es cuál de esos problemas cruza un límite de permiso serio. La propia guía de informes de seguridad de Linux ayuda a explicar el papeleo. Los mantenedores piden una versión afectada, evidencia y las condiciones involucradas. También advierte que los informes de IA de mala calidad consumen capacidad de revisión. Esta es una guía general de la comunidad, independiente del artículo de OpenAI. No certifica este lote de hallazgos.

¿Por qué el recuento final se convierte en 948?

1:58 Aquí está el detalle del recuento. OpenAI informa de mil ciento sesenta y nueve escaladas de privilegios locales exitosas durante la evaluación. Los investigadores luego analizaron variantes relacionadas y desarrollaron novecientos cuarenta y ocho parches distintos. Utilizan ese recuento de parches para definir los hallazgos únicos de escalada local. Múltiples éxitos pueden pertenecer al mismo problema subyacente. Aproximadamente un millón doscientos mil dólares cubren los créditos de API informados para los modelos, objetivos y flujo de trabajo evaluados.

2:23 OpenAI dice que la medición de la capacidad impulsó el diseño y que una mejor ingeniería podría reducir los costos. Los gastos totales de los investigadores no se miden aquí. OpenAI compara los hallazgos con recompensas históricas por errores, produciendo una valoración hipotética. La aceptación y el pago pertenecen al programa de recompensas. Multiplicar una recompensa por un recuento de investigación se siente genial hasta que intentas depositar la multiplicación en tu cuenta bancaria.

¿Qué hace que un parche propuesto sea incompleto?

2:45 Un parche propuesto también necesita su propia revisión. Los autores dicen que los parches tempranos podrían detener el problema demostrado mientras agregan código innecesario, sacrificando rendimiento o pasando por alto variantes relacionadas. Mejoraron las instrucciones e iteraron. Una solución tiene que encajar en la base de código más amplia y sobrevivir a más que la primera prueba que se pone en verde. OpenAI describe la revisión humana de la gravedad y las soluciones antes de informar a upstream. La guía de Linux dice que una solución propuesta probada puede ahorrar tiempo de revisión incluso si los mantenedores eligen una solución diferente.

3:12 La aceptación en upstream sigue siendo una decisión de ingeniería separada.

¿Cuándo se midió la instantánea del parche?

3:15 La línea de base era el último kernel a mediados de octubre. Después de diez días de investigación y análisis manual, sesenta y un problemas de escalada local fueron parcheados en upstream, con cuarenta y tres teniendo parches de staging. OpenAI atribuye a los mantenedores moverse rápidamente. Esa es una instantánea de finalización de la investigación, y el proyecto siguió adelante. Su distribución tiene su propio kernel enviado y actualizaciones.

¿Qué fecha y estado del parche importan a los usuarios?

3:34 Para los usuarios, el paso práctico es seguir las advertencias para el software que realmente ejecutan. Un resultado de investigación de upstream aún necesita llegar a la versión en su máquina a través de ese proceso de actualización. Cualquiera que haya visto una suite de pruebas pasar mientras el producto hace lo incorrecto conoce la expresión facial requerida aquí. Ahora volvamos a ese marcador inicial. Los revisores humanos descubrieron un problema dentro de una señal de éxito. La pipeline inicial acreditó una vulnerabilidad asignada una vez que el agente obtuvo

3:58 root. Eso verifica el resultado. El hallazgo asignado aún necesita ser conectado a ese resultado, porque el sistema puede contener más de un fallo. Si la evidencia apunta a una causa diferente, el informe original necesita otra

¿Qué encontraron los revisores en la ejecución temprana?

4:09 revisión. Según OpenAI, una ejecución temprana informó de doscientas escaladas locales exitosas. La revisión humana encontró que veinte habían alcanzado la raíz a través de un fallo diferente al asignado. El éxito fue real, y la atribución fue errónea. Eso podría dejar la evidencia del hallazgo original sin resolver incluso mientras el marcador celebraba. La prueba había respondido a la pregunta equivocada. Los autores dicen que endurecieron las restricciones y agregaron una verificación independiente de que cada resultado final utilizó su vulnerabilidad asignada.

4:34 Esa es su respuesta al defecto temprano. Los veinte tempranos no establecen que los novecientos cuarenta y ocho hallazgos finales sean falsos. Verifique cómo ocurrió un resultado tan cuidadosamente como si ocurrió. La parte prometedora es dar a los revisores evidencia sobre la que pueden actuar, con el hallazgo correcto adjunto. Si prefiere leer esto en lugar de escucharme decirlo, el diff llega a su bandeja de entrada cada mañana, gratis en the daily diff dot dev, enlace a continuación.

¿Qué obtiene el veredicto sobre la pipeline de OpenAI?

4:55 Así que el veredicto de hoy, NEEDS REVIEW. Mantendría esta pipeline en el flujo de trabajo defensivo con revisión humana de parches y verificaciones de ruta independientes asignadas. Los hallazgos reportados se vuelven útiles cuando los mantenedores reciben evidencia en la que pueden confiar y soluciones que pueden evaluar. Y esa es la diferencia por hoy. Soy Niko de Axrisi.

5:10 Fusionar responsablemente.

Fuentes

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