La RCE que AMD no quiso arreglar
Una falla de ejecución remota de código en el autoactualizador de Windows de AMD, causada por descargar actualizaciones por HTTP en claro, ha reavivado las críticas a la calidad del software y a las prácticas de seguridad de la empresa. Los comentaristas sostienen que tratar los ataques man-in-the-middle como “fuera de alcance” para el bug bounty de AMD socava tanto los incentivos de los investigadores como la seguridad de los usuarios, especialmente dada la lenta respuesta y la negativa inicial a abordar el problema. Aunque AMD finalmente cambió el actualizador a HTTPS, el uso de una comprobación CRC32 no criptográfica en lugar de una firma adecuada se considera emblemático de una desatención más profunda y prolongada a la ingeniería de software robusta en la empresa.
Vulnerabilidad e impacto
- Las utilidades de Windows de AMD (por ejemplo, Ryzen Master) se enviaban con un autoactualizador que usaba HTTP en claro para obtener metadatos de actualización y binarios.
- Esto permite ejecución remota de código mediante MITM o ataques relacionados (por ejemplo, envenenamiento de DNS), aunque algunos señalan que el actualizador estaba, en la práctica, medio roto, lo que limita la explotación “masiva”.
- Varios comentaristas subrayan que cualquier autoactualizador de un proveedor que pueda ejecutar código debe tratar a todo Internet como hostil y protegerse contra MITM.
Alcance del bug bounty e incentivos
- El proveedor del bounty de AMD rechazó inicialmente el informe por estar “fuera de alcance” porque MITM estaba excluido.
- Una postura sostiene que esto es lo normal: los bounties son herramientas limitadas para orientar las prioridades internas de ingeniería, no programas de seguridad integrales, y en general las empresas tienen incentivos para pagar.
- Otros argumentan que “fuera de alcance” equivale de facto a “no queremos pagar ni arreglar esto”, y que los observadores externos solo ven que errores graves fueron ignorados durante meses.
- Hay escepticismo ante la idea de asumir que los incentivos internos siempre están alineados con pagar bounties, citando en general incentivos corporativos desalineados.
La corrección de AMD y la “firma” CRC32
- AMD finalmente cambió el actualizador a HTTPS, pero según se informa solo “verifica” las descargas con CRC32.
- Varios comentaristas califican esto de analfabetismo en seguridad: CRC32 detecta corrupción accidental, no manipulación maliciosa, y colisiona con facilidad.
- Algunos señalan que la pieza realmente faltante es la verificación mediante firma de código; en teoría, HTTPS más firmas adecuadas sería suficiente.
Modelos de amenaza y MitM
- Debate sobre excluir MITM del alcance del bounty: algunos lo defienden como una forma de limitar la responsabilidad sobre el entorno; otros dicen que MITM sobre HTTP, sin comprobaciones criptográficas, está obviamente dentro del alcance.
- Se hacen comparaciones con excluir la ingeniería social de los bounties; los críticos dicen que esto es distinto porque no hace falta interacción humana.
Críticas más amplias al software de AMD
- Muchos comentarios describen el software y los drivers de AMD como crónicamente malos: utilidades llenas de fallos, curvas de ventilador deficientes, ventanas emergentes molestas, y problemas de larga data en cómputo GPU.
- Las quejas se extienden a ROCm, HIP y al soporte OpenCL debilitado o eliminado, visto como autosabotaje frente a CUDA.
- Algunos especulan sobre una cultura de empresa que infravalora el software y paga poco a los ingenieros.
Ética, divulgación y reacciones
- Varios ven esto como prueba de que el trabajo white hat y los bug bounties son cada vez menos agradecidos.
- Algunos abogan por una divulgación pública completa antes cuando los proveedores se estancan o se escudan en reglas de alcance.
- Unos pocos proponen financiar colectivamente un “bounty” para el investigador.
- Aparece una ligera especulación sobre posibles puertas traseras de actores estatales, pero otros lo atribuyen a simple negligencia.