To install click the Add extension button. That's it.

The source code for the WIKI 2 extension is being checked by specialists of the Mozilla Foundation, Google, and Apple. You could also do it yourself at any point in time.

4,5
Kelly Slayton
Congratulations on this excellent venture… what a great idea!
Alexander Grigorievskiy
I use WIKI 2 every day and almost forgot how the original Wikipedia looks like.
What we do. Every page goes through several hundred of perfecting techniques; in live mode. Quite the same Wikipedia. Just better.
.
Leo
Newton
Brights
Milds

Meltdown (vulnerabilidad)

De Wikipedia, la enciclopedia libre

Meltdown es un agujero de seguridad en el hardware que afecta a los procesadores Intel x86, a los procesadores IBM POWER, y también a algunos procesadores basados en la arquitectura ARM,[1][2][3]​ y que permite que un proceso malicioso pueda leer de cualquier lugar de la memoria virtual, aún sin contar con autorización para hacerlo.[4]

Meltdown afecta a una amplia gama de sistemas. En el momento de hacerse pública su existencia, se incluían todos los dispositivos que no utilizasen una versión convenientemente parcheada de iOS,[5]GNU/Linux,[6][7]macOS,[5]Windows y Windows 10 Mobile. Por lo tanto, muchos servidores y servicios en la nube se han visto impactados,[8]​ así como potencialmente la mayoría de dispositivos inteligentes y sistemas embebidos que utilizan procesadores con arquitectura ARM (dispositivos móviles, televisores inteligentes y otros), incluyendo una amplia gama de equipo usado en redes. Se ha considerado que una solución basada únicamente en software para Meltdown ralentizaría los ordenadores entre un cinco y un 30 por ciento dependiendo de la tarea que realizasen.[9]​ Por su parte, las compañías responsables de la corrección del software en relación con este agujero de seguridad informan de un impacto mínimo según pruebas tipo.[10]

A Meltdown le fue asignado en enero de 2018 el identificador CVE-2017-5754, también conocido como carga maligna de la caché de datos (Rogue Data Cache Load).[2]​ Su existencia fue revelada junto con la de otra vulnerabilidad, Spectre, con la cual comparte algunas características. Las vulnerabilidades Meltdown y Spectre han sido consideradas como «catastróficas» por algunos analistas de seguridad.[11][12][13]​ Su gravedad es de tal magnitud que al comienzo los investigadores no daban crédito.[14]

Se han publicado varios procedimientos para ayudar a proteger las computadoras personales y otros dispositivos relacionados contra las vulnerabilidades de seguridad Meltdown y Spectre.[15][16][17][18]​ Los parches para Meltdown pueden producir una pérdida de rendimiento.[19][20][21]​ Asimismo, se ha informado de que los parches para Spectre degradan también de forma significativa el rendimiento, especialmente en los ordenadores más antiguos; en las nuevas plataformas de octava generación se han medido caídas de rendimiento de entre un 2 y un 14 %.[22]​ El 18 de enero de 2018 se supo de problemas con reinicios indeseados tras la instalación de los parches para Meltdown y Spectre, afectando incluso a los chips más recientes de Intel.[23]​ En cualquier caso y según Dell: «No se ha tenido constancia hasta la fecha (26 de enero de 2018) de que estas vulnerabilidades hayan sido puestas en práctica en el mundo real, a pesar de que los investigadores han publicado pruebas de concepto».[24][25]​ Asimismo, entre las medidas preventivas recomendadas citan «instalar de inmediato las actualizaciones de software a medida que se publiquen, evitar seguir enlaces a sitios desconocidos, no descargar archivos o aplicaciones de fuentes desconocidas... seguir los protocolos de seguridad a la hora de usar contraseñas seguras... (usar) software de seguridad para ayudar a protegerse del malware (programas avanzados de prevención de amenazas, o antivirus)».[24][25]

El 25 de enero de 2018 se presentó un informe sobre el estado actual así como de las posibles consideraciones a tomar de cara al futuro con el fin de resolver las vulnerabilidades Meltdown y Spectre.[26]

Base de funcionamiento

Meltdown explota una condición de carrera inherente al diseño de muchas CPU actuales. Esta condición se da entre los accesos a la memoria y la comprobación de privilegios durante el procesamiento de instrucciones. Además, en combinación con un ataque de canal lateral a la caché de la CPU, esta vulnerabilidad permite que un proceso se salte las comprobaciones habituales de nivel de privilegio que normalmente aislarían al proceso maligno e impedirían que accediese a datos que pertenecen al sistema operativo y otros procesos concurrentes. La vulnerabilidad permite que un proceso no autorizado lea información de cualquier dirección mapeada al espacio de memoria del proceso actual. Dado que la segmentación de instrucciones reside en los procesadores afectados, la información de una dirección no autorizada casi siempre se cargará temporalmente en la caché de la CPU durante la ejecución fuera de orden, pudiendo posteriormente leerse desde la caché. Esto puede suceder incluso cuando la instrucción de lectura original falla debido a una comprobación de privilegios que da negativo, o cuando no produce un resultado legible.

Dado que muchos sistemas operativos mapean la memoria física, los procesos del núcleo y otros procesos del espacio de usuario en el espacio de direcciones de cada proceso, Meltdown permite que un proceso maligno pueda leer cualquier memoria mapeada física, del núcleo o de otro proceso, con independencia de si debería o no poder hacerlo. Las defensas contra Meltdown exigirían evitar el uso del mapeo de memoria de un modo que resultase vulnerable a tales amenazas (una solución basada en software), o bien evitar la condición de carrera subyacente (una modificación del microcódigo de la CPU o la ruta de ejecución).

El agujero es viable en cualquier sistema operativo en el que la información privilegiada se mapee a memoria virtual para procesos no privilegiados, una característica que incorporan muchos sistemas operativos actuales. Por lo tanto, potencialmente Meltdown puede afectar a una gama de dispositivos mayor que la identificada actualmente, dado que apenas hay variaciones entre las familias de microprocesadores utilizados por estos sistemas.

Un ataque basado en esta vulnerabilidad sería indetectable.[27][28]

Historia

El 8 de mayo de 1995, un documento titulado La arquitectura del procesador Intel 80x86: trampas para los sistemas seguros y publicado en el simposio de 1995 del IEEE referente a seguridad y privacidad advertía de un canal de temporización encubierto en la caché de la CPU y el TLB.[29]​ Este análisis fue llevado a cabo bajo los auspicios del Programa de Evaluación de Productos de Confianza (TPEP) de la Agencia de Seguridad Nacional estadounidense.

En julio de 2012, el núcleo XNU de Apple (utilizado, entre otros, por macOS, iOS y tvOS) integró la aleatoriedad en la disposición del espacio de direcciones del núcleo (KASLR) con el lanzamiento de Mac OS X Mountain Lion 10.8: la base del sistema, incluido el núcleo y los módulos cargados por él y las zonas se relocalizan de forma aleatoria durante el arranque del sistema en un esfuerzo por reducir la vulnerabilidad del sistema operativo ante los ataques.[30]

En 2014, el núcleo Linux adoptó a su vez la funcionalidad KASLR para mitigar las fugas de direcciones de memoria.[31]

El 4 de agosto de 2016, Anders Fogh y Daniel Gruss presentaron "Cómo usar comportamiento no documentado de la CPU para explorar el espacio del núcleo y de paso romper la protección KASLR" en la conferencia Black Hat de 2016.[32]

El 10 de agosto de 2016, Moritz Lipp y otros miembros de Universidad Tecnológica de Graz publicaron ARMagedón: Ataques a la caché en dispositivos móviles con motivo de la celebración de la 25 edición del simposio de seguridad USENIX. Aunque el trabajo estaba enfocado en ARM, sentaba las bases del vector de ataque.[33]

El 27 de diciembre de 2016 y durante la celebración del 33C3, Clémentine Maurice y Moritz Lipp de la Universidad Tecnológica de Graz presentaron su charla "¿Qué podría salir mal al usar <inserte aquí una instrucción x86>?". Entre los efectos colaterales se mencionaban «los ataques de canal lateral y el baipás al ASLR del núcleo», que ya daban una idea de lo que estaba por llegar.[34]

El 1 de febrero de 2017 los códigos CVE 2017-5715, 2017-5753 y 2017-5754 fueron asignados a Intel.

El 27 de febrero de 2017, Bosman y otras personas de la Universidad Libre de Ámsterdam hicieron públicos en el simposio NDSS sus hallazgos sobre cómo podía abusarse de la aleatoriedad en la disposición del espacio de direcciones (ASLR) en arquitecturas basadas en caché.[35]

El 27 de marzo de 2017, investigadores de la Universidad Tecnológica de Graz desarrollaron una prueba de concepto que podía obtener claves RSA de enclaves de las extensiones de salvaguarda de software (Intel SGX) corriendo en el mismo sistema en cuestión de 5 minutos, empleando ciertas instrucciones de la CPU y una temporización muy granularizada para explotar canales laterales de la caché DRAM.[36]

En junio de 2017, se detectó que KASLR contaba por sí mismo con una nueva clase de nuevas vulnerabilidades.[37]​ Los investigadores de la Universidad Tecnológica de Graz mostraron cómo resolver estas vulnerabilidades impidiendo todo acceso a páginas no autorizadas.[38]​ Una presentación de la técnica KAISER fue remitida al congreso Black Hat en julio de 2017, pero fue rechazada por los organizadores.[39]​ En cualquier caso, este trabajo condujo al aislamiento de tablas de páginas del núcleo (KPTI, originalmente conocido como KAISER) en 2017, que se confirmó que eliminaba un gran número de fallos de seguridad, incluyendo el por entonces aún no descubierto Meltdown, extremo éste confirmado por los autores de Meltdown.[40]

En julio de 2017, investigaciones publicadas por el sitio CyberWTF por parte del investigador de seguridad Anders Fogh describían el uso de un ataque coordinado a la caché para leer la información del espacio del núcleo observando los resultados de operaciones especulativas condicionados a datos obtenidos mediante privilegios no válidos.[41]

La vulnerabilidad Meltdown fue descubierta de forma independiente por Jann Horn del Proyecto Cero de Google, Werner Haas y Thomas Prescher de Cyberus Technology, así como Daniel Gruss, Moritz Lipp, Stefan Mangard y Michael Schwarz de la Universidad Tecnológica de Graz.[42]​ Los mismos equipos de investigación que descubrieron Meltdown también descubrieron una vulnerabilidad de seguridad relacionada con la CPU, que ahora se conoce como Spectre.

En octubre de 2017, la funcionalidad ASLR para la arquitectura amd64 se añadió a la rama NetBSD-current, convirtiendo a NetBSD en el primer sistema BSD formado totalmente por código abierto en soportar la aleatoriedad en la disposición del espacio de direcciones del núcleo (KASLR).[43]​ Sin embargo, el sistema operativo Darwin, que es parcialmente de código abierto[44]​ y forma la base, entre otros, de macOS e iOS, está basado en FreeBSD; KASLR se añadió a su núcleo XNU en 2012 tal como se indicó más arriba.

El 14 de noviembre de 2017, el investigador de seguridad Alex Ionescu mencionó públicamente cambios en la nueva versión de Windows 10 que causarían cierta degradación en el rendimiento, aunque sin explicar la necesidad de dichos cambios, refiriéndose simplemente a los cambios similares realizados en GNU/Linux.[45]

Una vez que los fabricantes del hardware y el software afectados tuvieron conocimiento del problema el 28 de julio de 2017,[46]​ las dos vulnerabilidades se hicieron públicas conjuntamente el 3 de enero de 2018, varios días antes de la fecha de anuncio decidida del 9 de enero de 2018, debido a que varios sitios de noticias comenzaron a informar sobre los cambios al núcleo Linux y los mensajes a su lista de correo.[47]​ Como resultado de este adelanto en los acontecimientos, no se disponía todavía de parches para algunas plataformas, como Ubuntu,[48]​ cuando se revelaron ambas vulnerabilidades.

La vulnerabilidad fue denominada Meltdown porque «básicamente lo que hace es derretir las barreras de seguridad que normalmente coloca el hardware».[27]

Hardware afectado

La vulnerabilidad Meltdown afecta principalmente a microprocesadores Intel[49]​ y también a algunos ARM.[50]​ La vulnerabilidad no afecta a los microprocesadores de AMD,[20][51][52][53]​ si bien Intel ha replicado que los defectos afectan a todos los procesadores.[54][55][56]​ AMD negó esta última afirmación, afirmando "creemos que los procesadores de AMD no son susceptibles debido al uso que hacemos de la protección a nivel de privilegios en la arquitectura de paginado".[57]

Los investigadores han indicado que la vulnerabilidad Meltdown es exclusiva de los procesadores Intel, mientras que la vulnerabilidad Spectre puede posiblemente afectar a procesadores Intel, AMD y ARM.[58][59][60][61]​ Concretamente, los procesadores con ejecución especulativa incorporada en su arquitectura son los afectados por estas vulnerabilidades;[62]​ los procesadores Intel y ARM son los más afectados, mientras que los de AMD son los menos.[63]​ Google ha manifestado que todos los procesadores de Intel desde 1995 con ejecución fuera de orden son potencialmente vulnerables a Meltdown (esto excluye las CPU Itanium, así como las Intel Atom de antes de 2013).[64]​ Intel introdujo la ejecución especulativa en sus procesadores a partir de la familia P6 con el procesador Pentium Pro IA-32 en 1995.[65]

ARM aseguró que la mayoría de sus procesadores no son vulnerables, y publicó una lista de los procesadores en concreto que sí están afectados. El ARM Cortex-A75 core está afectado directamente tanto por Meltdown como por Spectre, mientras que los Cortex-R7, Cortex-R8, Cortex-A8, Cortex-A9, Cortex-A15, Cortex-A17, Cortex-A57, Cortex-A72 y Cortex-A73 lo están únicamente por Meltdown.[50]​ Esto contradice algunas de las primeras aseveraciones realizadas acerca de Meltdown, que aseguraban que la vulnerabilidad sólo afectaba a Intel.[66]

Una gran parte de los teléfonos móviles Android actuales de gama media utilizan Cortex-A53 y Cortex-A55 de 8 núcleos y no están afectados ni por Meltdown ni por Spectre, ya que no realizan ejecución fuera de orden. Esto incluye también los sistemas en chip Snapdragon 630, Snapdragon 626 y Snapdragon 625 de Qualcomm, así como todos los procesadores Snapdragon 4xx basados en núcleos A53 y A55.[67]​ Los sistemas Raspberry Pi no son vulnerables a Meltdown ni a Spectre.[68]

IBM también ha confirmado que sus CPU Power están afectadas por ambos ataques a la CPU.[69]​ Red Hat anunció públicamente en su aviso de seguridad del 3 de enero que las vulnerabilidades afectan también a los sistemas basados en IBM System Z y arquitectura POWER, incluidos los POWER8 y POWER9.[70]

Oracle ha indicado que los sistemas SPARC basados en V9 (T5, M5, M6, S7, M7, M8, M10, M12) no están afectados por Meltdown, si bien los procesadores SPARC más antiguos y que ya no tienen soporte alguno sí podrían estarlo.[71]

Mecanismo de acción

Meltdown se basa en una condición de carrera de la CPU que puede surgir entre la ejecución de instrucciones y la comprobación de privilegios,[72]​ con el fin de leer sin autorización información mapeada en memoria de una forma detectable antes de que pueda tener lugar la comprobación de privilegios que normalmente impediría que se leyese esa información.[40]​ El texto siguiente describe el funcionamiento de la vulnerabilidad, y el mapeo de memoria que usa como objetivo. El ataque se describe tal como ocurre en un procesador Intel corriendo Microsoft Windows o GNU/Linux, los principales sistemas a prueba en los documentos técnicos originales, pero también afecta a otros procesadores y sistemas operativos.

Antecedentes: diseño actual de las CPU

Las CPU de los actuales equipos informáticos emplean una variedad de técnicas para proporcionar altos niveles de eficiencia. En el caso de Meltdown, hay cuatro particularidades que resultan especialmente relevantes:

  • Memoria virtual (paginada), también conocida como mapeo de memoria: se utiliza para que los accesos a la memoria resulten más eficientes, y para controlar qué procesos pueden acceder a determinadas áreas de la memoria.
    Un ordenador actual normalmente ejecuta muchos procesos en paralelo. En un sistema operativo como Windows o GNU/Linux, a cada proceso se le hace pensar que dispone de un uso completo de la memoria física del ordenador, y que puede disponer de ella como quiera. En realidad, al proceso se le asigna una parte de la memoria física, que actúa como una porción de la memoria disponible, cuando intenta por primera vez usar una determinada dirección de la memoria (ya sea para leerla o escribir en ella). Esto permite que una multitud de procesos —incluyendo el núcleo o el propio sistema operativo— puedan cohabitar en el mismo sistema, al tiempo que conservan su actividad individual y su propia integridad sin verse afectados por cualquier otro proceso concurrente, y sin resultar vulnerables frente a interferencias o accesos no autorizados causados por un proceso fuera de control.
  • Los dominios de protección o anillos de protección: proporcionan un medio por el cual el sistema operativo puede controlar qué procesos están autorizados a leer determinadas áreas de la memoria virtual.
    Puesto que la memoria virtual permite a un ordenador hacer referencia a una cantidad de memoria muy superior a la que puede contener físicamente, el sistema puede gozar de un aumento de velocidad considerable "mapeando" cada proceso y la memoria que utilizan —esto es, toda la memoria de todos los procesos activos— a la memoria virtual de cada proceso. En algunos sistemas toda la memoria física está también mapeada para ganar así todavía más velocidad y eficiencia. Normalmente esto se considera algo seguro, dado que el sistema operativo puede confiar en que los dominios de protección de los que consta el propio procesador limitarán las áreas de la memoria a las que se permite acceder a cada proceso. Un intento de acceder a memoria autorizada tendrá éxito inmediatamente, mientras que un intento de acceder a memoria no autorizada causará una excepción y declarará nula la instrucción de lectura, que devolverá un fallo. Tanto el proceso llamante como el sistema operativo pueden decidir lo que ocurre cuando se realiza un intento de leer de memoria no autorizada; lo habitual es que esto cause una condición de error y que se ponga fin al proceso que intentó llevar a cabo dicha lectura. Dado que las lecturas no autorizadas no suelen formar parte de la ejecución normal de un programa, resulta mucho más rápido usar este método en lugar de pausar el proceso cada vez que ejecute alguna función que requiera acceso a memoria privilegiada, para permitir que esa memoria se mapee a un espacio de direcciones legible.
  • Segmentación de instrucciones y ejecución especulativa: se utilizan para permitir que las instrucciones se ejecuten del modo más eficiente posible —si es necesario, permitiéndoles correr fuera de orden o en paralelo a través de las múltiples unidades de procesamiento de la CPU— siempre que el resultado final sea correcto.
    Los procesadores modernos suelen contener múltiples unidades de ejecución separadas, y un planificador que decodifica las instrucciones y decide, en el momento de ejecutarlas, la forma más eficiente de hacerlo. Esto puede suponer decidir que dos instrucciones pueden ejecutarse al mismo tiempo, o incluso fuera de orden, en unidades de ejecución diferentes (algo conocido como segmentación de instrucciones). Mientras el resultado final sea el correcto, esto maximiza la eficiencia al hacer que se usen al máximo todas las unidades de ejecución del procesador. Algunas instrucciones, como los saltos condicionales, conducen a uno de dos resultados posibles dependiendo de una determinada condición; por ejemplo, podría realizarse determinada operación dependiendo de si un valor es 0, u otra si el valor es distinto. En ciertos casos la CPU puede no saber todavía qué ruta de ejecución (rama) tomar, y esto puede deberse a un valor que está sin cachear. En lugar de esperar a conocer la opción correcta, la CPU puede continuar su trabajo inmediatamente (ejecución especulativa), y para ello puede o bien adivinar la opción correcta (ejecución predictiva) o incluso tomar ambas (ejecución ansiosa). En caso de ejecutar la opción incorrecta, la CPU intentará descartar todos los efectos debidos a la suposición errónea. Véase también: predictor de saltos.
  • La caché de la CPU es una pequeña cantidad de memoria alojada en la CPU que se utiliza para garantizar el alto rendimiento del procesador, acelerar los accesos a memoria y facilitar la ejecución "inteligente" de instrucciones de un modo eficiente.
    Desde el punto de vista de una CPU, el acceso a la memoria física del ordenador es muy lento. Además, las instrucciones que ejecuta una CPU suelen ser repetitivas, o se accede muchas veces a las mismas o similares direcciones de memoria. Para maximizar el uso eficiente de los recursos de la CPU, las CPUs modernas albergan en su interior una modesta cantidad de memoria conocida como caché de CPU, de acceso muy rápido. Cuando se accede a información o cuando se lee una instrucción de la memoria física, una copia de esa información se guarda también en la caché de la CPU, de forma sistemática. Si posteriormente la CPU necesita acceder de nuevo a la misma instrucción o al mismo contenido de la memoria, puede obtener esa información en un tiempo mínimo de su propia memoria caché en lugar de tener que esperar a obtenerla de la memoria física, una operación que en comparación resulta mucho más lenta.

La vulnerabilidad Meltdown

Por lo general, los mecanismos anteriormente descritos se consideran seguros, y proporcionan la base sobre la que se fundamentan la mayoría de sistemas operativos y procesadores modernos. Meltdown se aprovecha de la forma en que interactúan estas mecánicas, para saltarse los controles de privilegios fundamentales de la CPU y poder así acceder a información sensible del sistema operativo y de otros procesos. Para comprender el funcionamiento de Meltdown, consideremos la información que está mapeada en memoria virtual (gran parte de la cual se supone que resulta inaccesible para el proceso en cuestión), y veamos cómo responde la CPU cuando un proceso intenta acceder a memoria no autorizada. El proceso está corriendo en una versión vulnerable de Windows, GNU/Linux o macOS sobre un procesador de 64 bits de los considerados como vulnerables[40]​ (se trata de una combinación muy habitual entre todos los ordenadores de sobremesa, portátiles, servidores y dispositivos móviles usados actualmente).

  1. Al igual que sucede con cualquier otro proceso y con el propio sistema operativo, el proceso en este caso "maligno" cuenta con acceso a un espacio de direcciones virtual (memoria virtual) de billones de gigabytes. Ignorando los controles de privilegios, este espacio se usará de tal forma que maximice la eficiencia. La mayor parte de este espacio no está adjudicado, es decir, no contiene información alguna. Algunas áreas están asignadas al proceso maligno para sus propias instrucciones y su información. Por razones de eficiencia, e ignorando los controles de privilegios, este espacio también contiene el resto de la información que emplean los demás procesos que están en marcha, incluyendo el sistema operativo, y posiblemente incluso memoria que se utilizó anteriormente pero que no se ha vaciado todavía o bien direcciones que siempre se mapean directamente a la totalidad de la memoria física. Sin embargo, el hecho de que toda esta información se mapee a la memoria de cada proceso suele considerarse un procedimiento completamente seguro, puesto que los controles de privilegios de la CPU se encargarán de impedir cualquier abuso. Cualquier intento por parte del proceso maligno de acceder a información que no le pertenece —es decir, cualquier dirección de memoria a la que no le esté permitido acceder— supondrá una excepción, es decir, un error. La petición fallará y el proceso no recibirá información alguna, garantizando así la seguridad del sistema.
  2. Si un proceso intentara leer de memoria no autorizada, la instrucción de lectura en principio llegaría al planificador para ser ejecutada por la CPU, como cualquier otra instrucción. Como es habitual, se elegiría una unidad de ejecución y una unidad del controlador de memoria recibiría la orden de leer el contenido de esa memoria y pasarla a la instrucción, de forma que estuviese lista y accesible de forma rápida en la CPU cuando llegase el momento de ejecutar el resto de la instrucción. En algún momento previo a que se permitiese a la instrucción producir cualquier información de salida, la comprobación de privilegios completaría su trabajo en otra parte. En el caso de una lectura no autorizada, la unidad de ejecución recibirá el dato de que la instrucción no ha superado la comprobación de privilegios — descartará toda la información de la instrucción, nunca le pasará nada al proceso, y abandonará la instrucción para proceder a atender a la siguiente.
  3. En teoría, y suponiendo que la unidad de ejecución, el controlador de memoria, el planificador y la comprobación de privilegios funcionen correctamente, este procedimiento es completamente seguro. Aún en el caso de que la memoria privilegiada llegase a ser leída inicialmente por la unidad de ejecución y el controlador de memoria, la ejecución de la instrucción se cancelaría a medio camino, y los datos procesados a medias se descartarían — el comportamiento ha sido el correcto. Sin embargo, como demuestra Meltdown, esto no es tan seguro como se creía.
  4. En los primeros estadios de la ejecución de la instrucción, el planificador de la CPU planificó dos eventos: una comprobación de privilegios, y los primeros pasos de la ejecución de la instrucción. Como parte de esta labor, mientras estaba esperando a que la comprobación de privilegios se completase, la unidad de ejecución empezó su trabajo y solicitó la información. En el caso de un proceso maligno, la información procedía de una dirección no autorizada, pero aun así fue obtenida por el controlador de memoria durante la etapa inicial de la ejecución de la instrucción, aunque fuera después descartada y abandonada cuando la comprobación de privilegios se completó y produjo un fallo.

Normalmente esto no tiene efecto alguno y la seguridad está garantizada, puesto que la información leída nunca se pone a disposición de otros procesos hasta completarse la comprobación de privilegios. Sin embargo, aun cuando falla la instrucción, la información ya ha sido solicitada por la unidad de ejecución y obtenida por el controlador de memoria con el fin de estar listo para procesarla, y si bien la unidad de ejecución descarta la información al fallar la comprobación de privilegios, la caché de la CPU de hecho se actualizó como es habitual al leer información de la memoria, por si acaso esa información fuese necesaria en breve plazo una segunda vez.

Es en este momento cuando interviene Meltdown:[40]

  1. La caché de la CPU no es legible por parte de un proceso no autorizado, puesto que es algo interno de la CPU. Pero, usando un ataque coordinado a la caché (una forma de ataque de canal lateral), resulta posible para un proceso maligno determinar si la información de una dirección específica se encuentra en la caché de la CPU, aunque no pueda leer por sí mismo la información que se encuentra en esa dirección. Si la información de alguna dirección ha sido cacheada por la CPU, entonces una segunda instrucción para leer esa dirección utilizará la caché de la CPU para este propósito (puesto que esto mejora el rendimiento), de lo contrario la CPU tendría que solicitar la lectura de esa información a partir de la memoria normal (que es algo mucho más lento). El proceso maligno puede utilizar esta diferencia temporal para detectar cuál de ambos casos ha tenido lugar, y saber así si la dirección ya estaba en la caché de la CPU. Normalmente esto no sería de por sí una vulnerabilidad insuperable, pero Meltdown puede combinar este conocimiento con otras particularidades del juego de instrucciones de la CPU para disponer de un acceso completo a toda la memoria mapeada...
  2. Cuando una instrucción solicita una lectura de memoria, puede indicar la dirección de la que efectuar esa lectura de muchas maneras distintas. Puede emplear, por ejemplo, modos de direccionamiento indirectos: instrucciones que le digan a la CPU que lea de la memoria X, que use el valor almacenado en X para calcular una segunda dirección Y, y la "respuesta" (o valor retornado) es el valor almacenado en la dirección Y. Meltdown utiliza esta técnica como base de un ataque de canal lateral para determinar el contenido de cualquier dirección de memoria. Supongamos que la dirección 2000 no es legible de forma directa para el proceso, pero podría tener un valor comprendido entre 1 y 5, y supongamos también que ignoramos la comprobación de privilegios. Uno podría ejecutar una instrucción "Lee el valor de memoria en la dirección dada por (5000 + el valor de la memoria en la dirección 2000)". Si la dirección 2000 contiene 1, entonces la CPU intentará devolver el valor de la memoria en la dirección 5001; si la dirección 2000 contiene 2, intentará devolver el valor de la memoria en la dirección 5002, y así sucesivamente. Si a continuación ejecutamos un ataque coordinado, y descubrimos que la CPU ha tardado más en leer de las direcciones 5001, 5002, 5003 y 5005, pero ha sido más rápida leyendo de la dirección 5004, entonces podemos concluir que es porque recientemente ha accedido a esa dirección. Y podemos deducir, por tanto, que la dirección 2000 contiene el valor "4".
  3. Si 2000 es una dirección no autorizada, entonces este intento debería fracasar y el proceso no debería sacar ninguna información de ello, debido a la comprobación de privilegios.
  4. Pero el problema —tal como demuestra Meltdown— es que, para ser eficiente, la CPU ya ha comenzado a prepararse para acceder a las posiciones de memoria que pueden resultar necesarias, en paralelo con la comprobación de privilegios. Esto significa que cuando la comprobación de privilegios da negativo y la unidad de ejecución (correctamente) descarta la información y abandona la instrucción de lectura, la dirección 2000 ya ha sido leída y su contenido utilizado para leer la dirección 5004, aunque la lectura fuese abandonada y la información empleada en la tarea fuese descartada por la unidad de ejecución de la CPU. Es más, cuando el controlador de memoria recibió orden de la unidad de ejecución de acceder a la dirección 5004 para prepararse para la instrucción, automáticamente colocó una copia de esa información en la caché de la CPU como es habitual, en previsión de una futura lectura de la misma información, y esa copia todavía está presente en la caché de la CPU. (No se espera que sea detectable sin autorización, y a menudo será utilizada de nuevo muy pronto aunque no llegase a ser utilizada la primera vez). Es decir, que aunque la instrucción en sí falló, y a pesar de que el proceso no puede leer directamente el contenido de la dirección 2000 ni tampoco el contenido cacheado de cualquiera de las direcciones 5001 a la 5005, el proceso maligno puede a pesar de todo emplear su ataque de canal lateral para saber que la dirección 5004 está en la caché, y que las otras direcciones de la 5001 a la 5005 no lo están, con lo cual puede, a pesar de todo, determinar que la dirección que la instrucción hubiera intentado leer es la 5004, y por tanto que el contenido de la dirección no autorizada 2000 es "4".

Meltdown emplea esta técnica de forma secuencial para leer cualquier dirección que le interese a alta velocidad, y dependiendo de cuáles sean los otros procesos concurrentes, el resultado puede contener contraseñas, información encriptada y cualquier otro tipo de información sensible, de cualquier dirección de cualquier proceso que exista en su mapa de memoria. En la práctica, dado que los ataques de canal lateral a la caché son lentos, resulta más rápido extraer la información un bit cada vez (solo son necesarios 2 x 8 = 16 ataques a la caché para leer un byte, en lugar de 256 pasos si intentase leer los 8 bits a la vez).

Impacto

El impacto de Meltdown depende del diseño de la CPU, del diseño del sistema operativo (concretamente, de cómo utiliza la paginación de memoria) y de la capacidad de la parte maliciosa para ejecutar código en ese sistema, así como del valor de la información obtenida en caso de llegar a ejecutarse.

  • CPU. Muchas de las CPU modernas empleadas comúnmente desde finales de 1990 hasta principios de 2018 tienen el diseño vulnerable necesario para dar lugar a este agujero en la seguridad. Sin embargo, es posible mitigarlo con el diseño de la CPU. Una CPU que pudiese detectar y evitar accesos a memoria por parte de instrucciones sin los privilegios necesarios, o que no fuese susceptible a ataques coordinados a su caché u otras sondas similares, o que eliminase información de la caché al detectar usos no autorizados (y no permitiese a otros procesos acceder a esa información hasta contar con la debida autorización) como parte del proceso de descarte de la instrucción, no estaría sujeta a ser explotada de esta manera. Algunos observadores consideran que todas las soluciones basadas únicamente en software son "parches" a un problema que continúa estando presente, y que la verdadera solución pasa por actualizar los diseños de CPU afectados para eliminar las debilidades subyacentes.
  • Sistema operativo. La mayoría de los sistemas operativos de propósito general utilizados comúnmente emplean niveles de privilegios y mapeo de memoria virtual como parte de su diseño. Meltdown sólo puede acceder a páginas que están mapeadas en memoria, con lo cual el impacto será mayor si todos los procesos y la memoria activa están mapeados a memoria en cada proceso, y menor si el sistema operativo está diseñado de tal forma que no pueda accederse a casi nada de esta manera. Un sistema operativo podría también ser capaz de mitigar hasta cierto punto el impacto mediante software, asegurando que los intentos de sondeo de este tipo no revelen nada útil. Sin embargo, los modernos sistemas operativos utilizan mapeo de memoria para aumentar la velocidad, con lo cual esto podría conllevar una caída del rendimiento.
  • Máquina virtual. El ataque de Meltdown no puede utilizarse para forzar una máquina virtual. Es decir, en máquinas completamente virtualizadas, el espacio del usuario invitado sigue pudiendo leerse desde el espacio del núcleo del invitado, pero no desde el espacio del núcleo del sistema anfitrión.[73]​ El fallo permite leer memoria desde el espacio de direcciones representado por la misma tabla de páginas, lo que significa que el fallo no funciona entre tablas virtuales. O lo que es lo mismo, existe una barrera infranqueable al intentar acceder a las tablas de páginas del anfitrión desde la parte del invitado, aunque sí existe riesgo de acceso entre los espacios de núcleo y de usuario del invitado, como también existe entre esos mismos espacios al hablar del sistema anfitrión. Esto significa también que al tener múltiples máquinas virtuales corriendo en el mismo hipervisor completamente virtualizado no hay riesgo de traspaso de datos entre ellas, pero diferentes usuarios operando en un mismo invitado sí podrían traspasarse información.[74]
  • Sistema embebido. Entre los chips vulnerables se encuentran los fabricados por ARM e Intel diseñados para dispositivos tanto autónomos como embebidos, tales como dispositivos móviles, TVs inteligentes, equipos de red, vehículos, discos duros, aparatos de control industrial y similares. Como ocurre con todas las vulnerabilidades, si un tercero no puede ejecutar código en el dispositivo, sus vulnerabilidades internas no pueden explotarse. Por ejemplo, el procesador ARM de un teléfono inteligente o un aparato de la Internet de las cosas puede ser vulnerable, pero el mismo procesador alojado en un dispositivo que no puede descargar y ejecutar nuevo código, como sería el caso de un aparato de cocina o la controladora de un disco duro, se cree que es prácticamente imposible que pueda ser explotado de este modo.[75]

El impacto en sí depende de la implantación del mecanismo de traducción de direcciones empleado por el sistema operativo y de la arquitectura del hardware subyacente. El ataque puede revelar el contenido de cualquier espacio de memoria mapeado en el espacio de direcciones de usuario, aún en el caso de estar protegido de otro modo. Por ejemplo, antes de la introducción del aislamiento de tablas de páginas del núcleo, la mayor parte de versiones de Linux mapean toda la memoria física al espacio de direcciones de todo proceso en el espacio de usuario; las direcciones mapeadas están (en su mayor parte) protegidas, haciéndolas ilegibles desde el espacio de usuario y resultando accesibles únicamente cuando llegan al núcleo. La existencia de estos mapeos acelera la transición de información hacia y desde el núcleo, pero es una práctica que resulta insegura en presencia de esta vulnerabilidad Meltdown, ya que el contenido de toda la memoria física (que puede contener información sensible, como contraseñas pertenecientes a otros procesos o al núcleo mismo) puede obtenerse entonces mediante al proceso descrito arriba empleando cualquier proceso sin autorización desde el espacio de usuario.

Según los investigadores, «todo procesador de Intel que implemente ejecución fuera de orden está potencialmente afectado, lo que significa efectivamente todos los procesadores de la marca comercializados desde 1995 (excepto el Intel Itanium y el Intel Atom de antes de 2013)».[42]​ Intel respondió a las vulnerabilidades reportadas en la seguridad con un comunicado oficial.[76]

Se espera que la vulnerabilidad tenga impacto sobre los grandes proveedores de servicios de computación en la nube tales como Amazon Web Services (AWS) y la plataforma Google Cloud. Los proveedores de servicios en la nube permiten a los usuarios ejecutar programas en los mismos servidores físicos en los que podría estar alojada información sensible, y dependen de que las salvaguardas proporcionadas por la CPU impidan accesos no autorizados a posiciones de memoria protegidas donde se guarda esa información, un sistema de seguridad que la vulnerabilidad Meltdown puede saltarse.

Uno de los descubridores de la vulnerabilidad informa de que las tecnologías de paravirtualización (Xen) y los contenedores (tales como Docker, LXC y OpenVZ) también están afectados.[73]​ El informe apunta a que en entornos de virtualización pura, sería posible acceder al espacio de memoria del núcleo de la máquina virtualizada desde el espacio de usuario de la misma máquina virtualizada, pero no al espacio del núcleo de la máquina anfitrión.

Mitigación

La mitigación de esta vulnerabilidad requiere cambios en el código del núcleo del sistema operativo, incluyendo un mayor aislamiento de la memoria del núcleo respecto a los procesos del modo usuario.[3]​ Los desarrolladores del núcleo Linux se han referido a esta medida como aislamiento de tablas de páginas del núcleo (KPTI, según las siglas en inglés). Los parches KPTI han sido desarrollados para el núcleo Linux 4.15, y han sido liberados como backport para los núcleos 4.14.11 y 4.9.75.[77][78][79][80]​ Red Hat publicó actualizaciones del núcleo para sus distribuciones Red Hat Enterprise Linux versión 6[81]​ y versión 7.[82]CentOS también ha publicado ya sus actualizaciones del núcleo para CentOS 6[83]​ y CentOS 7.[84]

Apple añadió mitigaciones para el problema en MacOS 10.13.2, iOS 11.2 y tvOS 11.2. Estos parches se lanzaron un mes antes de que las vulnerabilidades fueran hechas públicas.[85][86][87][88]​ Apple ha declarado que watchOS y el Apple Watch no se han visto afectados.[89]​ También se incluyeron mitigaciones adicionales en una actualización para Safari, así como en una actualización adicional para MacOS 10.13 e iOS 11.2.2.[90][91][92][93][94]

Microsoft lanzó el 3 de enero de 2018 una actualización de emergencia pensada para abordar la vulnerabilidad y dirigida a Windows 10, 8.1 y 7 SP1,[95][96][97]​ así como Windows Server (incluyendo Windows Server 2008 R2, Windows Server 2012 R2 y Windows Server 2016) y Windows Embebido.[98]​ Se sabe que estos parches causan conflictos con software antivirus de terceros que utilizan llamadas al núcleo no soportadas; los sistemas que ejecuten software antivirus incompatible no recibirán ésta ni ninguna futura actualización de seguridad para Windows hasta que el antivirus sea parcheado y el software añada una clave especial al registro de Windows que afirme su compatibilidad.[99][100][101]

Se ha indicado que la implantación de KPTI puede conllevar una reducción en el rendimiento de la CPU, que alcanzaría según algunos investigadores hasta un 30% dependiendo del uso, aunque Intel consideró este último extremo una exageración.[19]​ Se informó asimismo de que las generaciones de procesadores Intel que admiten identificadores de contexto de procesos (PCID), una característica introducida con Westmere[102]​ y disponible en todos los chips de la arquitectura Haswell en adelante, no eran tan susceptibles a las pérdidas de rendimiento con KPTI como las generaciones anteriores que carecen de ella.[103][104]​ Esto se debe a que la limpieza selectiva del translation lookaside buffer (TLB) habilitada por el PCID (también llamado número de espacio de dirección, ASN, bajo la arquitectura Alpha) hace que el comportamiento del TLB compartido que resulta crucial para la vulnerabilidad se aisle entre procesos sin estar constantemente limpiando toda la caché: la principal razón del coste de la mitigación.

En declaraciones Intel dijo que «cualquier impacto en el rendimiento depende de la carga de trabajo y, para el usuario medio de PC, no debería ser significativo y se mitigará con el tiempo».[21]Phoronix comparó varios juegos de PC populares en un sistema Linux con la CPU Coffee Lake Core i7-8700K de Intel y los parches KPTI instalados, y descubrió que el posible impacto en el rendimiento sería mínimo o inexistente.[52]​ En otras pruebas, incluyendo medidas de E/S sintéticas y bases de datos como PostgreSQL y Redis, sí se encontró un impacto medible en el rendimiento.[105]

Se han publicado varios procedimientos para ayudar a proteger las computadoras personales y otros dispositivos relacionados contra las vulnerabilidades de seguridad Meltdown y Spectre.[15][16][17][18]​ Mientras tanto, en Estados Unidos ya se han entablado tres demandas contra Intel por, entre otras cosas, prácticas engañosas, violación de la garantía implícita, negligencia, competencia desleal y enriquecimiento ilícito.[106]

Problemas en las medidas de mitigación

Existen numerosos informes de que el parche de Microsoft KB4056892 para mitigar Meltdown y Spectre está causando que algunas computadoras con procesadores AMD no puedan iniciar el sistema operativo;[107][108]​ el problema parece afectar en particular a las computadoras con procesadores de la gama AMD Athlon.[109]​ El 9 de enero de 2018, Microsoft detuvo la distribución de la actualización para los sistemas con las CPU afectadas mientras investigaban cómo solucionar este fallo.[99]

Por otro lado, el 18 de enero de 2018 se supo de problemas con reinicios indeseados tras la instalación de los parches para Meltdown y Spectre, afectando incluso a los chips más recientes de Intel.[23]​ Según Dell: «No se ha tenido constancia hasta la fecha (26 de enero de 2018) de que estas vulnerabilidades hayan sido puestas en práctica en el mundo real, a pesar de que los investigadores han publicado pruebas de concepto».[24][25]​ Asimismo, entre las medidas preventivas recomendadas citan «instalar de inmediato las actualizaciones de software a medida que se publiquen, evitar seguir enlaces a sitios desconocidos, no descargar archivos o aplicaciones de fuentes desconocidas... seguir los protocolos de seguridad a la hora de usar contraseñas seguras... (usar) software de seguridad para ayudar a protegerse del malware (programas avanzados de prevención de amenazas, o antivirus)».[24][25]

El 25 de enero de 2018 se presentó un informe sobre el estado actual así como de las posibles consideraciones a tomar de cara al futuro con el fin de resolver las vulnerabilidades Meltdown y Spectre.[26]

Sumario de mitigaciones en Microsoft Windows[110]
Vulnerabilidad CVE Referencia Denominación técnica Cambios en Windows Cambios en el firmware
(Spectre) 2017-5753 Variante 1 Baipás de la comprobación de límites Recompilación con un compilador nuevo

Navegador endurecido para atajar ataques desde código JavaScript
No
(Spectre) 2017-5715 Variante 2 Inyección de destino de salto Nuevas instrucciones de la CPU que eliminen la especulación de rama
Meltdown 2017-5754 Variante 3 Carga maligna de la caché de datos Aislar las tablas del núcleo de las del modo usuario No

Véase también

Referencias

  1. «About speculative execution vulnerabilities in ARM-based and Intel CPUs». Apple.com (en inglés). 5 de enero de 2018. 
  2. a b Arm Ltd. «Arm Processor Security Update». ARM Developer (en inglés). 
  3. a b Bright, Peter (5 de enero de 2018). «Meltdown and Spectre: Here’s what Intel, Apple, Microsoft, others are doing about it». Ars Technica (en inglés). Consultado el 6 de enero de 2018. 
  4. «Detectado un posible error masivo en el diseño de las CPU de Intel: solucionarlo ralentizará millones de ordenadores». Xataka. 3 de enero de 2018. Consultado el 4 de enero de 2018. 
  5. a b «Apple Confirms 'Meltdown' and 'Spectre' Vulnerabilities Impact All Macs and iOS Devices, Some Fixes Already Released» (en inglés). 
  6. Vaughan-Nichols, Steven J. (11 de enero de 2018). «Major Linux distros have Meltdown patches, but that's only part of the fix». ZDNet (en inglés). Consultado el 16 de enero de 2018. 
  7. «CVE-2017-5754». security-tracker.debian.org (en inglés). Consultado el 16 de enero de 2018. 
  8. «CERT: "Meltdown and Spectre" CPU Security Flaw Can Only Be Fixed by Hardware Replacement». WinBuzzer.com (en inglés). 4 de enero de 2018. 
  9. «Kernel-memory-leaking Intel processor design flaw forces Linux, Windows redesign». The Register (en inglés). Consultado el 5 de enero de 2018. 
  10. «Industry Testing Shows Recently Released Security Updates Not Impacting Performance in Real-World Deployments». Intel newsroom (en inglés). 4 de enero de 2018. Consultado el 5 de enero de 2018. 
  11. Schneier, Bruce. «Spectre and Meltdown Attacks Against Microprocessors - Schneier on Security». www.schneier.com. Consultado el 9 de enero de 2018. 
  12. https://www.cylance.com/en_us/blog/this-week-in-security-internet-meltdown-over-spectre-of-cpu-bug.html
  13. http://www.rudebaguette.com/2018/01/08/meltdown-spectre-heres-what-you-should-know/
  14. King, Ian; Kahn, Jeremy; Webb, Alex; Turner, Giles (8 de enero de 2018). «‘It Can’t Be True.’ Inside the Semiconductor Industry’s Meltdown». Bloomberg Technology (en inglés). Bloomberg L.P. Archivado desde el original el 10 de enero de 2018. Consultado el 10 de enero de 2018. 
  15. a b Metz, Cade; Chen, Brian X. (4 de enero de 2018). «What You Need to Do Because of Flaws in Computer Chips». The New York Times. Consultado el 5 de enero de 2018. 
  16. a b Pressman, Aaron (5 de enero de 2018). «Why Your Web Browser May Be Most Vulnerable to Spectre and What to Do About It». Fortune (en inglés). Consultado el 5 de enero de 2018. 
  17. a b Chacos, Brad (4 de enero de 2018). «How to protect your PC from the major Meltdown and Spectre CPU flaws». PC World (en inglés). Consultado el 4 de enero de 2018. 
  18. a b Elliot, Matt (4 de enero de 2018). «Security - How to protect your PC against the Intel chip flaw - Here are the steps to take to keep your Windows laptop or PC safe from Meltdown and Spectre.». CNET (en inglés). Consultado el 4 de enero de 2018. 
  19. a b «Computer chip scare: What you need to know». BBC News (en inglés británico). 2018. Consultado el 5 de enero de 2018. 
  20. a b Metz, Cade; Perlroth, Nicole (3 de enero de 2018). «Researchers Discover Two Major Flaws in the World's Computers». The New York Times (en inglés estadounidense). ISSN 0362-4331. Consultado el 3 de enero de 2018. 
  21. a b «Intel says processor bug isn’t unique to its chips and performance issues are ‘workload-dependent’». The Verge (en inglés). Consultado el 5 de enero de 2018. 
  22. Hachman, Mark (9 de enero de 2018). «Microsoft tests show Spectre patches drag down performance on older PCs». PC World. Consultado el 9 de enero de 2018. 
  23. a b Tung, Liam (18 de enero de 2018). «Meltdown-Spectre: Intel says newer chips also hit by unwanted reboots after patch - Intel's firmware fix for Spectre is also causing higher reboots on Kaby Lake and Skylake CPUs.». ZDNet (en inglés). Consultado el 18 de enero de 2018. 
  24. a b c d Staff (26 de enero de 2018). «Microprocessor Side-Channel Vulnerabilities (CVE-2017-5715, CVE-2017-5753, CVE-2017-5754): Impact on Dell products». Dell (en inglés). Consultado el 26 de enero de 2018. 
  25. a b c d Staff (26 de enero de 2018). «Meltdown and Spectre Vulnerabilities». Dell (en inglés). Archivado desde el original el 24 de enero de 2018. Consultado el 26 de enero de 2018. 
  26. a b Hachman, Mark (25 de enero de 2018). «Intel's plan to fix Meltdown in silicon raises more questions than answers - But what silicon?!! Be sure and read the questions Wall Street should have asked.». PC World (en inglés). Consultado el 26 de enero de 2018. 
  27. a b https://spectreattack.com/
  28. https://www.cybereason.com/blog/what-are-the-spectre-and-meltdown-vulnerabilities
  29. Sibert, Olin; Porras, Philip A.; Lindell, Robert (8 de mayo de 1995). «The Intel 80x86 Processor Architecture: Pitfalls for Secure Systems». Archivado desde el original el 7 de enero de 2018. Consultado el 9 de enero de 2018. 
  30. «OS X Mountain Lion Core Technologies Overview». Junio de 2012. Consultado el 25 de julio de 2012. 
  31. «Linux_3.14». kernelnewbies.org (en inglés). 30 de diciembre de 2017. Consultado el 18 de enero de 2018. 
  32. Fogh, Anders; Gruss, Daniel. «Blackhat USA 2016, Using Undocumented CPU Behavior to See into Kernel Mode and Break KASLR in the Process» (en inglés). 
  33. Lipp, Moritz; Gruss, Daniel; Spreitzer, Raphael; Maurice, Clémentine; Mangard, Stefan (10 de agosto de 2016). «ARMageddon: Cache Attacks on Mobile Devices» (en inglés). Consultado el 9 de enero de 2018. 
  34. Maurice, Clémentine; Lipp, Moritz. «What could possibly go wrong with <insert x86 instruction here>?». 
  35. Gras, Ben; Razavi, Kaveh; Bosman, Erik; Box, Herbert; Giuffrida, Cristiano (27 de febrero de 2017). «ASLR on the Line: Practical Cache Attacks on the MMU» (en inglés). Consultado el 9 de enero de 2018. 
  36. [1]
  37. «KASLR is Dead: Long Live KASLR» (en inglés). 
  38. ESSoS 2017: Engineering Secure Software and Systems (en inglés). 
  39. Gruss, Daniel (3 de enero de 2018). «#FunFact: We submitted #KAISER to #bhusa17 and got it rejected». Archivado desde el original el 8 de enero de 2018. Consultado el 8 de enero de 2018 – via Twitter. 
  40. a b c d Lipp, Moritz; Schwarz, Michael; Gruss, Daniel; Prescher, Thomas; Haas, Werner; Mangard, Stefan; Kocher, Paul; Genkin, Daniel; Yarom, Yuval; Hamburg, Mike. «Meltdown» (PDF). Meltdown and Spectre (en inglés). p. 8 sec. 5.1. Consultado el 4 de enero de 2018. 
  41. «Negative Result Reading Kernel Memory from user Mode». CyberWTF.com (en inglés). 28 de julio de 2017. 
  42. a b «Meltdown and Spectre: Which systems are affected by Meltdown?». meltdownattack.com (en inglés). Consultado el 3 de enero de 2018. 
  43. «Kernel ASLR on amd64». 2017. Consultado el 16 de octubre de 2017. 
  44. «Apple Open Source». 2017. 
  45. Ionescu, Alex (14 de noviembre de 2017). «Windows 17035 Kernel ASLR/VA Isolation In Practice (like Linux KAISER)» (en inglés). Twitter. Archivado desde el original el 6 de enero de 2018. Consultado el 6 de enero de 2018. 
  46. Gibbs, Samuel (4 de enero de 2018). «Meltdown and Spectre: ‘worst ever’ CPU bugs affect virtually all computers» (en inglés). The Guardian. Archivado desde el original el 6 de enero de 2018. Consultado el 6 de enero de 2018. 
  47. «Kernel-memory-leaking Intel processor design flaw forces Linux, Windows redesign». The Register (en inglés). 2 de enero de 2018. Consultado el 5 de enero de 2018. 
  48. «Information Leak via speculative execution side channel attacks (CVE-2017-5715, CVE-2017-5753, CVE-2017-5754 aka Spectre and Meltdown)». Ubuntu Wiki (en inglés). Consultado el 4 de enero de 2018. 
  49. «A Critical Intel Flaw Breaks Basic Security for Most Computers» (en inglés). Wired. 3 de enero de 2018. 
  50. a b «Arm Processor Security Update». ARM Developer (en inglés). ARM Ltd. 3 de enero de 2018. Consultado el 5 de enero de 2018. 
  51. «Intel's processors have a security bug and the fix could slow down PCs». The Verge (en inglés). Consultado el 3 de enero de 2018. 
  52. a b «Linux Gaming Performance Doesn't Appear Affected By The x86 PTI Work - Phoronix». www.phoronix.com (en inglés). Consultado el 3 de enero de 2018. 
  53. Lendacky, Tom. «[tip:x86/pti] x86/cpu, x86/pti: Do not enable PTI on AMD processors». lkml.org (en inglés). Consultado el 3 de enero de 2018. 
  54. «Intel Responds to Security Research Findings». Intel (en inglés). 3 de enero de 2018. Consultado el 4 de enero de 2018. 
  55. Miranda, Luis (3 de enero de 2018). «Intel da la cara y dice que el error abarca múltiples dispositivos». Fayerwayer. Consultado el 4 de enero de 2018. 
  56. «Patches arrive for Intel's ‘Meltdown’ flaw — here's how to protect your device». Digital Trends (en inglés). 4 de enero de 2018. 
  57. «An Update on AMD Processor Security» (en inglés). 
  58. «Who's affected by computer chip security flaw». The Augusta Chronicle (en inglés). 4 de enero de 2018. Archivado desde el original el 4 de enero de 2018. Consultado el 6 de enero de 2018. 
  59. «Kernel-memory-leaking Intel processor design flaw forces Linux, Windows redesign». The Register (en inglés). 2 de enero de 2018. 
  60. Staff (2018). «Meltdown and Spectre-faq-systems-spectre». Universidad Tecnológica de Graz (en inglés). Consultado el 4 de enero de 2018. 
  61. Busvine, Douglas; Nellis, Stephen (3 de enero de 2018). «Security flaws put virtually all phones, computers at risk». Reuters (en inglés). Thomson-Reuters. Consultado el 3 de enero de 2018. 
  62. «Today's CPU vulnerability: what you need to know». Google Security Blog (en inglés). 3 de enero de 2018. 
  63. Saad, Abdullah (3 de enero de 2018). «Google Pitches In On x86 Kernel Bug - 3 Variants, Intel & ARM Chips Mostly Affected, Near Zero Risk To AMD». Wccftech.com (en inglés). 
  64. «Google: Almost All CPUs Since 1995 Vulnerable To "Meltdown" And "Spectre" Flaws». bleepingcomputer.com (en inglés). 3 de enero de 2018. 
  65. «P6 family microarchitecture». www.jaist.ac.jp (en inglés). 
  66. Hackett, Robert (4 de enero de 2018). «Understanding Those Alarming Computer Chip Security Holes: 'Meltdown' and 'Spectre'». Fortune (en inglés). 
  67. Sims, Gary (4 de enero de 2018). «'Spectre' and 'Meltdown': New CPU vulnerabilities affect most smartphones and computers». Android Authority (en inglés). 
  68. «Why Raspberry Pi isn’t vulnerable to Spectre or Meltdown». raspberrypi.org (en inglés). Raspbery Pi. 5 de enero de 2018. Consultado el 5 de enero de 2018. 
  69. https://www.ibm.com/blogs/psirt/potential-impact-processors-power-family/
  70. Liam Tung (10 de enero de 2018). «Meltdown-Spectre: IBM preps firmware and OS fixes for vulnerable Power CPUs» (en inglés). 
  71. «Solaris+SPARC is Meltdown (CVE-2017-5754) free - Tales from the Datacenter». Tales from the Datacenter (en inglés estadounidense). 22 de enero de 2018. Consultado el 23 de enero de 2018. 
  72. Lipp, Moritz (4 de enero de 2018). «Chip-Sicherheitslücke: "Alle sind betroffen" (Interview von Hakan Tanriverdi)» (html). Süddeutsche Zeitung (en alemán). Archivado desde el original el 4 de enero de 2018. Consultado el 31 de diciembre de 2018. «Stellen Sie sich das wie einen Wettlauf vor. Der Prozessor holt sich Daten und überprüft, ob Sie als Nutzer diese überhaupt lesen dürfen. Hier kann es passieren, dass der Prozessor mit Daten rechnet, bei denen er erst im Nachhinein, während der Prüfung merkt, dass er das nicht hätte tun dürfen. » 
  73. a b Galowicz, Jacek (3 de enero de 2018). «Cyberus Technology Blog - Meltdown». blog.cyberus-technology.de (en inglés). Consultado el 5 de enero de 2018. 
  74. Wheeler, Eric (4 de enero de 2018). «Meltdown BUG: What about KVM/Xen/Docker/OpenVZ/LXC/PV-Xen/HyperV?». www.linuxglobal.com (en inglés). 
  75. Bhat, Akshay (17 de enero de 2018). «Meltdown and Spectre vulnerabilities». timesys.com (en inglés). Consultado el 23 de enero de 2018. «unless your product allows running 3rd party or WEB applications, we believe the device is not exposed to exploits ». 
  76. Staff (3 de enero de 2018). «Intel Responds To Security Research Findings». Intel (en inglés). Consultado el 4 de enero de 2018. 
  77. Kroah-Hartman, Greg (2 de enero de 2018). «Linux 4.14.11 Changelog». kernel.org (en inglés). 
  78. Kroah-Hartman, Greg (5 de enero de 2018). «Linux 4.9.75 Changelog». kernel.org (en inglés). 
  79. «KAISER: hiding the kernel from user space [LWN.net]». lwn.net (en inglés). Consultado el 5 de enero de 2018. 
  80. «The current state of kernel page-table isolation [LWN.net]». lwn.net (en inglés). Consultado el 5 de enero de 2018. 
  81. «Red Hat Customer Portal». access.redhat.com (en inglés). Consultado el 5 de enero de 2018. 
  82. «Red Hat Customer Portal». access.redhat.com (en inglés). Consultado el 5 de enero de 2018. 
  83. «[CentOS-announce] CESA-2018:0008 Important CentOS 6 kernel Security Update». CentOS announcements (en inglés). 4 de enero de 2018. Consultado el 5 de enero de 2018. 
  84. «[CentOS-announce] CESA-2018:0007 Important CentOS 7 kernel Security Update». CentOS announcements (en inglés). 4 de enero de 2018. Consultado el 5 de enero de 2018. 
  85. «Kernel-memory-leaking Intel processor design flaw forces Linux, Windows redesign». The Register (en inglés). Consultado el 3 de enero de 2018. 
  86. «About the security content of macOS High Sierra 10.13.2, Security Update 2017-002 Sierra, and Security Update 2017-005 El Capitan». Apple Support (en inglés estadounidense). Consultado el 18 de enero de 2018. 
  87. «About the security content of iOS 11.2». Apple Support (en inglés estadounidense). Consultado el 18 de enero de 2018. 
  88. «About the security content of tvOS 11.2». Apple Support (en inglés estadounidense). Consultado el 18 de enero de 2018. 
  89. «About speculative execution vulnerabilities in ARM-based and Intel CPUs». Apple Support (en inglés estadounidense). Consultado el 18 de enero de 2018. 
  90. «Apple Releases macOS High Sierra 10.13.2 Supplemental Update With Spectre Fix» (en inglés). Consultado el 18 de enero de 2018. 
  91. «Apple Releases iOS 11.2.2 With Security Fixes to Address Spectre Vulnerability» (en inglés). Consultado el 18 de enero de 2018. 
  92. «About the security content of Safari 11.0.2». Apple Support (en inglés estadounidense). Consultado el 18 de enero de 2018. 
  93. «About the security content of macOS High Sierra 10.13.2 Supplemental Update». Apple Support (en inglés estadounidense). Consultado el 18 de enero de 2018. 
  94. «About the security content of iOS 11.2.2». Apple Support (en inglés estadounidense). Consultado el 18 de enero de 2018. 
  95. Warren, Tom. «Microsoft issues emergency Windows update for processor security bugs». The Verge (en inglés). Vox Media, Inc. Consultado el 3 de enero de 2018. 
  96. Thorp-Lancaster, Dan (3 de enero de 2018). «Microsoft pushing out emergency fix for newly disclosed processor exploit». Windows Central (en inglés). Consultado el 4 de enero de 2018. 
  97. «Windows Client Guidance for IT Pros to protect against speculative execution side-channel vulnerabilities». support.microsoft.com (en inglés). Consultado el 4 de enero de 2018. 
  98. «Windows Server guidance to protect against speculative execution side-channel vulnerabilities». support.microsoft.com (en inglés). Consultado el 5 de enero de 2018. 
  99. a b Ranger, Steve. «Windows Meltdown and Spectre patches: Now Microsoft blocks security updates for some AMD based PCs». ZDNet. Consultado el 9 de enero de 2018. 
  100. Tung, Liam. «Windows Meltdown-Spectre patches: If you haven't got them, blame your antivirus». ZDNet. Consultado el 4 de enero de 2018. 
  101. «Important information regarding the Windows security updates released on January 3, 2018 and anti-virus software» (en inglés). Microsoft. Consultado el 4 de enero de 2018. 
  102. «Westmere Arrives». www.realworldtech.com (en inglés estadounidense). Consultado el 5 de enero de 2018. 
  103. «A Critical Intel Flaw Breaks Basic Security for Most Computers». Wired (en inglés estadounidense). Consultado el 4 de enero de 2018. 
  104. «Intel CPU kernel bug FAQ: Fix for massive security flaw could slow down PCs and Macs». PCWorld (en inglés). Consultado el 4 de enero de 2018. 
  105. «Initial Benchmarks Of The Performance Impact Resulting From Linux's x86 Security Changes - Phoronix». www.phoronix.com (en inglés). Consultado el 5 de enero de 2018. 
  106. Nichols, Shaun (5 de enero de 2018). «Here come the lawyers! Intel slapped with three Meltdown bug lawsuits». The Register (en inglés). Consultado el 9 de enero de 2018. 
  107. «Warning: Microsoft's Meltdown and Spectre patch is bricking some AMD PCs». betanews.com (en inglés). Consultado el 9 de enero de 2018. 
  108. Tung, Liam. «Windows Meltdown-Spectre update: Some AMD PC owners post crash reports | ZDNet». ZDNet (en inglés). Consultado el 9 de enero de 2018. 
  109. Brown, Aaron (8 de enero de 2018). «Windows 10 WARNING: Some users unable to boot PCs after emergency Meltdown-Spectre patch». Express.co.uk (en inglés). Consultado el 9 de enero de 2018. «According to the complaints, it appears the problems are most prevalent in AMD Athlon systems [...] ». 
  110. «Understanding the performance impact of Spectre and Meltdown mitigations on Windows Systems» (en inglés). Microsoft. 9 de enero de 2018. 

Enlaces externos

Esta página se editó por última vez el 25 ene 2024 a las 16:20.
Basis of this page is in Wikipedia. Text is available under the CC BY-SA 3.0 Unported License. Non-text media are available under their specified licenses. Wikipedia® is a registered trademark of the Wikimedia Foundation, Inc. WIKI 2 is an independent company and has no affiliation with Wikimedia Foundation.