- Tras la divulgación de Copy Fail, Hyunwoo Kim consideró que la corrección existente no era suficiente y compartió un parche ese mismo día, pero el proceso al estilo Linux de corregir en público y en silencio quedó expuesto por un descubrimiento externo, lo que llevó al fin del embargo
- En Linux, especialmente en el área de redes, existe la práctica de compartir el impacto de seguridad en una lista privada y avanzar rápidamente con la corrección del bug en público, intentando mantener en embargo durante unos días la existencia de la vulnerabilidad real
- Después de que otra persona detectó el cambio público y dedujo su impacto de seguridad, lo divulgó, y luego se publicaron los detalles completos
- A medida que la IA reduce el costo de evaluar el significado de seguridad de cada commit, se vuelve más fácil encontrar vulnerabilidades a partir de correcciones publicadas en silencio y también mejora la relación señal/ruido
- La divulgación coordinada tradicional de 90 días también se está debilitando; en este caso, apenas 9 horas después del reporte de la vulnerabilidad ESP por parte de Kim, Kuan-Ting Chen la reportó de forma independiente, lo que sugiere que embargos muy cortos podrían ser una mejor dirección
El choque entre Copy Fail y la práctica de correcciones de seguridad en Linux
- Después de que se hiciera pública la vulnerabilidad Copy Fail, Hyunwoo Kim consideró que la corrección existente no era suficiente y compartió un parche ese mismo día
- Kim siguió un procedimiento común en Linux, especialmente en el área de redes
- Compartió el impacto de seguridad en una lista privada de ingenieros de seguridad de Linux
- La corrección del bug avanzó públicamente, de forma silenciosa y rápida
- El objetivo era mantener en embargo durante unos días la existencia de una vulnerabilidad grave mientras solo la corrección real estaba visible públicamente
- Otra persona detectó ese cambio, dedujo su impacto de seguridad y lo divulgó
- Como la vulnerabilidad ya se consideró pública, el embargo terminó y luego se publicaron los detalles completos
La presión que la IA ejerce sobre dos culturas de vulnerabilidades
-
Cultura de divulgación coordinada
- Cuando se descubre un bug de seguridad, se notifica en privado a los maintainers y normalmente se les da un plazo, como 90 días, para corregirlo
- El objetivo es que la corrección se distribuya antes de que la vulnerabilidad se conozca ampliamente
-
Cultura de “un bug es un bug”
- Es un enfoque especialmente común en Linux, que parte de la idea de que si el kernel hace algo que no debería hacer, alguien podría convertirlo en un ataque
- Se corrige lo más rápido posible sin llamar la atención sobre el hecho de que se trata de una vulnerabilidad
- Dado que pasan muchos cambios, se espera que la gente no lo note y que mientras tanto quede tiempo para aplicar parches a los sistemas
-
La IA aumenta el riesgo del modelo de correcciones públicas
- Este enfoque nunca funcionó de forma perfecta, pero se vuelve un problema mayor a medida que la IA mejora para encontrar vulnerabilidades
- Como aparecen muchas correcciones de seguridad, revisar commits se ha vuelto más atractivo y la relación señal/ruido ha mejorado
- El costo de que la IA evalúe cada commit a medida que aparece sigue bajando y su efectividad sigue subiendo
-
Los embargos largos también se debilitan
- Antes, como la detección era lenta, si se reportaba al vendor y se abría una ventana de divulgación de 90 días, era poco probable que alguien más la encontrara en ese periodo
- Ahora esa premisa se debilita porque grupos asistidos por IA están escaneando vulnerabilidades de software a gran escala
- En este caso, apenas 9 horas después de que Kim reportó la vulnerabilidad ESP, Kuan-Ting Chen también la reportó de forma independiente
- Los embargos pueden crear una falsa sensación de no urgencia y aumentar el riesgo al limitar a los actores que pueden corregir la falla
-
Posibles direcciones y una prueba simple con modelos
- La solución no es clara, pero los embargos muy cortos parecen un buen enfoque y con el tiempo quizá deban volverse aún más cortos
- La IA puede acelerar no solo a los atacantes sino también a los defensores, haciendo posibles embargos que antes habrían sido demasiado cortos para servir de algo
- Al darles f4c50a403 a Gemini 3.1 Pro, ChatGPT-Thinking 5.5 y Claude Opus 4.7, los tres modelos identificaron de inmediato que se trataba de un parche de seguridad
- Cuando solo se les dio el diff sin el contexto del commit, Gemini afirmó con confianza que era una corrección de seguridad, GPT consideró que era muy probable y Claude estimó que probablemente no lo era
- Esta prueba fue solo un ejemplo muy rápido, ejecutando cada modelo una vez con el prompt
"Without searching, does this look like a security patch?", por lo que no conviene darle demasiado peso como comparación entre modelos
2 comentarios
Como no queda otra que optar por un "embargo muy corto" en vez de un embargo muy corto vs. un embargo largo, los agentes de IA encargados de seguridad van a estar todavía más ocupados.
Comentarios de Hacker News
Este cambio se veía venir desde hace mucho tiempo, y la grieta que estamos viendo ahora era predecible incluso antes de saber qué era un LLM
El catalizador es el aumento de la transparencia del software. La adopción de software de código abierto y con código disponible ha crecido mucho, y las herramientas de ingeniería inversa y descompilación también han mejorado enormemente. La época en la que el software cerrado comercial típico estaba oculto de forma significativa para atacantes serios ya quedó atrás hace más de una década
Desde BinDiff, este problema ha ido avanzando lentamente. Cuando parcheas software, inevitablemente también terminas revelando la vulnerabilidad. Hasta ahora, todos lo negaban porque hacía falta cierto nivel de especialización para darse cuenta de que un parche equivalía a divulgar la vulnerabilidad, pero la IA eliminó esa excusa
Ahora, cada vez que algo se fusiona en el mainline de Linux, varias organizaciones ponen ese diff en un prompt de LLM, evalúan agresivamente si es una corrección de vulnerabilidad y generan guías de explotación. La mayoría de los grandes proyectos open source como nginx, OpenSSL y Postgres pronto también estarán en esa situación
Las prácticas de divulgación coordinada no están adaptadas a este entorno y, de hecho, diría que tampoco lo han estado durante los últimos diez años
Curiosamente, esta situación no me incomoda, porque creo que las prácticas de divulgación coordinada siempre han aceptado sin cuestionarlo el supuesto de que retrasar la divulgación era bueno por conveniencia operativa para los administradores de sistemas. Ese supuesto merece ser cuestionado. Retrasar la divulgación también les quita información a operadores de sistemas que sí tienen opciones aparte de simplemente aplicar el parche
Si las vulnerabilidades se detectan y explotan con mayor facilidad, ese enfoque podría volverse más común. Claro, no siempre es posible
Durante los últimos 11 años ha sido bastante molesto ver cómo binarios de clientes de juegos ofuscados con ProGuard se descompilaban varias veces y terminaban subidos a GitHub. Solo el código del servidor, que no se distribuía, seguía siendo privado
Curiosamente, mientras no cambiábamos el protocolo de red con menos frecuencia que cada semana, no tuvimos problemas con atacantes haciendo ingeniería inversa. Ahora parece que atacantes asistidos por LLM también podrían seguir ese ritmo
Esto parece menos un problema nuevo causado por la IA y más un problema viejo reempaquetado como problema de IA
La gente ya comparaba diffs de commits del kernel para detectar cuáles eran correcciones de seguridad mucho antes de que aparecieran los LLM. En cuanto un parche se publica, la carrera en realidad ya empezó
No tengo claro que reducir el período de embargo realmente ayude. Las organizaciones que pueden parchear en cuestión de horas ya están bien; al resto igual les toma días o semanas
De hecho, mientras más bajo sea el costo de generar exploits, más probable es que la divulgación coordinada se vuelva más importante, no menos
Sobre “no tengo claro que reducir el período de embargo ayude”, la clave es por qué 90 días y no 2 años. El argumento del artículo es que, al aumentar la frecuencia de descubrimientos simultáneos, cambiaron los factores que definían ese equilibrio. Si muchas personas fuera del embargo igual van a encontrar el exploit, entonces el período de embargo no es una ventana real sino una ilusión
Sí estoy de acuerdo en que “la generación barata de exploits hace más importante la divulgación coordinada”. Pero al mismo tiempo la hace menos viable. Si hasta los script kiddies pueden encontrar y explotar zero-days, se derrumba la capacidad de coordinar
La cultura white hat siempre tuvo una especie de ética gremial artesanal. Si ese gremio se rompe, esa ética también pierde dónde sostenerse
Yo no había visto eso, y aun considerando el tono algo exagerado, me da la impresión de que ahora esto pasará con más frecuencia gracias a los LLM
Así que no sorprende que Dirtyfrag se divulgara como un parche del kernel de Linux [2]
[1] https://www.zdnet.com/article/torvalds-criticises-the-securi...
[2] https://afflicted.sh/blog/posts/copy-fail-2.html
https://news.ycombinator.com/item?id=47921829
Tenemos un gran problema
Estados Unidos está en guerra, y buena parte del mundo también está en una guerra a nivel de ciberataques en este momento. Eso incluye a EE. UU., la UE, gran parte de Medio Oriente, Israel y Rusia
Servicios clave como Ubuntu, GitHub, Let’s Encrypt y Stryker han sido atacados y quedaron fuera de servicio durante días, y sistemas hospitalarios completos también han sufrido interrupciones parciales
En medio de todo esto, la IA ha acelerado muchísimo la velocidad de generación de ataques. Más rápido de lo que el lado defensor puede responder. Antes los ataques zero-day eran raros, pero ahora se están volviendo algo común
Se pondrá peor antes de mejorar, y quizá mucho peor
La parte de “ahora hay tantas correcciones de seguridad que revisar commits se volvió más atractivo. La relación señal-ruido es más alta” me hace preguntarme por qué
La clave está en “la IA hace que el costo de evaluar cada commit a medida que pasa sea cada vez más barato y efectivo”. Con IA se rompe la suposición de que “hay tantos cambios que la gente no se va a dar cuenta”
Esta prueba rápida no muestra demasiado. Si le preguntas directamente “¿esto es un parche de seguridad?”, estás insinuando y guiando a la IA a dar una salida que acepte esa premisa
Una matriz de confusión sería más útil. Claro, entiendo que este artículo no pretende ser una prueba detallada de capacidades de IA
Puede calcularse con los conteos de verdaderos positivos, verdaderos negativos, falsos positivos y falsos negativos
Necesitamos ciclos automatizados de parcheo y liberación
Hasta ahora hemos dependido de procedimientos manuales increíblemente lentos: recibir el reporte, investigar, validar, parchear y preparar la liberación. Es común que sacar una versión corregida tome meses. En una era donde los atacantes pueden producir nuevos exploits en cuestión de horas, eso es demasiado lento
Para reducir el tiempo promedio hasta el parche, hay que mejorar repetidamente los cuellos de botella en toda la cadena de valor
Deberíamos poder convertir un reporte de bug en un producto parchado y listo para pruebas de QA en menos de una hora. Habría que estandarizarlo o volverlo open source, y lograr que toda la cadena de suministro de software lo use: kernel de Linux → distribución → productos que usan esa distribución → usuario. Con IA no hay razón para que no se pueda; solo somos lentos
La IA va a reducir drásticamente la ventana de actualización. En 2026, pensar en cooldowns de dependencias sería lo peor; ahora hay que pensar en warmups de dependencias
Pronto desaparecerá eso de cómo divulgar vulnerabilidades de forma segura en proyectos open source. El SaaS centralizado tendrá aquí una gran ventaja de seguridad
Una vulnerabilidad de ejecución remota de código en una dependencia open source significa que en cuanto se publica el parche de seguridad, todos quedan igual de expuestos, así que no entiendo por qué sería polémico
La vieja frase de Tony Hoare sobre “la ausencia de errores evidentes” y “la evidencia de ausencia de errores” aplica mejor que nunca en la era de los LLM
Personalmente, la explicación de tratar un bug simplemente como bug me suena bastante absurda, pero sé que en el mundo Linux hay mucha gente que valora más los principios que los problemas prácticos
Aun así, 90 días suenan largos
Al final, parece que las grandes empresas de IA tendrán que ayudar a la gente que trabaja en infraestructura crítica de internet. Hacer correr la IA más nueva y mejor sobre cosas como nginx sería un beneficio colectivo para todos
La parte de “por suerte, aquí la IA puede acelerar a los defensores tanto como a los atacantes, haciendo posibles incluso períodos de embargo que antes habrían sido demasiado cortos para servir” toca un aspecto importante de este espacio del problema
El riesgo de seguridad podría terminar convirtiéndose en una carrera armamentista definida por quién puede gastar más en costos de tokens
Los atacantes no pueden gastar tokens sobre él, pero los defensores sí pueden gastar tokens en reforzarlo a partir del código fuente. Los atacantes quedan limitados a pruebas de caja negra