AMD responde a las acusaciones de seguridad de CTS Labs y las resoluciones entrantes

AMD-HBM

La semana pasada, una empresa de seguridad hasta ahora desconocida, CTS Labs, publicó acusaciones explosivas de lo que declaró que eran 13 fallas de seguridad críticas que afectó a las CPU y chipsets Ryzen de AMD. Rápidamente se hizo evidente que todo el proceso de divulgación era inusual, por decirlo suavemente, y hay buenas razones para pensar que todo el asunto fue orquestado por una empresa que espera ganar dinero rápidamente con acciones de AMD. AMD ahora ha respondido a los hallazgos iniciales de CTS Labs, pateando las piernas de una de las defensas de la empresa por sus propias acciones en el proceso.

Las 13 fallas identificadas por CTS Labs requieren acceso administrativo para explotar. Si bien este hecho no excusa ningún problema de seguridad dado, pone los problemas en contexto: si tiene acceso de administrador a un sistema, de hecho lata comprometerlo utilizando cualquier número de ataques. AMD luego se rompe las tres principales familias de vulnerabilidades y proporciona un cronograma actualizado de cuándo se esperan correcciones en el mercado.

AMD-Ryzen-Defectos



De particular interés son las declaraciones de AMD de que se espera que las soluciones para los tres conjuntos de vulnerabilidades lleguen en cuestión de semanas. Eso es significativo, dado el fundamento declarado de CTS Labs para sus propias prácticas de divulgación.HowLongBeforeFix

CTS Labs duplicó su argumento de línea de tiempo en un entrevista con Anandtech, cuando su director financiero, Yaron Luk-Zilberman, dijo: “Calculo que pasarán muchos meses antes de que AMD pueda arreglar estas cosas. Si les hubiéramos dicho, digamos, 'ustedes tienen 30 días / 90 días para hacer esto', no creo que importaría mucho '.

CTS está, y estaba, completamente equivocado en este punto. Las personas razonables pueden estar en desacuerdo sobre cómo se deben manejar las divulgaciones de seguridad o cuánto tiempo, si corresponde, se debe proporcionar al fabricante para solucionar sus problemas. En este caso, sin embargo, el hecho de que CTS Labs no discutiera sus propios hallazgos con AMD ha socavado sus propias razones declaradas para la forma y naturaleza de su divulgación. Va a no tomar 'muchos meses' para solucionar estos problemas y no ponen vidas en juego - que fue uno de los laboratorios de CTS otro justificaciones de por qué utilizó el lenguaje que utilizó en su divulgación inicial:

AMD-Security-Lives

No hay exageración imprudente aquí.

TrailofBits, que realizó un análisis y verificación de terceros de los errores que encontró CTS, escribe:

No existe un riesgo inmediato de explotación de estas vulnerabilidades para la mayoría de los usuarios. Incluso si los detalles completos se publicaran hoy, los atacantes tendrían que invertir esfuerzos de desarrollo significativos para crear herramientas de ataque que utilicen estas vulnerabilidades. Este nivel de esfuerzo está fuera del alcance de la mayoría de los atacantes ...

Este tipo de vulnerabilidades no debería sorprender a ningún investigador de seguridad; Se han encontrado fallas similares en otros sistemas integrados que han intentado implementar características de seguridad. Son el resultado de simples fallas de programación, límites de seguridad poco claros y pruebas de seguridad insuficientes.

Las fallas son reales, requieren actualizaciones y deben tratarse, pero no representan una falla de seguridad cataclísmica. Ciertamente no representan el apocalipsis del fin de la empresa que el presunto socio en el crimen de CTS Labs, Viceroy Research, dijo que sí. Mientras tanto, no hay señales de ningún esfuerzo por parte de CTS Labs para abordar las puertas traseras y las fallas de seguridad críticas que se encuentran en decenas de millones de Intel placas base cortesía de su controladores Asmedia integrados, aunque el ASM1042 y el ASM1142 se han enviado con productos Intel durante los últimos seis años.

La mala fe no excusa la mala seguridad

Todo el esfuerzo de CTS Labs, de principio a fin, parece haber sido un intento de convertir en arma las divulgaciones de seguridad y dañar a una empresa en nombre de ganar dinero para inversores sin escrúpulos. Es un ejemplo de libro de texto de por qué el análisis de seguridad y la divulgación deben manejarse con cuidado. Pero nada de esto cambia el hecho de que estos problemas de seguridad no deberían haber existido en primer lugar.

Tanto AMD como Intel han pedido a los usuarios de computadoras que acepten la presencia de implementaciones de seguridad de caja negra en nombre de una mayor seguridad. Intel tiene su Intel Management Engine, AMD tiene su procesador TrustZone. AMD usa una solución ARM con un procesador integrado Cortex-A5, Intel usa su propia CPU Quark. Ambas compañías se han resistido a las llamadas para proporcionar documentación y / o código fuente abierto para estas soluciones y, sin embargo, la seguridad de ambas se ha encontrado repetidamente deficiente. A medida que los dispositivos se integran más estrechamente y aumenta la cantidad de componentes y bloques de IP integrados en los SoC, es cada vez más importante que los fabricantes sigan las mejores prácticas de seguridad de principio a fin. Tanto Intel como AMD tienen más trabajo por hacer en este sentido.

Copyright © Todos Los Derechos Reservados | 2007es.com