edición general
348 meneos
5393 clics

Publicados los detalles de las vulnerabilidades Meltdown y Spectre que afectan a la mayoría de procesadores en uso (ING)

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
Comentarios destacados:                        
#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?
«12
  1. ¿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.
  2. #1 Si, está de moda.
  3. #1 Parece que sí, es como los huracanes y tormentas tropicales o las operaciones policiales.

    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.
  4. #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 :-D
  5. Cagada nivel epico
  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?
  7. #relacionada: www.meneame.net/m/Crackeame/lectura-memoria-privilegiada-canal-lateral
  8. #1 Curioso artículo sobre el tema: medium.com/threat-intel/bug-branding-heartbleed-14ef1a64047f y unos cuantos logos: commons.wikimedia.org/wiki/Category:Security_vulnerability_logos a ver si suben todos los más nuevos.
  9. #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.
  10. #7 no funciona
  11. #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?
  12. Que risas cuando vuelva al trabajo y me pregunten si los sistemas estan en peligro...
  13. #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. #12 nada, sólo preguntaba por curiosidad (#4), y bueno, encontré esto → #8
  15. #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... xD

    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. #13 Ya te digo, verás el lunes... :-P
  17. #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 xD
  18. #18 Me acabas de matar, que cabron xD
    No se , igual con una pulserita de esas biomagneticas , que me parece que colara mas.
  19. #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 xD
  20. #20 Yo soy mas de correr en circulos agitando los brazos , para ahorrar en el gimnasio, pero tomo nota xD
  21. #4 Tú lo puedes llamar CVE-2017-5689 si te molesta.
  22. #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 xD
    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)
  23. 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.
  24. Mas que vulnerabilidad esto me suena a diseño, purito diseño
  25. 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).
  26. "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...
  27. 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.
  28. #4 ¿No hemos tenido una conversación muy parecida casi identica a esta en otro hilo muy similar?
  29. #4 Lo siento te pulsé negativo por error, no era mi intención.
  30. #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.
  31. #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."
  32. #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. :tinfoil:
  33. #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.
  34. #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...
  35. #26 is not a bug is a feature.
  36. #28 cuanto echo de menos mi Amstrad...
  37. Esto es aún más grave de lo que pensaba.
  38. #6 ¿Acaso no lo sospechabas?
  39. #3 Pero lo de meterle un logo sinsentido... :roll: :shit: Es como si le pusieran logo al 23-F.
  40. #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.
  41. #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?
  42. #6 - ¿Me equivoco Nota?
    - No te equivocas.
    - ¿Me equivoco?
    - No te equivocas pero eres un gilipollas.
    (Me ha recordado a esta mierda, lo siento xD )
    Por cierto, no te equivocas.
  43. #1 Empezo con HeartBleed, creo, aunque quiza me equivoque:

    heartbleed.com/

    Ami estos logos que babean me recuerdan a:

    dailyturd.files.wordpress.com/2011/10/swallow-or-its-going-in-your-eye

    :troll:  media
  44. #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.
  45. #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 :-D
  46. #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.
  47. #23 Y vaya solución para cualquier empresa con un mínimo de infraestructura informática. Nos esperan meses "interesantes" por delante.
  48. #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.
  49. #16 Eso se llama path travelsal, y en caso que citas se aprovechaba la codificion unicode para saltarse las protecciones que lo impedían.
  50. #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)
  51. 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
  52. #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... </ironic>
  53. #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
  54. #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
  55. 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.
  56. #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 :troll:
  57. #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.
  58. #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
  59. #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.
  60. #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
  61. #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.
  62. #53 Y denuncias, no te olvides de las denuncias que van a empezar a llover a partir de la semana que viene.
  63. #27 Si te cargas la ejecución especulativa las prestaciones se van al carajo.
  64. #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.
  65. #25 ¿Donde puedo y qué ordenador comprar más o menos decente con hardware libre totalmente?
  66. #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 ).
  67. #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.
  68. #72 Tronco:

    <<#SEXYPETCAT: Speculative EXecution Yields Privilege Escalation Through Cache ATtacks

    Just saying.>>

    ¿ Me tomas el pelo ? ¿ Que aporta eso ?
  69. #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í.
  70. #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.
  71. #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.
  72. #29 Pos ARM es también vulnerable en este caso... y no solo a la variante 1.
  73. #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.
  74. #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.
  75. #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.
  76. #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.
  77. #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] googleprojectzero.blogspot.com.es/2018/01/reading-privileged-memory-wi
  78. #86 Muchas gracias! Voy a corregir un par de cosas que he estado diciendo.
  79. #68 No puedes... Y ese es el problema. Hasta el diseño de los procesadores ARM de las Raspberry Pi es secreto.
  80. #85 pues eso, difícil, que no imposible en un entorno real, como lleva pasando toda la vida.
  81. #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. :-)
  82. #45 eso parece #8
  83. Hace ya tiempo modificaron con acierto el logo de intel  media
  84. #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.
  85. En el nuervo patch del kernel de Linux, en 2 lineas de código deja intel por los suelos.

    twitter.com/nospotfer/status/948888462404571136
  86. #63 No, goto #96 y #97.
  87. #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"
«12
comentarios cerrados

menéame