CERT (Computer Emergency Response Team) es un centro de respuesta a incidentes de seguridad en tecnologías de la información creado en 1988 como respuesta al incidente del gusano Morris. Mientras Microsoft, Amazon y Google afirman que sus equipos están protegidos, CERT asegura que la mejor solución es cambiar la CPU afectada.
|
etiquetas: cert , intel , amd , meltdown , spectre 
Hay tecnología, hay meneo.
Hay noticia, hay meneo.
A ver si estás descubriendo a estas alturas de lo que va menéame...
supongo que el problema en cuestión será que se pueda acceder de forma inadvertida, porque lo que es acceder a la memoria de otros procesos (al menos de usuario) es posible usando llamadas de la API de Windows (ejemplo):
(...)
process = Process.GetProcessesByName(name)[0];
(...)
processHandle = OpenProcess(PROCESS_WM_READ, false, process.Id);
IntPtr baseAddress = process.MainModule.BaseAddress;
IntPtr newAddress = IntPtr.Add(baseAddress, OFFSET);
byte[] buffMem = new byte[4]; //This is needed for a temporary conversion.
ReadProcessMemory((int)processHandle, newAddress.ToInt32(), buffMem, 4, ref bytesRead);
Y el rendimiento de ARM sobre x86... Por favor, no todo es consumo, no olvidemos que a los PCs de sobremesa/portátiles no necesitan consumos ridículos si no rendimiento para mover muchas apps y muy exigentes. ¿Que mueven android e iOS sobre ARM? Aplicaciones simples. Si el rendimiento no importase tanto no importaría perder un 30% de rendimiento para aplicar ese parche que solucione la cagada de Intel. Pero es que resulta que el rendimiento si importa.
Y si, los ejemplos de como volcar el gestor de contraseña de firefox se refiere a si el mismo está cargado en memoria desde un proceso en ejecución, en ningún caso desde un javascript, tarugo.
En el caso del Pentium el fallo se corrigió cambiando unos valores en una tabla. En este caso no sé si habría una solución rápida que no afectara al rendimiento.
Dado que el bug actual afecta a todos los modelos desde el 95' ... es imposible que cambien las CPUs. Como mucho lo harán en secreto con sus clientes mas importantes (gobiernos, grandes empresas, etc..) el resto no vamos a ver ni un euro.
El tema es que el problema no es un valor en un tabla, sino que es un tema de arquitectura. Hay que hacer una arquitectura nueva, probar que funciona, fabricarlo y venderlo.
Vamos, que tenemos que rehacer los 10 últimos años de la tecnología caché y temas de predicciones de código.
Ja ja ja ja ja ja ja ja
Está claro que no sabes lo complejísimo que es un microprocesador moderno. Además de que no estamos hablando de un fallo menor en una unidad funcional concreta, si no del mecanismo de ejecución especulativa y de la predicción de saltos. Habría que rediseñar prácticamente toda la lógica de control, y eso no se hace en un par de meses.
As a proof-of-concept, JavaScript code was written that, when run in the Google Chrome browser, allows JavaScript to read private memory from the process in which it runs (cf. Listing 2). The portion of the JavaScript code used to perform the leakage is as follows.
Dentro del articulo tienes el código en javascript y el desensamblado. La prueba demuestra que es posible por parte de codigo javascript leer la memoria del proceso que lo ejecuta (el navegador). Si tienes curiosidad, la parte de codigo en javascript exacta que engaña al BP:
if (index < simpleByteArray.length) {
index = simpleByteArray[index | 0];
index = (((index * TABLE1_STRIDE)|0) & (TABLE1_BYTES-1))|0;
localJunk ^= probeTable[index|0]|0;
}
Es un poco mas lento que uno normal, ya que hay ciertas limitaciones, pero funciona.
Dado que el white paper igual no es suficiente para ti, aqui tienes a la gente de Mozilla explicando lo que van a hacer para mitigar el problema:
blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-tim
Presta atencion a lo que dice aqui:
Our internal experiments confirm that it is possible to use similar techniques from Web content to read private information between different origins
Esa es la confirmación de que es vulnerable via ataques de JS.
Pero nada, tu sigue en tus trece.
Respuesta larga: ya te la ha dado el usuario aiguy
Por eso digo, que afirmar simplemente "antes del bug no era posible acceder a la memoria de otro proceso" no es correcto. La verdad es que no me he leido el paper, supongo que tendrá más matices.
Aquí muestro 3 demandas que ya se han presentado contra Intel:
es.scribd.com/document/368434221/District-of-Oregon
es.scribd.com/document/368434313/northern-district-of-californian
es.scribd.com/document/368434285/southern-district-of-indiana
A ver si Europa aprovecha y fabrica sus propios procesadores, pero creo que antes lo aprovechará alguna empresa China.
Por otro lado debemos reconocer que somos dependientes de esas tres multinacionales. Simplemente no pueden caer porque no disponemos de alternativas a su mismo nivel, no podemos permitirnos prescindir de ellas. La tecnología actual depende de ellas y en buena de media depende de sus patentes y secretos corporativos en diseños y procesos de fabricación. Es lo que hay si los gobiernos no se toman los temas de la independencia tecnológica totalmente en serio.
(CC #15)
dle.rae.es/?id=Gu1umDT
Por que es mentira, así, sin más.
En cualquier caso, podría TAL VEZ (que ni de coña) pedir memoria dentro del propio navegador, pero más allá de eso NO por que los navegadores implementan control de puntero al JavaScript.
Pero vale.
A día de hoy hay poca capacidad de fabricación en Europa, pero siempre se puede diseñar un chip y encargar la fabricación a TSMC o similar.
lkml.org/lkml/2018/1/3/797
Creo que el más perjudicado de todo esto ha sido intel, y parece que es solo el principio.
El problema es para las aplicaciones que ejecutan código de terceros que en teoría no puede hacer todo lo que le de la gana (todo lo que se ejecute en sandboxes [1] básicamente). Ejemplos: javascript en los navegadores (te podrían leer cookies/sesiones de otras webs), javascript en adobe reader (te podrían robar certificados que uses para firmar pdfs), stored procedures en un servidor (MS|Postgre|My)SQL (podrían acceder a tablas/bases de datos para las que el usuario no tiene permiso), etc..
[1] en.wikipedia.org/wiki/Sandbox_(computer_security)
El tema es que el código para disparar este bug es código aparentemente normal: no hay que hacer llamadas de sistema como las que hace tu snippet (que se pueden controlar fácilmente en una sandbox) ni nada que hasta ahora se hubiera considerado sospechoso. Por tanto, actualmente es muy difícil de detectar y prevenir.
Ademas, que todo eso sería para volver a donde estabamos hace 10 años. Si se quiere hacer algo mas moderno, se tiene que hacer un trabajo de investigación del copón.
Supongo que estabas exagerando en #48, pero.. no es un curro de pocos meses ni de coña.
El cambio, afecta al monitor también, si tienes uno de los últimos y carísimos G-Sync (intel+nvidia) o freesync (amd)
Yo en todos estos largos años, empecé con intel, luego AMD, luego Intel, luego AMD, y finalmente un I7 de intel.
Yo ya sabía que Intel, en su día, en la época del 386 y el 486 (muchos tendréis que ir a wikipedia para ver de que hablo), había 2 modelos, el SX y el DX. El SX era más barato porque no tenía coprocesador matemático, el DX era más caro porque sí lo traía.
Intel en realidad fabricaba el mismo procesador, y antes de venderlo se cargaba el copro a propósito y lo vendía como SX
Estamos hablando de gentuza, que lleva décadas siendo gentuza. Nunca adoptaron tecnologías novedosas como Silicon Graphics, y las que salieron lo hicieron décadas después a base de estirar la gallina de los huevos de oro, o retrocompatiblidad que le llamaban ellos, y seguimos arrastrando una arquitectura que no permite apenas a los ordenadores actuales trabajar en paralelo salvo entre un par de componentes con buses dedicados y multiplicar sus prestaciones de todo el ordenador en general.
Ahora, nada más quedaba saber este último escándalo, a lo que añado, que igual algunos no lo recordáis, que cuando salió el PENTIUM había una división que jodía el procesador y tuvieron que arreglarlo cambiando micros. De eso igual ya tampoco se acuerda nadie... hace 17 años.
Y otra cosa, los AMD se te podían quemar, aunque tenían una aviso de temperatura, si fallaba el ventilador o hacía demasiado calor. Pero Intel, hacía como la indigna Apple (otros miserables), te tocaba el rendimiento del hardware por bajo mano sin avisarte ni nada,
de tú hardware, el que tú habías comprado. Supongo que ahí es donde empezaron a perder el respeto al cliente que le costeaba sus micros y todo lo imaginable y empezaron a maltratar a la gente.
No, no he visto ese código en ejecución. Tampoco he visto el de meltdown. No me hace falta. La elegancia de estos ataques es que te lees el White paper y no te preguntas como funcionan, eso se hace evidente, la pregunta es como no nos habíamos dado cuenta antes de ese fallo de seguridad. Se me da bien la arquitectura x86 (y x64). He pasado incontables horas mirando depurando código ensamblador (por trabajo, tengo hobbies más ligeros). Basándome en mi experiencia, estos ataques permiten hacer lo que dicen que pueden hacer. Curiosamente, es una opinión compartida por muchos
Los procesadores que están actualmente diseñados para sacarlos al mercado tal vez dentro de un par de años, y que tal vez ya estén en proceso de fabricación, tienen una gran diferencia en capacidad de procesamiento comparados con procesadores que salieron al mercado hace ya varios años. Me baso sobre todo en la ley de Moore.
Lo de la división me gustaría matizarlo: el procesador no se estropeaba, sino que la división la hacían mal y les tocó cambiar procesadores.
Lo del DX y SX también me gustaría matizarlo: lo que hacían era que si el procesador de punto flotante funcionaba mal, lo anulaban, lo que ya no se es si llegaron a anular procesadores en buen estado.
Respecto a las arquitecturas, también hay que valorar una cosa: hoy en día muchos programas antiguos funcionan bien en ordenadores actuales... si hacemos cambios de arquitectura... adiós muy buenas. También hay que decir que esto podría arreglarse con más código abierto y compilación.
Lo de "antes" que aparece tachado en los precios de Amazon debe ser de cuando salieron al mercado.
Lo de las arquitecturas, es una estupidez seguir arrastrando fallos de diseño o decisiones de compromiso al 2018.
Hoy en día se puede virtualizar cualquier máquina y configuración hardware, lo que hay que hacer es dejar atrás los remilgos e intentar fabricar las máquinas más potentes que puedan emular eso sin problemas. El hardware ya no debería estar condicionado por el software ni mucho menos si es además, antiguo.
Los AMD no se quemaban, se apagaban antes de quemarse, y además en la Bios se podía configurar bastante el tema, si tenías una placa base medio decente claro.
Diseñar, probar, arreglar errores, volver a diseñar, construir, ....
El proceso anterior costó una década, no creo que se tarde menos de cinco años antes de tener un producto seguro a la altura del actual.
AMD se toma la seguridad en serio en sus arquitecturas y me alegro de haber apostado siempre por ellos.
Nota: llevo 4 años usando un micro AMD y le tengo bastante odio a Intel.
#113 Respecto a lo de que hay que hacer una nueva arquitectura no estoy tan seguro, puede que encuentren una solución sencilla. Además, más les vale encontrarla, si no, ¿quién va a comprarles otro procesador?.