Portada
mis comunidades
otras secciones
#6:
Desde mis conocimientos de informática, como desarrollador, me atrevería a afirmar:
Esto quiere decir que llevamos 23 años en bragas, es decir, que tanto antivirus, tanto ACL, tanta cuenta de acceso restringida, tanta capa de software para asegurar ejecución en 'sandbox'... no han servido para una puta mierda, que los señores de la NSA / CBP / MOSSAD / Hackers chinos, han tomado siempre cuanto han querido y más.
¿O me equivoco?
Esto quiere decir que llevamos 23 años en bragas, es decir, que tanto antivirus, tanto ACL, tanta cuenta de acceso restringida, tanta capa de software para asegurar ejecución en 'sandbox'... no han servido para una puta mierda, que los señores de la NSA / CBP / MOSSAD / Hackers chinos, han tomado siempre cuanto han querido y más.
¿O me equivoco?
#43:
#28 Eso a mí me esta mosqueando, lo de sacar los dos bugs juntos como si fuesen lo mismo cuando al parecer lo de AMD y ARM se podría solucionar de una forma más eficiente y no es fruto de una negligencia equivalente...
Me da la impresión de que se están juntando para defender con humo y confusión a Intel de su mala praxis.
Al final nos torean como quieren, encima publicidad a Google por encontrar dos por uno ¿Tanto les costaba poner cada problema en su propio dominio? ¿Económicamente o en alianza estratégica con Intel?
Me da la impresión de que se están juntando para defender con humo y confusión a Intel de su mala praxis.
Al final nos torean como quieren, encima publicidad a Google por encontrar dos por uno ¿Tanto les costaba poner cada problema en su propio dominio? ¿Económicamente o en alianza estratégica con Intel?
#75:
#6 Te equivocas. Todo eso que has mencionado funciona, y sirve de mucho.
Este ataque es grave, pero ni siquiera permite escalar privilegios. Se puede acceder a memoria privilegiada pero sólo en modo lectura, lo que permite exfiltración de datos pero nunca escalada de privilegios.
Para que te hagas una idea, muy resumido: si la máquina la usas tú solo, o la usas con software no malicioso, no hay peligro. El problema vendría en máquinas multiusuario, o en máquinas donde hay ejecutando software malintencionado.
Este ataque es grave, pero ni siquiera permite escalar privilegios. Se puede acceder a memoria privilegiada pero sólo en modo lectura, lo que permite exfiltración de datos pero nunca escalada de privilegios.
Para que te hagas una idea, muy resumido: si la máquina la usas tú solo, o la usas con software no malicioso, no hay peligro. El problema vendría en máquinas multiusuario, o en máquinas donde hay ejecutando software malintencionado.
#33:
#29 "Which systems are affected by Spectre?
Almost every system is affected by Spectre: Desktops, Laptops, Cloud Servers, as well as Smartphones. More specifically, all modern processors capable of keeping many instructions in flight are potentially vulnerable. In particular, we have verified Spectre on Intel, AMD, and ARM processors."
Almost every system is affected by Spectre: Desktops, Laptops, Cloud Servers, as well as Smartphones. More specifically, all modern processors capable of keeping many instructions in flight are potentially vulnerable. In particular, we have verified Spectre on Intel, AMD, and ARM processors."
#3:
#1 Parece que sí, es como los huracanes y tormentas tropicales o las operaciones policiales.
La vulnerabilidad krack tambien.
https://www.krackattacks.com/
Entre
Meltdown
Spectre
Krack
"CVE-2017-5689 Intel Management Engine Vulnerability" igual no se recuerda tan bien ni tiene tanto gancho.
La vulnerabilidad krack tambien.
https://www.krackattacks.com/
Entre
Meltdown
Spectre
Krack
"CVE-2017-5689 Intel Management Engine Vulnerability" igual no se recuerda tan bien ni tiene tanto gancho.
#46:
#14 Al final, a falta de leerme los papers academicos, el articulo del meltdown no explica la parte final de como saber cual de esas 256 paginas, indexadas por el byte leido en la primera parte de la ejecucion especulativa de ese gadget, es el que se lee en la segunda parte de la ejecucion especulativa de ese gadget. Y ese paso final son los cache side channel attacks que vienen de 2016 o quiza 2015. Que basicamente es:
a) flushear cache
b) empezar medicion de tiempo
c) acceder a una direccion de memoria
d) terminar medicion de tiempo
e) calibrando esto, repitiendolo para reducir el "ruido" si hace falta, etc., saber si ese dato estaba en la cache, lo que llaman "warm". Esto tiene implicaciones varias pero en este caso es saber si ese gadget ha cargado una u otras paginas en cache ( en realidad no toda la pagina, mas bien una linea del comienzo de cada pagina, pero les vale para saber cual de esas paginas se ha "tocado" ).
Modificando esto, metiendo la ejecucion del gadget entre a) y b) y haciendo las mediciones para las paginas de 0 hasta 255 o hasta ver la que "tarda poco" por estar en cache ( eso que llaman "warm" ), saben cual ha sido ese indice que se lee en la primera instruccion en la ejecucion especulativa del gadget.
Es jodidamente elegante.
a) flushear cache
b) empezar medicion de tiempo
c) acceder a una direccion de memoria
d) terminar medicion de tiempo
e) calibrando esto, repitiendolo para reducir el "ruido" si hace falta, etc., saber si ese dato estaba en la cache, lo que llaman "warm". Esto tiene implicaciones varias pero en este caso es saber si ese gadget ha cargado una u otras paginas en cache ( en realidad no toda la pagina, mas bien una linea del comienzo de cada pagina, pero les vale para saber cual de esas paginas se ha "tocado" ).
Modificando esto, metiendo la ejecucion del gadget entre a) y b) y haciendo las mediciones para las paginas de 0 hasta 255 o hasta ver la que "tarda poco" por estar en cache ( eso que llaman "warm" ), saben cual ha sido ese indice que se lee en la primera instruccion en la ejecucion especulativa del gadget.
Es jodidamente elegante.
#13:
Que risas cuando vuelva al trabajo y me pregunten si los sistemas estan en peligro...
Comentarios
Desde mis conocimientos de informática, como desarrollador, me atrevería a afirmar:
Esto quiere decir que llevamos 23 años en bragas, es decir, que tanto antivirus, tanto ACL, tanta cuenta de acceso restringida, tanta capa de software para asegurar ejecución en 'sandbox'... no han servido para una puta mierda, que los señores de la NSA / CBP / MOSSAD / Hackers chinos, han tomado siempre cuanto han querido y más.
¿O me equivoco?
#6 Hombre, servir ha servido... siempre que nadie se haya coscado de estos errores hace años y se lo haya quedado para su uso y disfrute.
Un bug que nadie detecta, es como si no hubiera existido.
El problema es que ahora es un marrón de tamaño universal.
#9 lo de callarse estos fallos para su uso y disfrute y comerciar con ellos en el mercado negro es justo lo que hacen la NSA y otros criminales
#6 Puede que la NSA si, grupos de hackers lo dudo. El ataque es bastante sofisticado y llamarlo bug no me parece muy correcto. Vulnerabilidad si, lo es, pero es debido a como funcionan los procesadores más que a un fallo en si. Parchear la vulnerabilidad , por lo que he entendido, es poco más que desactivar la característica de los procesadores que la provoca.
#14 Al final, a falta de leerme los papers academicos, el articulo del meltdown no explica la parte final de como saber cual de esas 256 paginas, indexadas por el byte leido en la primera parte de la ejecucion especulativa de ese gadget, es el que se lee en la segunda parte de la ejecucion especulativa de ese gadget. Y ese paso final son los cache side channel attacks que vienen de 2016 o quiza 2015. Que basicamente es:
a) flushear cache
b) empezar medicion de tiempo
c) acceder a una direccion de memoria
d) terminar medicion de tiempo
e) calibrando esto, repitiendolo para reducir el "ruido" si hace falta, etc., saber si ese dato estaba en la cache, lo que llaman "warm". Esto tiene implicaciones varias pero en este caso es saber si ese gadget ha cargado una u otras paginas en cache ( en realidad no toda la pagina, mas bien una linea del comienzo de cada pagina, pero les vale para saber cual de esas paginas se ha "tocado" ).
Modificando esto, metiendo la ejecucion del gadget entre a) y b) y haciendo las mediciones para las paginas de 0 hasta 255 o hasta ver la que "tarda poco" por estar en cache ( eso que llaman "warm" ), saben cual ha sido ese indice que se lee en la primera instruccion en la ejecucion especulativa del gadget.
Es jodidamente elegante.
#46 Los estuve ojeando un poco. La cagada real es que todos los fabricantes mapean la memoria completa del sistema en el espacio de usuario confiando en que la implementación en hardware es infalible, y al menos así parecía hasta ahora. El parche de KAISER lo que hace es mapear únicamente el trozo que va a necesitar el proceso de usuario y crea una copia para cada proceso de las estructuras del kernel que necesita.
#59 Eso no es ninguna cagada; mapear memoria de kernel y de usuario en el mismo espacio de direcciones es lo correcto ( por razones obvias, como por ejemplo que el kernel pueda acceder a los buffers de salida pasados en las peticiones de modo usuario ). Que esto haga que hagan una CHAPUZA y pasen a un distema dual "solo memoria de usuario" para modo usuario y "memoria de kernel MAS memoria de usuario" ( y pongo esto asi por que estoy viendo que la gente lo esta entendiendo mal, si no fuera asi no funcionaria y habria que rediseñar muchisimas cosas de los kernel Y reescribir muchos drivers ) es otra cosa.
La cagada es la suma de a) no chequear privilegios en direcciones de memoria ANTES de traer lineas de memoria desde esa direccion a cache en la ejecucion especulativa y b) side channel attacks en cache ( que esto es una vulnerabilidad como efecto de timing de cache, no exactamente un bug ).
#46 #59 #70 Yo me llamo Ralph.
Gracias por la información, intentaré ir buscando punto por punto a ver si consigo entenderla.
#6 Se puede ir más alla, y pensar que la NSA conocía la vulnerabilidad pero presionó a Intel para que no la corrigiera, y algunos pesos pesados de Intel pusieron las barbas a remojar cuando se avecinaba su publicación. No es probable, pero oye, me apetecía ponerme el gorrito de aluminio.
#34 teniendo en cuenta que intentaron meter cosas en el generador del kernel linux y que la criptografía que se exportaba desde eeuu hasta hace poco era mas floja que la doméstica (5 de la mañana perdón si uso términos no correctos) pues no me extrañaría nada de nada...
#36 Este ataque es demasiado sofisticado hasta para la CIA, y estoy de acuerdo con el "paranoico no es suficiente", pero especular que sólo ellos lo conocían es absurdo. Lo correcto es pensar que todo el mundo lo podía conocer y parchear todos los equipos como si no hubiera un mañana.
cc #34
#6 ¿Acaso no lo sospechabas?
#6 En la página, en la sección de preguntas y respuestas dice:
Can I detect if someone has exploited Meltdown or Spectre against me?
Probably not. The exploitation does not leave any traces in traditional log files.
#6 - ¿Me equivoco Nota?
)
- No te equivocas.
- ¿Me equivoco?
- No te equivocas pero eres un gilipollas.
(Me ha recordado a esta mierda, lo siento
Por cierto, no te equivocas.
#6 Me autocito, esto aplicará por siempre: microsoft-vuelve-lanzar-actualizaciones-seguridad-windows-xp/c019#c-19
Microsoft vuelve a lanzar actualizaciones de segur...
cyberseguridad.net#6 Bueno, pues creo que no. Imagino que han liberado esto porque ya tienen suficiente con nuestros telefonos android.
#6 Te equivocas. Todo eso que has mencionado funciona, y sirve de mucho.
Este ataque es grave, pero ni siquiera permite escalar privilegios. Se puede acceder a memoria privilegiada pero sólo en modo lectura, lo que permite exfiltración de datos pero nunca escalada de privilegios.
Para que te hagas una idea, muy resumido: si la máquina la usas tú solo, o la usas con software no malicioso, no hay peligro. El problema vendría en máquinas multiusuario, o en máquinas donde hay ejecutando software malintencionado.
#75 ¿Tienes más información sobre que se pueda o no modificar la memoria y no solo leer? Yo había leído que si.
#84 En cualquier sitio medianamente serio. Por ejemplo en el propio blog de Project Zero [1], primer párrafo (negritas mías):
"We have discovered that CPU data cache timing can be abused to efficiently leak information out of mis-speculated execution, leading to (at worst) arbitrary virtual memory read vulnerabilities across local security boundaries in various contexts."
[1] https://googleprojectzero.blogspot.com.es/2018/01/reading-privileged-memory-with-side.html
#86 Muchas gracias! Voy a corregir un par de cosas que he estado diciendo.
#75 pero eso es triste consuelo en cualquier máquina conectada a Internet que corra JavaScript. Una web maliciosa, en potencia, podría leer datos "sensibles"
#6 al final los hackeos de las pelis son más reales de lo que parecían!
#6 No te equivocas lo más mínimo.
Salu2
Que risas cuando vuelva al trabajo y me pregunten si los sistemas estan en peligro...
#13 Ya te digo, verás el lunes...
#13 Dile a todos que se soluciona poniendo un cactus delante de la pantalla.... si funcionó en los 90 no veo porque no funcionaría ahora
#18 Me acabas de matar, que cabron
No se , igual con una pulserita de esas biomagneticas , que me parece que colara mas.
#19 Pasate por un chino o todoacien ( ¿ todoaeuro ? ) de camino al curro y compra unos cuantos atrapasueños de plasticurrio verde fosfo. Si, son unos eurillos pero las risas en la oficina pueden ser buenas
#13 Llévate las manos a la cabeza y grítales: VAMOS A MORIR TODOOOOOS!!!!!!! Acto seguído échate al suelo y ponte en posición fetal entre sollozos. En caso extremo, puedes optar por hacerte el muerto
#20 Yo soy mas de correr en circulos agitando los brazos , para ahorrar en el gimnasio, pero tomo nota
#21 correr en círculos desnudo, mientras te vacías un bidón de gasolina encima suele ser más efectivo. A la gente le aterra ver unos genitales colgando.
#13
Si eres paranoico, sí, están en peligro. Los sistemas operativos todavía no han sacado los parches para mitigar los ataques.
La solución final es comprar chips nuevos + mitigación por software para que la probabilidad de éxito en un ataque sea prácticamente nula.
#23 Teniendo en cuenta que algunas maquinas todavia estan en XP porque el programa de control de las maquinas no esta disponible para plataformas posteriores...me da a mi que me voy a reir mucho
Menos mal que hay un poquito de seguridad perimetral pero vamos que si alguien esta decidido a entrar ,va a entrar. Casi que me voy a buscar curro en otra parte.
(Nadie ha hablado todavia de cajeros automaticos , que ahi si que va a ser una risa histerica)
#24 Si están con XP, tienen problemas mayores que este. Aunque si además de la seguridad perimétrica, no tiene tarjeta de red, podría valer.
#23 Y vaya solución para cualquier empresa con un mínimo de infraestructura informática. Nos esperan meses "interesantes" por delante.
#23. Claro que sí, todo el hardware mundial actual en funcionamiento a la basura y a comprar nuevo cruzando los dedos para que sea 100% seguro ,esta vez sí, para siempre...
¿Esta moda de llamar a los bugs importantes con nombres rimbombantes y ponerles logo y todo obedece a algún motivo? Ya sé que la primera vez lo hizo Microsoft para hacerle FUD a Linux pero eso fue una vez.
#1 Si, está de moda.
#1 Parece que sí, es como los huracanes y tormentas tropicales o las operaciones policiales.
La vulnerabilidad krack tambien.
https://www.krackattacks.com/
Entre
Meltdown
Spectre
Krack
"CVE-2017-5689 Intel Management Engine Vulnerability" igual no se recuerda tan bien ni tiene tanto gancho.
#3 sólo lo digo por curiosidad, me parece algo irritante pero también me encantan los logos, de cualquier cosa así que por ese lado me gusta
#12 nada, sólo preguntaba por curiosidad (#4), y bueno, encontré esto → #8
#4 Tú lo puedes llamar CVE-2017-5689 si te molesta.
#4 ¿No hemos tenido una conversación muy parecida casi identica a esta en otro hilo muy similar?
#30 no lo recuerdo. Es posible. Me irritan esos iconos y aun así me gustan los logos desde el heartbleed así que todo es posible.
#4 Lo siento te pulsé negativo por error, no era mi intención.
#56 > #4
#3 Se hace desde siempre, los bugs que se merecen un nombre propio,lo tienen.
Aun recuerdo una catástrofe parecida con los servidores web de microsoft, no filtraban bien los caracteres en unicode y con una cadena formada de cierta manera /x86/u45/ etc etc podías poner una url con ../../../ y , por lo tanto, retroceder directorios desde el público de la web...
Millones y millones de servidores empresariales estaban afectados, no solo de webs, sino con que tuvieran el IIS server instalado ya valía. Decían que el bug era una puerta trasera que llevaba desde los orígenes...
Se le llamó "el bug del Unicode"
#16 Eso se llama path travelsal, y en caso que citas se aprovechaba la codificion unicode para saltarse las protecciones que lo impedían.
#51 Y anteriormente a este bug ya habían sufrido uno tan simple como /%2E%2E/
Microsoft siempre ha sido un chiste en cuanto a seguridad
#3 Pero lo de meterle un logo sinsentido...
Es como si le pusieran logo al 23-F.
#1 Curioso artículo sobre el tema: https://medium.com/threat-intel/bug-branding-heartbleed-14ef1a64047f y unos cuantos logos: https://commons.wikimedia.org/wiki/Category:Security_vulnerability_logos a ver si suben todos los más nuevos.
#8 a ver si suben quiénes? Tu no pillas el concepto de la Wikipedia... Te doy 5 minutos para que los subas y ya estás tardando
#58 soy editor end la Wikipedia desde hace bastantes años. Sin embargo he subido / editado menos de 20 imágenes porque siempre me da miedo estropear algo. Pero sí, esa también es una opción.
Tengo una cuenta en deviantart linux-rules que dedico a subir iconos de 50x50 35x35 21x21 y 16x16 y muchas veces necesito saber di un icono es Fair use o Dominio público. Alguna vez el icono está mal o lo que sea. No es tan fácil como parece por ejemplo las empresas de Reino Unido tienen una protección de copyright de los logos esperpéntica (da igual que sean letras).
Pero gracias por los ánimos.
#45 eso parece #8
#1 Teniendo en cuenta que el error lo avisó google hace más de 6 meses y no ha habido parche aún, darle visibilidad pública es una excelente forma de forzar a que se tomen cartas en el asunto. Qué hay de malo en ello?
#1 Empezo con HeartBleed, creo, aunque quiza me equivoque:
http://heartbleed.com/
Ami estos logos que babean me recuerdan a:
https://dailyturd.files.wordpress.com/2011/10/swallow-or-its-going-in-your-eye.gif?w=450&zoom=2
#45
#72 Tronco:
¿ Me tomas el pelo ? ¿ Que aporta eso ?
#73 Antes de que tuviera nombre, era una propuesta basada en las características del error en cuestión. Va más como respuesta al hilo que específica para tí.
#74 ... ha tenido varios nombres, eso es un tweet de ayer, no se; respondes a un post mio donde hablamos del tema de poner nombres y logos a vulnerabilidades y yo digo que la cosa empezo con heartbleed.
Vamos, de donde vienes, manzanas traigo.
#1 la página web está muy bien hecha muy bien estructurada y los iconos ayudan, la información se ofrece en distintos niveles de forma muy clara en un primer vistazo y luego mas profusa en los papers y artículos que enlaza
Pero claro no estamos acostumbrados a este tipo de buen trabajo
Mas que vulnerabilidad esto me suena a diseño, purito diseño
#26 is not a bug is a feature.
#37
#26 Basicamente es quitar carga de trabajo de chequeo ANTES de los accesos en esa ejecucion especulativa. El arreglo en los proximos micros tampoco sera gratis, desdeluego ni de lejos la penalizacion del rediseño que traen estos parches, pero el IPC bajara algo, seguro.
La seguridad completa no existe... Pero es que confiar en un hardware cerrado tampoco es buena idea. Para empezar, cualquier gobierno que se precie debería obligar a los fabricantes a abrir el sistema hardware/software y comprobar que no tiene nada "raro". Y, sí. Las CPU actuales son obras de ingeniería extremadamente complejas, pero la seguridad nacional no debería depender de "cajas negras". Auditoría externa a Intel (y revisiones periódicas a hardware chino) desde ya.
#25 veo 2 problemas:
El código publico no soluciona los bugs, para ejemplo openssl y los cientos de scripts que tiene armitage para hackear un equipo con linux también lo muestra
Los propios gobiernos son los que presionan a las empresas (nsa)
#52 Querrás decir Metasploit, Armitage solo es una GUI. ¿cuantos de esos exploits son contra el sistema y no contra software que se instala en linux? Creo que mezclas churras con merinas.
#78 Eso metasploit, paso el mundo de la auditoria de pasada y me acordaba de armitage, pero no de metasploit. Y si puede que no haya ningún exploit directo contra el kernel, pero los Linux vienen con programas preinstalados a cascoporro, que pueden ser aprovechados.
La única ventaja del código abierto es que todos lo podemos ver (aunque solo lo entienda el 1% de la población), pero es un arma de doble filo. Solo digo eso. Y visto como va el mundo. Esta ventaja se puede volver contra uno mismo. O que los poderosos te aplasten con ello.
Mezclo mas bien chustas con meninas.
#80 La ultima vez que eche un ojo a los exploits creo que contra el sistema solo habia un par de escalada de privilegios, y de software preinstalado con exploits ya me diras tu a que parte del kernel te refieres, que es lo que es linux. Luego lo que haga cada distribución sobre el kernel es otra historia.
#85 pues eso, difícil, que no imposible en un entorno real, como lleva pasando toda la vida.
#25 ¿Donde puedo y qué ordenador comprar más o menos decente con hardware libre totalmente?
#68 No puedes... Y ese es el problema. Hasta el diseño de los procesadores ARM de las Raspberry Pi es secreto.
#88 Gracias, conocía la respuesta, pero siempre es un placer/frustación recordarnoslo.
#63 No. Eso es en spectre y es a) muy raro/dificil y b) solucionable sin mucho trauma; meltdown no afecta a AMD y para solucionarlo en intel tienen que recurrir a dicotomizar el layout de espacio de direcciones, mapeando user ( en ring3 ) vs kernel+user ( en ring0 ). Que es una chapuza.
"La otra parece afectar a casi cualquier procesador de los últimos 20 años."
¿Osea, que al final AMD también caca de la mala o no?
En un día hemos pasado de los procesadores de hace 10 años a los de hace 20. A este ritmo, para el fin de semana vamos a tener que desempolvar los spectrums...
#28 cuanto echo de menos mi Amstrad...
#38 Yo puse en marcha el mio la semana pasada y aún funciona perfectamente incluso el lector de cassette. 30 años como si nada y mira que le di caña en su momento.
Ahora te compras un móvil y al cabo de un año ya está hecho una mierda. A esto le llamamos evolucionar.
#28 Eso a mí me esta mosqueando, lo de sacar los dos bugs juntos como si fuesen lo mismo cuando al parecer lo de AMD y ARM se podría solucionar de una forma más eficiente y no es fruto de una negligencia equivalente...
Me da la impresión de que se están juntando para defender con humo y confusión a Intel de su mala praxis.
Al final nos torean como quieren, encima publicidad a Google por encontrar dos por uno ¿Tanto les costaba poner cada problema en su propio dominio? ¿Económicamente o en alianza estratégica con Intel?
#43 Lo de spectre son pocos casos y paliables, en el caso de AMD, simplemente con no usar cierto software y/o features. Lo gordo es meltdown y AMD no lo tiene.
#50 Meltdown también afecta a AMD, en el paper indican que con el programa de ejemplo, los procesadores de AMD también sacan información que no debería poder leerse. Lo que no han conseguido es un exploit que lo aproveche, pero es cuestión de tiempo.
cc #28 #43
#63 No, goto #96 y #97.
#43 Correcto, eso es lo que están haciendo: Tratar de meter a todos en el mismo saco, premiando a quien lo ha hecho rematadamente mal, para salvar a Intel.
#28 NO.
Los primeros memorables fueron: el con/con del Windows 98 (el propio bug en sí, un bucle infinito con el nombre de un dispositivo restringido de DOS), el dcom en XP (es el nombre del servicio de Windows con un exploit en todas las versiones de Windows que permitió la propagación masiva del virus blaster).
Estos fallos más recientes, como son tan técnicos (buffer overflows o extracción de datos) entiendo que les pongan un nombre específico para ayudar a la mnemotecnia.
Es horrible.
En el caso de Spectre, puedes entrenar a la CPU para que pre-ejecute código que lee memoria (si luego la predicción es incorrecta descarta el resultado). Cuando el código "bueno" se ejecuta, la CPU pre-ejecuta el código atacante y lee bytes que no debería y que el código atacante puede explotar. Esto es mucho más fácil cuando el código atacante se ejecuta en el mismo proceso y núcleo de CPU que la víctima -- por ejemplo, lenguajes interpretados por un proceso residente (JavaScript, PHP en modo fpm, largo etcetera), procesos en máquinas virtuales, etc etc. También ayuda si el procesador tiene hyperthreading, en cuyo caso puedes tener el código malicioso corriendo en paralelo en el mismo procesador sacando información de la cache de memoria.
En principio, "parece" que hay formas de desactivar la ejecución especulativa al compilar, lo que afecta al rendimiento, y no está claro si los procesadores realmente la desactivan o solo descartan el resultado. Esto no serviría de mucho para todo el software que no tiene soporte y no hay forma de recompilar (igual alguien encuentra el modo de injertar instrucciones mfence en el binario).
#27 Si te cargas la ejecución especulativa las prestaciones se van al carajo.
#27 Por lo que he entendido una solucion aceptable podria ser retrasar la actualización de cache (una cache espejo 'especulativa') en las ejecuciones especulativas, en caso de excepción se descarta o de lo contrario se 'consolida' la actualización de la cache....algo parecido y mas refinado no tendria que afectar a rendimientos.
Creo que se refiere a los fabricados por Intel en los últimos 29 años. No se los microprocesadores de AMD están afectados ... pero yo hace tiempo que alrededor del 80% de las cosas estoy usando un ARM Cortex A73 de nombre Kirin.
Espero que esté mejor diseñado y tengo claro que el próximo portátil que compre, tendrá un microprocesador (o dos) ARM.
#29 "Which systems are affected by Spectre?
Almost every system is affected by Spectre: Desktops, Laptops, Cloud Servers, as well as Smartphones. More specifically, all modern processors capable of keeping many instructions in flight are potentially vulnerable. In particular, we have verified Spectre on Intel, AMD, and ARM processors."
#79 #67 #33 Pero los ingenieros de ARM ya han publicado los parches necesarios para solucionar las 4 variantes siempre que el OS sea Linux...
Joder!! ahora no encuentro el enlace. Ayer lo estuve mirando y parece que solo guardé este otro: https://gruss.cc/files/kaiser.pdf en el que no aparecen los enlaces a los kernel Linux parcheados.
Para los ARM que ejecutan Android, se remitían a Google.
Y yo opto por creer más en que se está poniendo en marcha lo de enmierdar a todo el que se pueda, para que Intel no parezca el demonio. Y no estoy solo en esa sospecha...
publicados-detalles-vulnerabilidades-meltdown-spectre-afectan/c028#c-28
Publicados los detalles de las vulnerabilidades Me...
meltdownattack.com#29 El Spectre afecta a los procesadores con ejecución especulativa. Es una técnica que todos los procesadores de altas prestaciones usan desde hará alrededor de 20 años.
#29 Pos ARM es también vulnerable en este caso... y no solo a la variante 1.
#104 #79 #67Encontré el enlace de los desarrolladores de ARM con lla información de los procesadores afectados y los enlaces a los kernel Linux parcheados. Así como otras instrucciones:
https://developer.arm.com/support/security-update
Cagada nivel epico
#relacionada:
#7 no funciona
#10 Lectura de memoria privilegiada con un canal lateral -eng-
Lectura de memoria privilegiada con un canal later...
googleprojectzero.blogspot.ieHace ya tiempo modificaron con acierto el logo de intel
Fiesta el lunes, con lo que cuesta explicarles a los de arriba cada vez que hay un agujero gordo de software... Ya verás tu que risa explicarles que es a nivel de hardware y qué parchearlo va a valer sudor y lágrimas y... Dinero
#53 Están preparando los parches a nivel de software para corregir el problema. Con aplicarlos es suficiente. Lo que hacen es mapear la memoria del proceso de usuario y una copia de las estructuras mínimas del kernel que necesita para poder funcionar. Hasta ahora se mapeaba la memoria completa del sistema, de ahí que se pueda acceder a todo. Con el parche aplicado, aunque el procesador siga siendo vulnerable, únicamente podrá acceder a su memoria.
#62 Si bueno se habla de que el parche puede llegar a reducir hasta un 30% la potencia del procesador lo cual es una autentica burrada, como tengas un entorno justito o no parcheas o parcheas y avisas a toda la empresa de que todo va a ir como el culo hasta que decidan gastarse el dinero en nuevo hardware. Esto es más grave de lo que parece.
#53 Y denuncias, no te olvides de las denuncias que van a empezar a llover a partir de la semana que viene.
Esto es aún más grave de lo que pensaba.
En el nuervo patch del kernel de Linux, en 2 lineas de código deja intel por los suelos.
En ese mensaje Intel mencionaba que según sus análisis el problema puede afectar "a muchos tipos de dispositivos informáticos, con todo tipo de procesadores y sistemas operativos de diferentes proveedores". Aquí Intel probablemente no hablaba de Meltdown, el error del que muchos medios nos hicimos eco ayer, sino de Spectre, el otro problema —aún más grave— que ha salido a la luz en las últimas horas.
Ina Fried, de Axios, mencionaba hace unas horas que efectivamente había dos problemas distintos. El primero, el que afectaba solo a Intel, quedaba ensombrecido por el segundo, que afectaba a todo tipo de procesadores, incluidos los diseños de AMD y ARM.
Jo, jo, jo, jo, jo
AMD y ARM no estan afectados decían.....no hay procesador del q