Se han publicado ya los de los detalles de las vulnerabilidades Meltdown y Spectre que afectan a la mayoría de procesadores en uso. Una de ellas es posible que sólo afecte a Intel. La otra parece afectar a casi cualquier procesador de los últimos 20 años.
|
etiquetas: procesador , cpu , vulnerabilidad , meltdown , spectre
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?
La vulnerabilidad krack tambien.
www.krackattacks.com/
Entre
Meltdown
Spectre
Krack
"CVE-2017-5689 Intel Management Engine Vulnerability" igual no se recuerda tan bien ni tiene tanto gancho.
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?
Un bug que nadie detecta, es como si no hubiera existido.
El problema es que ahora es un marrón de tamaño universal.
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"
No se , igual con una pulserita de esas biomagneticas , que me parece que colara mas.
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)
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).
¿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...
Espero que esté mejor diseñado y tengo claro que el próximo portátil que compre, tendrá un microprocesador (o dos) ARM.
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."
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.
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?
- 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.
heartbleed.com/
Ami estos logos que babean me recuerdan a:
dailyturd.files.wordpress.com/2011/10/swallow-or-its-going-in-your-eye
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.
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)
Microsoft siempre ha sido un chiste en cuanto a seguridad
Pero claro no estamos acostumbrados a este tipo de buen trabajo
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.
cc #34
cc #28 #43
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 ).
<<#SEXYPETCAT: Speculative EXecution Yields Privilege Escalation Through Cache ATtacks
Just saying.>>
¿ Me tomas el pelo ? ¿ Que aporta eso ?
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.
Vamos, de donde vienes, manzanas traigo.
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.
Ahora te compras un móvil y al cabo de un año ya está hecho una mierda. A esto le llamamos evolucionar.
"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] googleprojectzero.blogspot.com.es/2018/01/reading-privileged-memory-wi
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.
twitter.com/nospotfer/status/948888462404571136