El actualizador AMD tardó 124 días en recibir una corrección que mitiga un vector de ataque y, aun así, la compañía negó el pago de 10.000 dólares reclamado por el investigador que informó del problema. El caso plantea preguntas sobre prioridades de seguridad y los límites de los programas de recompensas.
Qué ocurrió con el actualizador AMD y el reporte
En febrero, un investigador identificado como Paul describió un posible vector de ejecución remota de código (RCE) que permitía un ataque Man-in-the-Middle (MITM) en el componente de actualización automática de AMD. Paul presentó el hallazgo a través del programa de bug bounty de la compañía y, además, publicó inicialmente un análisis en su blog.
AMD pidió retirar temporalmente esa publicación y, según el investigador, se comprometió a emitir un CVE, corregir el software y atribuir el hallazgo. Sin embargo, la compañía rechazó explícitamente la compensación económica asociada: el bug bounty no cubriría el escenario MITM que Paul había descubierto.
El diálogo entre las partes incluyó solicitudes de embargo y ampliaciones del plazo por parte de AMD. Aunque la corrección final llegó, la compañía pidió hasta 124 días desde el primer reporte para desplegar la solución.
La corrección, sus límites y lo que no aclara AMD
Cuando AMD lanzó la actualización, Paul comprobó que el proceso de descarga se había reescrito y ahora utiliza canales seguros para obtener los paquetes. No obstante, la validación de la integridad del archivo descargado sigue realizándose con CRC32, un método que ya no se considera seguro desde el punto de vista criptográfico.
Un detalle especialmente llamativo es que, según aportes de la comunidad, el fragmento de código vulnerable aparentemente no se estaba ejecutando —es decir, la ruta que Paul identificó estaría rota y, por tanto, la actualización no podía aplicarse desde ese propio actualizador. En la práctica, eso obligaba a los usuarios a descargar manualmente el paquete completo para obtener la corrección.
Lo que AMD no aclara todavía es por qué se requirieron cuatro meses para aplicar un cambio que, en apariencia, podía limitarse a reemplazar «http» por «https» en algunos puntos del código, y por qué no se aprovechó para actualizar también los mecanismos de verificación a firmas más robustas.
Otro aspecto relevante es la política del programa de recompensas: aunque un RCE suele considerarse de alta gravedad y justificar pagos importantes —en este caso la cifra mencionada fue de 10.000 $—, AMD sostuvo que el escenario MITM no entraba en la cobertura. En consecuencia, Paul no recibió compensación pese a su cooperación y a la retirada temporal de su divulgación pública.
En términos de prioridad, si la vulnerabilidad afectaba a «múltiples herramientas» como argumentó AMD, cuesta entender por qué no tuvo un tratamiento más urgente dentro de los estándares habituales de divulgación responsable.
En la práctica, esto significa que, aunque la amenaza teórica queda atenuada por la corrección, el proceso de parcheo fue lento, la validación de integridad sigue siendo deficiente y los usuarios tuvieron que recurrir a descargas manuales para asegurar que obtienen el software actualizado.
El episodio no es único: casos en los que empresas tardan en cerrar fallos críticos o disputan la gravedad de un hallazgo han salido a la luz con cierta frecuencia en los últimos años. La relación entre investigadores y programas de bug bounty depende tanto de reglas claras como de la voluntad de las empresas para reconocer y recompensar el trabajo externo que mejora la seguridad.
Vale la pena esperar a verlo en condiciones reales antes de asumir que todos los riesgos han desaparecido: la corrección elimina el vector señalado por Paul, pero no corrige otros problemas de diseño en el proceso de actualización.
Habrá que ver si AMD revisa sus criterios de recompensa y su política de verificación de descargas; mientras tanto, los usuarios interesados en minimizar riesgos deben descargar actualizaciones desde fuentes oficiales y comprobar firmas cuando estén disponibles, en lugar de confiar ciegamente en procesos automáticos con validaciones criptográficas obsoletas.
