EDICIóN GENERAL
348 meneos
5388 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?
¿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.
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 :-D
#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.
#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 Eso se llama path travelsal, y en caso que citas se aprovechaba la codificion unicode para saltarse las protecciones que lo impedían.
#3 Pero lo de meterle un logo sinsentido... :roll: :shit: Es como si le pusieran logo al 23-F.
#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.
#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:
#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:

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
#72 Tronco:

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

Just saying.>>

¿ 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
Cagada nivel epico
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…   » ver todo el comentario
#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…   » ver todo el comentario
#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. :tinfoil:
#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 xD )
Por cierto, no te equivocas.
#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] googleprojectzero.blogspot.com.es/2018/01/reading-privileged-memory-wi
#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
#relacionada: www.meneame.net/m/Crackeame/lectura-memoria-privilegiada-canal-lateral
Que risas cuando vuelva al trabajo y me pregunten si los sistemas estan en peligro...
#13 Ya te digo, verás el lunes... :-P
#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 Me acabas de matar, que cabron xD
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 :-D
#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 Yo soy mas de correr en circulos agitando los brazos , para ahorrar en el gimnasio, pero tomo nota xD
#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 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)
#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... </ironic>
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.
Mas que vulnerabilidad esto me suena a diseño, purito diseño
#26 is not a bug is a feature.
#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.
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…   » ver todo el comentario
#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.
"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. 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.
#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.
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: 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...

www.meneame.net/story/publicados-detalles-vulnerabilidades-meltdown-sp
#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:

developer.arm.com/support/security-update
Esto es aún más grave de lo que pensaba.
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.
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.
Hace ya tiempo modificaron con acierto el logo de intel  media
En el nuervo patch del kernel de Linux, en 2 lineas de código deja intel por los suelos.

twitter.com/nospotfer/status/948888462404571136
«12
comentarios cerrados

menéame