{"id":27515,"date":"2022-08-22T11:44:09","date_gmt":"2022-08-22T09:44:09","guid":{"rendered":"https:\/\/www.kaspersky.es\/blog\/?p=27515"},"modified":"2022-08-22T11:44:09","modified_gmt":"2022-08-22T09:44:09","slug":"retbleed-vulnerability","status":"publish","type":"post","link":"https:\/\/www.kaspersky.es\/blog\/retbleed-vulnerability\/27515\/","title":{"rendered":"Ataque Retbleed: Spectre contraataca"},"content":{"rendered":"

A mediados de julio, unos investigadores de la Escuela Polit\u00e9cnica Federal de Z\u00farich publicaron<\/a> un estudio que describe un nuevo ataque que aprovecha las vulnerabilidades (o caracter\u00edsticas) de los procesadores modernos. El ataque se denomin\u00f3 Retbleed y es un derivado de Retpoline<\/a>, un m\u00e9todo de defensa contra un tipo de ataque de Spectre. B\u00e1sicamente, los autores demostraron que su t\u00e9cnica de compilaci\u00f3n de programas, que anteriormente se cre\u00eda que ofrec\u00eda una protecci\u00f3n eficaz contra el conocido ataque Spectre Variant 2, no funciona o solo funciona de forma ocasional. La investigaci\u00f3n es bastante compleja, como ocurre en todos los anteriores estudios sobre vulnerabilidades de hardware <\/em>en procesadores. \u00a0En este art\u00edculo, como siempre, intentaremos no profundizar en la complejidad de los art\u00edculos cient\u00edficos m\u00e1s relevantes, sino describir los resultados de forma sencilla. Comencemos con algunos datos para ponernos en contexto:<\/p>\n

\u00bfQu\u00e9 es Spectre v2? Hablemos de la predicci\u00f3n de ramificaci\u00f3n<\/h2>\n

Hace m\u00e1s de cuatro a\u00f1os, a principios de 2018, se publicaron dos trabajos de investigaci\u00f3n que describ\u00edan<\/a> las vulnerabilidades de Spectre y Meltdown. Estas son vulnerabilidades de hardware<\/em>: la forma en la que funcionan los procesadores hace posible un ataque de robo de datos potencial. Desde entonces, se han descubierto diversas<\/a> variantes m\u00e1s de Spectre. Los investigadores han encontrado m\u00e1s formas de atacar una clase de vulnerabilidades comunes; es decir, usar para el ataque la funcionalidad predeterminada del procesador llamada \u201cpredicci\u00f3n de ramificaci\u00f3n\u201d.<\/p>\n

La predicci\u00f3n de ramificaci\u00f3n y la ejecuci\u00f3n especulativa de instrucciones ayudan a mejorar significativamente el rendimiento del procesador. En cualquier programa, la ejecuci\u00f3n de pasos posteriores suele depender del resultado de c\u00e1lculos previos. El ejemplo m\u00e1s sencillo es cuando un usuario introduce una contrase\u00f1a para acceder a informaci\u00f3n confidencial. Si la contrase\u00f1a es correcta, los datos se muestran al usuario. Si la contrase\u00f1a es incorrecta, se solicita al usuario que lo intente de nuevo. Con instrucciones simples para la CPU, esto se traduce b\u00e1sicamente en verificar los derechos de acceso a ciertos datos en la RAM: si se confirman los derechos necesarios, se otorga acceso a los datos; si no, el acceso queda denegado.<\/p>\n

El procesador puede realizar millones de operaciones de este tipo por segundo, y mientras se verifica una determinada condici\u00f3n, suele estar inactivo (en t\u00e9rminos generales, esperando a que un usuario introduzca una contrase\u00f1a o que se verifiquen los derechos de acceso). Pero \u00bfy si hacemos que utilice este tiempo de inactividad para realizar por adelantado los c\u00e1lculos que se realizan tras el resultado m\u00e1s probable de la verificaci\u00f3n? Cuando nuestro hipot\u00e9tico usuario introduzca su contrase\u00f1a hipot\u00e9tica, el resultado del c\u00e1lculo estar\u00e1 listo y el usuario podr\u00e1 ver sus datos confidenciales un poco m\u00e1s r\u00e1pido.<\/p>\n

Pero \u00bfc\u00f3mo saber qu\u00e9 parte del c\u00f3digo es m\u00e1s probable que se ejecute? Mediante estad\u00edsticas relacionadas con ejecuciones anteriores de instrucciones similares, por supuesto. Si nuestro usuario introduce la contrase\u00f1a correcta nueve de cada 10 veces (hay que tener en cuenta que este es un ejemplo te\u00f3rico y muy simplificado), podemos preparar sus datos confidenciales con antelaci\u00f3n. Si la contrase\u00f1a es incorrecta, simplemente descartaremos los resultados y tardaremos un poco m\u00e1s en mostrar un mensaje de error.<\/p>\n

Los autores del art\u00edculo de 2018 describieron dos variantes del ataque de Spectre, y la Variante 2 (conocida tambi\u00e9n como Inyecci\u00f3n de destino de rama) entrena a un predictor de ramificaci\u00f3n para que realice las instrucciones que necesitamos, como leer datos a los que un atacante no deber\u00eda tener acceso. S\u00ed, estos c\u00e1lculos luego se descartan, pero su resultado (los datos extremadamente confidenciales) se almacenan temporalmente en la cach\u00e9, donde pueden ser robados.<\/p>\n

Este es un ataque extremadamente complejo. En primer lugar, el atacante debe poder ejecutar c\u00f3digo en el sistema atacado, aunque sin los privilegios deseados, es decir, sin acceso a datos confidenciales. Por ejemplo, se podr\u00eda persuadir a un usuario para que abra en su navegador una p\u00e1gina web que contenga un script <\/em>malicioso. En segundo lugar, el atacante necesita un software<\/em> en el sistema de destino que incluya un c\u00f3digo id\u00f3neo para el ataque. En la jerga de los investigadores, esto se conoce como \u201cgadget\u201d. El c\u00f3digo de ataque entrena al sistema de predicci\u00f3n de ramificaci\u00f3n para ejecutar especulativamente este dispositivo. Esto hace que acceda a un \u00e1rea de memoria inaccesible para el atacante. Los datos confidenciales se colocan en la cach\u00e9 de la CPU, donde se pueden extraer muy lentamente (no m\u00e1s de decenas de bits por segundo) mediante la lectura del canal lateral.<\/p>\n

Tratemos de explicarlo de una forma a\u00fan m\u00e1s sencilla. El sistema de predicci\u00f3n de ramificaci\u00f3n incorporado en el procesador no separa las instrucciones de diferentes programas, y se puede usar un \u00fanico programa para hacer que el procesador ejecute especulativamente una instrucci\u00f3n que se supone que no debe ejecutar. Anteriormente, esto no parec\u00eda ser un problema, ya que el software<\/em> no puede acceder en ning\u00fan caso directamente a los datos en la cach\u00e9 del procesador. Pero resulta que, se pueden extraer los datos mediante la lectura de canales laterales (que es un mecanismo muy complejo: la reconstrucci\u00f3n de datos bas\u00e1ndose \u00fanicamente en la informaci\u00f3n sobre la velocidad de las respuestas a las solicitudes de lectura).<\/p>\n

Espera, Spectre fue descubierto en 2018. Seguramente ya lo hayan parcheado, \u00bfno?<\/h2>\n

Con las vulnerabilidades de hardware<\/em> no es tan sencillo. En primer lugar, incluso si nos centramos en esta descripci\u00f3n simplificada, est\u00e1 claro que la vulnerabilidad, aunque est\u00e9 definitivamente basada en el hardware<\/em>, requiere que coincidan ciertas condiciones en el software <\/em>para que pueda ser explotada. Si ese es el caso, \u00bfpor qu\u00e9 no parchear el software<\/em>? Esto es mucho m\u00e1s sencillo que actualizar el hardware<\/em>. Tambi\u00e9n es posible reparar parcialmente la vulnerabilidad en los procesadores mediante actualizaciones de microc\u00f3digo. Pero solo puede encontrarse una soluci\u00f3n definitiva al problema con el lanzamiento de nuevos procesadores con hardware <\/em>modificado. Mientras tanto, los viejos siguen siendo total o parcialmente vulnerables.<\/p>\n

Hay otra pregunta que es extremadamente importante en el contexto de la investigaci\u00f3n de Retbleed. \u00bfCu\u00e1l ser\u00eda el coste de un parche de software<\/em> o hardware<\/em>? Cada m\u00e9todo para \u201ccerrar\u201d Spectre reduce el rendimiento. Por ejemplo, el bastante obvio sistema de Especulaci\u00f3n restringida de rama indirecta (IBRS) introduce verificaciones adicionales de permisos durante la ejecuci\u00f3n de c\u00f3digo especulativo y evita que los programas con m\u00ednimos privilegios accedan a datos altamente confidenciales, haciendo imposible un ataque de Spectre. Pero con cientos de miles o millones de verificaciones de este tipo, el rendimiento de la CPU tiende a disminuir. \u00bfPero cu\u00e1nto? Hay investigaciones que demuestran<\/a> que un conjunto diverso de parches para Spectre en un sistema provoc\u00f3 una disminuci\u00f3n del rendimiento de hasta un 25 %.<\/p>\n

Y aqu\u00ed es donde viene Retpoline<\/a>, un m\u00e9todo de protecci\u00f3n contra Spectre relativamente sencillo propuesto por los ingenieros de Google que se ha utilizado durante la compilaci\u00f3n de software<\/em>. Como sugieren los autores del m\u00e9todo, reemplazar algunas instrucciones por otras en situaciones t\u00edpicas de ramificaci\u00f3n no afecta a la operatividad del software<\/em>, pero s\u00ed hace imposible un ataque de Spectre. Una ventaja importante de Retpoline frente a IBRS y otros m\u00e9todos de protecci\u00f3n es tan solo un ligero descenso de no m\u00e1s del 5 % del rendimiento.<\/p>\n

\u00bfQu\u00e9 muestra el estudio de Retbleed?<\/h2>\n

B\u00e1sicamente, esta nueva investigaci\u00f3n ha demostrado que Retpoline\u2026 \u00a1no funciona! Las instrucciones de retorno en las que se bas\u00f3 el m\u00e9todo Retpoline tambi\u00e9n podr\u00edan explotarse en un esquema ligeramente modificado para enga\u00f1ar (o entrenar maliciosamente) al predictor de ramificaci\u00f3n. Los autores han grabado incluso un v\u00eddeo demostrando el ataque:<\/p>\n