Los investigadores que encontraron supuestos fallos en la CPU de AMD explican su divulgación caótica
Ilia Luk-Zilberman, directora técnica (CTO) de CTS Labs, la compañía detrás de la divulgación de 13 vulnerabilidades que afectan a los procesadores AMD, ha publicado hoy una carta abierta en la que explica las acciones controvertidas de su compañía que lograron enfurecer a una gran parte de la comunidad tecnología y a los investigadores.
CTS Labs se enfrentó a una gran reacción ayer, en una escala rara vez vista en la industria de la seguridad, por la forma en que decidió enfocarse en el proceso de "revelación de vulnerabilidad" de 13 fallas CPU de AMD conocidas colectivamente bajo cuatro nombres clave: Ryzen Fall, MasterKey, Fallout y Quimera.
CTS Labs criticado por revelar los fallos demasiado rápido
Según un portavoz de AMD, CTS Labs le dio al fabricante de chips menos de 24 horas para leer un informe técnico, verificar, reproducir y preparar parches, un plazo que muchos investigadores de seguridad encontraron imposible de cumplir.
Los CTS Labs de Tel Aviv se apresurarón en divulgar públicamente las 13 vulnerabilidades a través de un comunicado de prensa solo compartido con agencias de noticias seleccionadas, con videos de YouTube, un sitio web elegante y un documento técnico que carecía de detalles técnicos.
La comunidad de seguridad se fustro con en la empresa, que rápidamente se convirtió en un tema de bromas y burlas. Los debates en las redes sociales pasaron rápidamente a las teorías de que CTS Labs estaba tratando de reducir las acciones de AMD utilizando vulnerabilidades "fabricadas" en un intento de comprar acciones a valores más bajos.
Fallos de AMD verificados de forma independiente por dos fuentes fiables?
Esas teorías duraron poco porque unas horas después de que CTS Labs recibiera una paliza en las redes sociales y en algunos blogs de infosec, Dan Guido, CEO de Trail of Bits -otra compañía de seguridad- se adelantó para confirmar que el informe de CTS Labs era real y contenía vulnerabilidades reales.
Yaron Luk, el director financiero de CTS Labs, confirmó ayer por correo electrónico que la compañía había pedido al equipo Trail of Bits que realizara una revisión independiente de sus hallazgos, un hecho que Dguido confirmó en Twitter.
Regardless of the hype around the release, the bugs are real, accurately described in their technical report (which is not public afaik), and their exploit code works.
— Dan Guido (@dguido) 13 de marzo de 2018
Además, hoy, Alex Ionescu, una de las figuras más respetadas de la comunidad de investigación de seguridad, también confirmó que él también había visto el informe técnico que CTS Labs enviaba a AMD, y que contenía "problemas legítimos de diseño e implementación".
On the #AMDflaws — I have seen the technical details and there are legit design & implementation issues worth discussing as part of a coordinated disclosure effort. The media storm and handling around that is sadly distracting from a real conversation around security boundaries.
— Alex Ionescu (@aionescu) 14 de marzo de 2018
Los fallos en los procesadores de AMD pueden convertir a los hackers aún más peligrosos
Ionescu también abordó otra crítica importante dirigida a CTS Labs: el hecho de que muchos investigadores de seguridad ridiculizaron a la compañía israelí porque los 13 defectos requerían que un atacante obtuviera los derechos de administrador antes de que pudieran ser explotados.
3) FALLOUT: vendor-supplied *signed* driver allows access to Secure Processor.
— Arrigo Triulzi (@cynicalsecurity) 13 de marzo de 2018
Threat level: No shit, Sherlock!
4) CHIMERA¹: outsourced chipset has an internal ucontroller which can be 0wned via digitally signed driver.
__
¹ read about my Chimaera Processor: far sexier stuff.
Ionescu no estuvo de acuerdo con que algunos investigadores de seguridad que descartaran la gravedad de los hallazgos de CTS Labs solo porque los defectos requerían acceso de administrador.
"El acceso y la persistencia del nivel de administrador son amenazas legítimas en IaaS multiusuario [Infraestructura como servicio] e incluso cosas como VTL0 / 1 (Credential Guard) cuando los límites de confianza del firmware y el chipset se rompen", dijo Ionescu en Twitter hoy.
A medida que el tema se fue digiriendo después de la revelación de las vulnerabilidades muchos investigadores de seguridad ahora no son tan escépticos con los hallazgos de CTS Labs, y las teorías de que pueda ser falso el descubrimentos de tales fallos en AMD comienzan a ser reemplazadas por advertencias de que los fallos se seguridad de AMD podrían traer grandes consecuencias a nivel de seguridad".
Esto se debe a que los expertos comenzaron a darse cuenta de que los atacantes podrían usar estas vulnerabilidades de AMD para obtener persistencia posterior a la reinstalación al dejar el código malicioso en áreas seguras de la CPU. Áreas en las que el software de seguridad no puede escanear o acceder, y donde los atacantes malintencionados normalmente no podrían alcanzar el acceso de administrador.
CTS Labs propone a su nuevo tipo de "divulgación de vulnerabilidades"
Estos fueron los problemas que Luk-Zilberman intentó abordar en una carta abierta hoy, con una gran parte de la carta dedicada a la decisión de la compañía de revelar los defectos de inmediato, sin darle tiempo a AMD para preparar parches. Según Luk-Zilberman, esto fue intencional.
Sé que este es un tema muy acalorado para el debate, donde todos tienen una opinión fuerte. Desafortunadamente, también tengo una fuerte opinión sobre este tema.
Creo que la estructura actual de "divulgación responsable" tiene un problema muy serio. Si un investigador encuentra una vulnerabilidad, este modelo sugiere que el investigador y el proveedor trabajen juntos para construir mitigaciones, con un límite de tiempo (30/45/90 días), al final del cual el investigador saldrá con las vulnerabilidades. El límite de tiempo está destinado a acelerar al vendedor para solucionar los problemas.
El principal problema en mi opinión con este modelo es que durante estos 30/45/90 días, le corresponde al vendedor si desea alertar a los clientes de que existe un problema. Y, por lo que he visto, es extremadamente raro que el vendedor avise con anticipación a los clientes: "Tenemos problemas que lo ponen en riesgo, estamos trabajando en ello". Casi siempre es post-factum: "Tuvimos problemas, aquí está el parche, no hay necesidad de preocuparse".
El segundo problema es: si el vendedor no lo arregla a tiempo, ¿qué ocurre entonces? El investigador se hace público? Con los detalles técnicos y exploits? Poniendo a los clientes en riesgo? Cómo he aceptado este modo de operación está más allá de mí, que los investigadores anuncian al final del tiempo límite los detalles técnicos de las vulnerabilidades "porque" el proveedor no respondió. ¿Por qué deberían los clientes pagar por la falta de acciones del proveedor? Entiendo que este es el modelo hoy y las personas lo siguen, pero creo que podemos hacerlo mejor.
En cambio, el CTO Labs CTO propone algo completamente nuevo para el proceso de divulgación de vulnerabilidades.
Creo que una mejor manera sería notificar al público en el día 0 que hay vulnerabilidades y cuál es el impacto. Para notificar al público y al vendedor juntos. Y no divulgar los detalles técnicos reales a menos que ya esté arreglado. Poner toda la presión pública sobre el proveedor desde el principio, pero nunca poner en riesgo a los clientes.
Es muy difícil argumentar en contra de la propuesta de Luk-Zilberman, que tiene sentido, al menos en el papel, aunque algunos expertos en seguridad se mantendrán en sus caminos.
Al recordar la divulgación reciente de CTS Labs, la compañía aceptó este principio, notificando a AMD y al público sobre las fallas, pero solo brindando detalles técnicos detallados al personal de AMD y algunos investigadores seleccionados.
En el momento de escribir, los detalles técnicos detallados sobre los 13 fallos no son públicos. Si vamos a creer en la carta abierta de Luk-Zilberman, CTS Labs nunca tiene la intención de compartir estos detalles al aire libre. La compañía espera que los atacantes nunca puedan convertir estos fallos en malware para los atacantes, algo que normalmente sucede después de cada divulgación de vulnerabilidades, ya que los hackers malintencionados siempre buscan mantenerse un paso por delante de los proveedores de seguridad.
Con todo, Luk-Zilberman dijo que lamenta no haber contactado a más validadores de terceros antes de revelar las vulnerabilidades. Hacerlo hubiera hecho menos probable que su investigación hubiera sido cuestionada como lo fue ayer con RyzenFall, MasterKey, Fallout y Chimera.
