Portada
mis comunidades
otras secciones
#13:
No es por joder, pero pongámonos en el supuesto de "hace un año y poco me compré un i7...", no es mi caso aunque seguro que habrá un montón de gente que está en ese caso. Ahora nos metemos en el tema de las garantías (terreno pantanoso): como tiene menos de dos años y, al parecer, el FALLO es de HARDWARE, o sea, del diseño del mismo, ¿el fabricante está obligado por las leyes de consumo a reemplazar mi procesador por uno similar que no tenga dicho fallo?. Y por favor, no me vengáis con parches de software, estamos ante UN FALLO de diseño.
Esta es la pregunta que me hago yo ahora mismo: ¿qué pasa con la inmensa cantidad de procesadores que hay en circulación y que se suponen que aun están cubiertos por la garantía de 2 años?. Y por no hablar del inmenso stockage de procesadores por vender y que tienen el fallo. Algunos podéis decir que, oye, el procesador funciona, no te lo van a cambiar, pero yo no lo veo de esa manera. Es como si compras un VW diesel de bajas emisiones y gran potencia y al tiempo descubres que todos esos coches por un mal diseño del motor están emitiendo partículas por encima de lo legal, pero que con un "parche en la centralita" se pone en niveles casi legales pero perdiendo un huevo de potencia ... ¿os suena esto? (preguntadle a los de VW como les ha salido de barata la gracia, incluso creo que hay algún directivo engrilletado por ello)
Señores, no me extraña nada que el CEO de Intel vendiera hace un mes todas las acciones que pudo de su propia compañía, ahora veo el terrible motivo que le ha llevado a esto.
PD.- Sería interesante aclarar el tema de las garantías y como afectaría a los usuarios. Es un error en el diseño, eso está claro.
Esta es la pregunta que me hago yo ahora mismo: ¿qué pasa con la inmensa cantidad de procesadores que hay en circulación y que se suponen que aun están cubiertos por la garantía de 2 años?. Y por no hablar del inmenso stockage de procesadores por vender y que tienen el fallo. Algunos podéis decir que, oye, el procesador funciona, no te lo van a cambiar, pero yo no lo veo de esa manera. Es como si compras un VW diesel de bajas emisiones y gran potencia y al tiempo descubres que todos esos coches por un mal diseño del motor están emitiendo partículas por encima de lo legal, pero que con un "parche en la centralita" se pone en niveles casi legales pero perdiendo un huevo de potencia ... ¿os suena esto? (preguntadle a los de VW como les ha salido de barata la gracia, incluso creo que hay algún directivo engrilletado por ello)
Señores, no me extraña nada que el CEO de Intel vendiera hace un mes todas las acciones que pudo de su propia compañía, ahora veo el terrible motivo que le ha llevado a esto.
PD.- Sería interesante aclarar el tema de las garantías y como afectaría a los usuarios. Es un error en el diseño, eso está claro.
#49:
#42 Resumen: No sería solución y a tí también te afecta.
Es importante entender que esta es la primera demostración de la idea de que se pueden atacar sistemas "trasteando" con la ejecución predictiva que hacen prácticamente todos los procesadores "potentes" del mercado (desde hace años!). Los que tuvieron esa idea pensaron en formas concretas de ponerla en práctica. El resultado son, actualmente, dos ataques concretos: "Meltdown" y "Spectre".
MELTDOWN, que solo afecta a procesadores Intel, es el que más ha preocupado a corto plazo: resulta que, usando este tipo de ataque, es posible saltarse las protecciones de memoria que debería asegurar el procesador. Eso significa que un atacante puede leer CUALQUIER parte de la memoria que le de la gana, incluida la memória de otras máquinas virtuales alojadas en el mismo hardware, desde dentro de una máquina virtual mismo!
Esto dejaba "en bolas" a todos los tinglados cloud porque cualquiera podría robarle info a "sus vecinos" (que son otros clientes). Este bug es el que se han apresurado a mitigar por todos lados (ya hay patches para Linux, Windows y MacOS). Estos parches lo que hacen es putear al procesador a drede para que la ejecución predictiva no funcione, evitando así que se pueda "disparar" el bug (a costa de disminuir el rendimiento de la CPU claro!).
De aquí viene la idea de "si no virtualizo no hay problema", pero es una idea falsa. Si no virtualizas pero tienes CPU intel, lo que pasa con este ataque es que un programa cualquiera, ejecutado por un usuario cualquiera, puede leer la memoria del sistema operativo, y por tanto obtener privilegios de root/administrador/sistema y controlar tu pc por completo (el sueño de todo worm/virus/cosa maliciosa). Por eso el parche también te lo aplican a ti que no virtualizas.
SPECTRE es otro ataque, más sutil y difícil de explotar. Con este ataque (en realidad son dos) lo que se consigue es leer cualquier parte de la memoria *de tu mismo proceso* (no puedes leer lo de otros procesos). Esto puede sonar poco peligroso, pero no lo es por un sencillo motivo: ahora mismo estás usando un programa (tu navegador web) que ejecuta programas de otra gente sin preguntarte (scripts javascript). Usando este ataque, es teóricamente posible que una web cualquiera lea los datos de las otras webs que tienes abiertas, incluyendo contraseñas, cookies de sesión, etc. Vamos, que visitando una web cualquiera te podrían robar la tarjeta de crédito que estás metiendo en amazon para comprar una chorrada, por ejemplo. De momento no han conseguido llevarlo a la practica en javascript (es complicado porque hay un JIT que interpreta y compila el código javascript, así que no es fácil terminar generando instrucciones específicas para disparar el bug), pero es solo cuestión de tiempo.
Durante este tiempo, tanto los desarrolladores de navegadores, como todos aquellos programas que permitan ejecutar scripts o plugins de terceros tratarán de buscar formas para evitar que esos scripts/plugins puedan disparar el bug.
DESGRACIADAMENTE, esto será una guerra que durará mucho tiempo. Estos dos ataques concretos son solo la primera oleada de ataques basados en "trastear con la ejecución predictiva", porque en el fondo el problema es del diseño del hardware. Este diseño se viene usando desde hace más de una década, y hoy en día lo usan prácticamente todas las CPUs "potentes" (incluídas tablets y moviles). El CERN dice que lo mejor es cambiar de CPU (a una que no haga ejecución predictiva), pero... eso no existe hoy en día (con potencia como para hacer el trabajo que hacen las CPUs afectadas). Por tanto, vamos a estar haciendo "chapuzas" para evitar los ataques que vayan apareciendo, mientras otra gente se dedica a buscar nuevos ataques que exploten este problema.
Y ya para terminar de hacerme pesado, voy a explicar un poco cuál es ese problema. La idea de la ejecución predictiva es que, cuando el procesador debería quedarse esperando alguna información de la memoria, en vez de quedarse parado "asume" qué datos vendrán y va ejecutando como si los tuviera. Si cuando llega la información esta coincide con lo esperado, se sigue ejecutando con ese trabajo ya adelantado (yuhu!). Si no, el procesador "deshecha" ese trabajo que ha "adelantado", vuelve al punto donde se habría parado, y ejecuta a partir de ahí pero con la información de verdad. Esta idea está muy bien (y funciona muy bien!), pero tiene un problema: el seguir ejecutando en vez de esperar tiene efectos secundarios, aunque luego deseches el trabajo. De hecho, no está claro que sea posible deshacer TODO lo que hayas cambiando mientras "se adelantaba trabajo". Lo que si está claro es que los procesadores actuales no consiguen deshacerlo, y de eso es de lo que se aprovechan Meltdown y Spectre: consiguen que el procesador vaya "adelantando trabajo" y luego observan los efectos secundarios producidos para descubrir información que en teoría no les toca conocer!
Es importante entender que esta es la primera demostración de la idea de que se pueden atacar sistemas "trasteando" con la ejecución predictiva que hacen prácticamente todos los procesadores "potentes" del mercado (desde hace años!). Los que tuvieron esa idea pensaron en formas concretas de ponerla en práctica. El resultado son, actualmente, dos ataques concretos: "Meltdown" y "Spectre".
MELTDOWN, que solo afecta a procesadores Intel, es el que más ha preocupado a corto plazo: resulta que, usando este tipo de ataque, es posible saltarse las protecciones de memoria que debería asegurar el procesador. Eso significa que un atacante puede leer CUALQUIER parte de la memoria que le de la gana, incluida la memória de otras máquinas virtuales alojadas en el mismo hardware, desde dentro de una máquina virtual mismo!
Esto dejaba "en bolas" a todos los tinglados cloud porque cualquiera podría robarle info a "sus vecinos" (que son otros clientes). Este bug es el que se han apresurado a mitigar por todos lados (ya hay patches para Linux, Windows y MacOS). Estos parches lo que hacen es putear al procesador a drede para que la ejecución predictiva no funcione, evitando así que se pueda "disparar" el bug (a costa de disminuir el rendimiento de la CPU claro!).
De aquí viene la idea de "si no virtualizo no hay problema", pero es una idea falsa. Si no virtualizas pero tienes CPU intel, lo que pasa con este ataque es que un programa cualquiera, ejecutado por un usuario cualquiera, puede leer la memoria del sistema operativo, y por tanto obtener privilegios de root/administrador/sistema y controlar tu pc por completo (el sueño de todo worm/virus/cosa maliciosa). Por eso el parche también te lo aplican a ti que no virtualizas.
SPECTRE es otro ataque, más sutil y difícil de explotar. Con este ataque (en realidad son dos) lo que se consigue es leer cualquier parte de la memoria *de tu mismo proceso* (no puedes leer lo de otros procesos). Esto puede sonar poco peligroso, pero no lo es por un sencillo motivo: ahora mismo estás usando un programa (tu navegador web) que ejecuta programas de otra gente sin preguntarte (scripts javascript). Usando este ataque, es teóricamente posible que una web cualquiera lea los datos de las otras webs que tienes abiertas, incluyendo contraseñas, cookies de sesión, etc. Vamos, que visitando una web cualquiera te podrían robar la tarjeta de crédito que estás metiendo en amazon para comprar una chorrada, por ejemplo. De momento no han conseguido llevarlo a la practica en javascript (es complicado porque hay un JIT que interpreta y compila el código javascript, así que no es fácil terminar generando instrucciones específicas para disparar el bug), pero es solo cuestión de tiempo.
Durante este tiempo, tanto los desarrolladores de navegadores, como todos aquellos programas que permitan ejecutar scripts o plugins de terceros tratarán de buscar formas para evitar que esos scripts/plugins puedan disparar el bug.
DESGRACIADAMENTE, esto será una guerra que durará mucho tiempo. Estos dos ataques concretos son solo la primera oleada de ataques basados en "trastear con la ejecución predictiva", porque en el fondo el problema es del diseño del hardware. Este diseño se viene usando desde hace más de una década, y hoy en día lo usan prácticamente todas las CPUs "potentes" (incluídas tablets y moviles). El CERN dice que lo mejor es cambiar de CPU (a una que no haga ejecución predictiva), pero... eso no existe hoy en día (con potencia como para hacer el trabajo que hacen las CPUs afectadas). Por tanto, vamos a estar haciendo "chapuzas" para evitar los ataques que vayan apareciendo, mientras otra gente se dedica a buscar nuevos ataques que exploten este problema.
Y ya para terminar de hacerme pesado, voy a explicar un poco cuál es ese problema. La idea de la ejecución predictiva es que, cuando el procesador debería quedarse esperando alguna información de la memoria, en vez de quedarse parado "asume" qué datos vendrán y va ejecutando como si los tuviera. Si cuando llega la información esta coincide con lo esperado, se sigue ejecutando con ese trabajo ya adelantado (yuhu!). Si no, el procesador "deshecha" ese trabajo que ha "adelantado", vuelve al punto donde se habría parado, y ejecuta a partir de ahí pero con la información de verdad. Esta idea está muy bien (y funciona muy bien!), pero tiene un problema: el seguir ejecutando en vez de esperar tiene efectos secundarios, aunque luego deseches el trabajo. De hecho, no está claro que sea posible deshacer TODO lo que hayas cambiando mientras "se adelantaba trabajo". Lo que si está claro es que los procesadores actuales no consiguen deshacerlo, y de eso es de lo que se aprovechan Meltdown y Spectre: consiguen que el procesador vaya "adelantando trabajo" y luego observan los efectos secundarios producidos para descubrir información que en teoría no les toca conocer!
#79:
#66
http://mundowdg.com/blog/2013/05/06/la-chica-de-practicas/
Daisy pasa otra vez de vuelta a su PC a medio montar con uno alicates de corte en la mano. Hija de puta. Esta criatura no atasca.
-Daisy, bonita, ¿qué vas a hacer con los alicates?
-No entra la RAM.
-Déjame ver… – me acerco a ver el interior de la carcasa. Ha elegido una placa AMD AM3 y dos módulos de memoria DDR. Si hay algún lego en la materia en la sala, por favor, sírvase de visualizar la siguiente imagen para comprender por qué Daisy, en ese momento perdió mi respeto.
Adaptador de memoria DDR a DDR3 por cojones edition:
http://mundowdg.com/blog/2013/05/06/la-chica-de-practicas/
Daisy pasa otra vez de vuelta a su PC a medio montar con uno alicates de corte en la mano. Hija de puta. Esta criatura no atasca.
-Daisy, bonita, ¿qué vas a hacer con los alicates?
-No entra la RAM.
-Déjame ver… – me acerco a ver el interior de la carcasa. Ha elegido una placa AMD AM3 y dos módulos de memoria DDR. Si hay algún lego en la materia en la sala, por favor, sírvase de visualizar la siguiente imagen para comprender por qué Daisy, en ese momento perdió mi respeto.
Adaptador de memoria DDR a DDR3 por cojones edition:
#11:
Yo lo que no entiendo como la gente asume los fallos de esta compañía y no les reclaman la CPU nueva, no se han estado forrando estos años vendiendo a precio de oro sus CPU's? Pues venga.
#34:
#24 No se puede eso, cada fabricante de CPUs tiene sus propios chipsets y zócalos y no son compatibles con las de otros fabricantes ni con otras familias de CPUs del mismo fabricante, aunque dependiendo de la familia y modelo de CPU, puedes llegar a usar una placa base con chipset nuevo en una CPU anterior, por ejemplo usar un i5 6600K en una placa base con chipset Z270, o en el caso de modelos antiguos de AMD, mezclar placas base modernas con socket AM3 con CPUs antiguas del socket AM2+, pero a día de hoy AMD ha hecho como Intel y a cada nueva familia de CPUs van a cambiar de socket y chipset.
Resumen: si cambias de CPU cambias de placa base y puede que hasta de RAM.
Resumen: si cambias de CPU cambias de placa base y puede que hasta de RAM.
#1:
Eso mismo decía yo, por el bien de todos será mejor que Intel decida cambiar las CPUs, cueste lo que cueste, ya que ha sido su error, como le ha tocado hacer a todas las demás empresas, INTELGATE cociéndose en la olla.
CERT asegura que la mejor solución es cambiar la CPU afectada.
y los problemas afectan a CPUs fabricadas desde hace !!!!!20 años!!!!!! casi ná.
CERT asegura que la mejor solución es cambiar la CPU afectada.
y los problemas afectan a CPUs fabricadas desde hace !!!!!20 años!!!!!! casi ná.
#18:
En un MacBook Pro está chupado. Sacas la radial y después a cincel despacito va saliendo.
Con los PowerPC estábamos mejor, esto de cambiar a Intel fue una conspiración desde el principio para obligarnos a renovar el ordenador
Con los PowerPC estábamos mejor, esto de cambiar a Intel fue una conspiración desde el principio para obligarnos a renovar el ordenador
#3:
Mi pregunta es ¿Como se les ha pasado el BUG? Si es un bug. O en realidad es otra cosa.
Comentarios
No es por joder, pero pongámonos en el supuesto de "hace un año y poco me compré un i7...", no es mi caso aunque seguro que habrá un montón de gente que está en ese caso. Ahora nos metemos en el tema de las garantías (terreno pantanoso): como tiene menos de dos años y, al parecer, el FALLO es de HARDWARE, o sea, del diseño del mismo, ¿el fabricante está obligado por las leyes de consumo a reemplazar mi procesador por uno similar que no tenga dicho fallo?. Y por favor, no me vengáis con parches de software, estamos ante UN FALLO de diseño.
Esta es la pregunta que me hago yo ahora mismo: ¿qué pasa con la inmensa cantidad de procesadores que hay en circulación y que se suponen que aun están cubiertos por la garantía de 2 años?. Y por no hablar del inmenso stockage de procesadores por vender y que tienen el fallo. Algunos podéis decir que, oye, el procesador funciona, no te lo van a cambiar, pero yo no lo veo de esa manera. Es como si compras un VW diesel de bajas emisiones y gran potencia y al tiempo descubres que todos esos coches por un mal diseño del motor están emitiendo partículas por encima de lo legal, pero que con un "parche en la centralita" se pone en niveles casi legales pero perdiendo un huevo de potencia ... ¿os suena esto? (preguntadle a los de VW como les ha salido de barata la gracia, incluso creo que hay algún directivo engrilletado por ello)
Señores, no me extraña nada que el CEO de Intel vendiera hace un mes todas las acciones que pudo de su propia compañía, ahora veo el terrible motivo que le ha llevado a esto.
PD.- Sería interesante aclarar el tema de las garantías y como afectaría a los usuarios. Es un error en el diseño, eso está claro.
#13 El problema de eso es que te vas a meter en un berenjenal del que probablemente te cueste salir mucho mas de lo que vale un microprocesador fe maxima gama.
Si fuese de la compania te puedo argumentar facilmente que te devolvemos tu procesador ya que al testearlo en el SAT esta en buen estado y funciona con su potencia comercial.
Tal y como esta diseñado el procesador, este prioriza ciertas partes del mismo para diferentes tareas, entre ellas la de gestionar permisos de acceso a informacion entre las partes del mismo por cuestiones de seguridad.
#16: Denuncia conjunta y listo.
#16 Para un particular, sí que es un berenjenal, pero para empresas como las de la lista siguiente, que tienen un volumen muy grande, sí que es tema serio
- Grandes vendedores de ordenadores: Apple y todos sus Mac,
- Cloud: Amazon AWS+ Microsoft Azure, Digital Ocean y todos los demás proveedores de cloud, que podrían reclamar que les paguen el coste de cambiar todas las CPUs de todos los servidores que tienen,
- proveedores de HW específico para seguridad (como Firewalls, etc.)
#75 y para que van a joder a su principal proveedor de chips?, si hicieran eso, al siguiente les cobras el doble y ale. Y a ver que otro proveedor te da rendimientos de intel o amd. Los fabricantes de chips necesitan de esas empresas, y esas empresas necesitan de esos fabricantes.
#84 Ya se están empezando a comprar procesadores ARMv8 para los servidores. Esto puede ser el empujón que necesitan.
#75 el estado. Cualquier estado.
#16 Puedes argumentar que funciona muy bien y que su potencia es la correcta, pero el cliente puede argumentar un fallo de seguridad del que tendrías que hacerte responsable en el caso de sufrir pérdidas de dinero por la vulnerabilidad del procesador...no sé qué será peor....
#13 Pues tienes toda la razón en el planteamiento que haces. Vamos a tener que empezar a reclamar...
#13 Aquí los que tienen la sartén por el mango y que seguramente reclamaran, son las grandes compañías de datos, bolsa e internet, que estas si tienen fuerza para forzar una indemnización a intel. Es un bug que puede poner en riesgo a muchas empresas y gobiernos, no se como no hay mas de uno pidiendo la cabeza de los directivos de intel, pensemos en s.o. de barcos, defensa en fin que pueden explotar un bug.
En estos momentos hay carreras para encontrar una aplicación efectiva para explotar el bug.
#13 En tu ejemplo tienes la respuesta.
En el resto del mundo Intel tendrá que indemnizar, aquí incluso les saldrá rentable.
#13 El fallo afecta casi exclusivamente a servidores y mainframes, a nivel de usuario la actualización no afecta prácticamente nada a nviel ni de juegos ni ofimática ni siquiera photoshop
#29, ¿de dónde sacas eso? No lo pongo en duda, de hecho he visto a alguien decir algo parecido, pero tú más concreto aún. Agradecería algún link o similar.
Por otro lado es que si afectara al usuario y se obrara el milagro de que reemplazaran los microprocesadores defectuosos sería un tema complicado, primero porque los procesadores que tendrían que darnos no existen y tendrían que desarrollarlos y fabricarlos, lo que llevaría un tiempo considerable. Además tendrían que hacerlos compatibles con las placas de los procesadores a reemplazar.
#44 Por ejemplo: https://www.techspot.com/article/1554-meltdown-flaw-cpu-performance-windows/
Hay varias comparaciones por ahí ya publicadas. El cambio que te puedes esperar es por debajo del 1%.
#65 y otro más.
http://www.guru3d.com/articles_pages/windows_vulnerability_cpu_meltdown_patch_benchmarked,3.html
#29 Llevo un trato buscando por google si alguien ha testeado el paquete adobe (me interesa por trabajo) pero no encuentro ninguna referencia en ingles por ahora
#13 Y por no hablar del inmenso stockage de procesadores por vender y que tienen el fallo.
https://www.amazon.es/Intel-Core-i7-7700K-Procesador-Subprocesos/dp/B01LTI1JEM/ref=sr_1_13?s=computers&ie=UTF8&qid=1515116570&sr=1-13&keywords=procesadores+intel
https://www.amazon.es/Intel-Core-i5-7500-Procesador-Subprocesos/dp/B01MZZJ1P0/ref=sr_1_14?s=computers&ie=UTF8&qid=1515116570&sr=1-14&keywords=procesadores+intel
Parece que algunas tiendas ya han empezado a deshacerse del stock
Aunque yo preferiría este, si no está afectado por meltdown y spectre
https://www.amazon.es/HP-Intel-Xeon-E5520-Procesador/dp/B00A1ZVLNO/ref=sr_1_fkmr2_2?ie=UTF8&qid=1515116065&sr=8-2-fkmr2&keywords=procesadores+Xeon+baratos
#39 https://i.imgur.com/lADQHTc.png el primero sigue al mismo precio que hace meses.
#62 Solo miré en Amazon...
#13 estuve siguiendo esta misma conversación ayer en Slashdot, se mencionó esto mismo que planteas pero parece que los listos de Intel tienen una cláusula en la compra/garantía de los peocesadores que los exime de daños por defectos en el diseño. Imagino que la incluirían en los primeros tiempos del pentium tras el fiasco del 1/2*2.
Aparte fíjate en el lenguaje que utilizaron en la declaración de ayer "nuestros procesadores funcionan tal como fueron diseñados", es decir no aceptan que sea un problema de ellos.
#69 ahora veremos qué dicen los jueces... Quizá que hay que sacrificar Intel para paliar el daño.
#69 ¿Y hasta que punto esa cláusula es abusiva? Por muchas cláusulas que pongan en sus contratos si contradicen a lo que la ley del país en el que vendan sus procesadores, la ley prevalece sobre las condiciones de Intel. Igual que en muchos países solo ofrecen 1 año de garantía, y aquí en España son 2 años quieran o no (aunque en el 2º año te pueden pedir que demuestres el fallo mediante un tercero).
Un fallo de diseño probablemente en España lo tenga que cubrir la garantía.
#13 Que les costará caro a los de Intel ni lo dudes. Lo de cambiarte el procesador por uno sin el fallo de diseño igual que les cambiaron el coche a los poseedores de un VW con la centralita trucada. No lo verán tus ojos.
#73 ¿Y por que no? es no estamos hablando solo de los coches, ya paso algo parecido con las tres luces rojas de la xbox 360.
#13 La garantía cubre cualquier fallo de fabricación. Legalmente, en España son dos años como mínimo. Aunue en los 6 primeros meses se presupone que el fallo es de origen en fábrica y los 18 meses siguientes, lo ha de acreditar el comprador.
Además, en las versiones en caja Intel ofrece 3 años de garantía: https://www.intel.es/content/www/es/es/support/articles/000005862/processors.html
De todas formas, en un caso como éste, en que está claro y reconocido que es un fallo de fábrica, se podría con la ley en la mano obligar a Intel a cambiar todos los procesadores vendidos en los últimos 2 años y todos los vendidos en caja los últimos 3 años por uno nuevo sin el fallo.
El problema es que no hay procesadores sin el fallo, han de re-diseñarlos y ponerse a fabricar ya mismo.
#13 ¿el fabricante está obligado por las leyes de consumo a reemplazar mi procesador por uno similar que no tenga dicho fallo?
En el caso de Intel, eso simplemente no existe.
#13 Todos sus procesadores tienen ese problema, así que en el mejor de los casos te pueden dar el dinero de vuelta, pero te quedas sin CPU.
#13 ¿Stockage? ¿De dónde te has sacado esa palabra? Será "stock" en todo caso.
#13 Otro problema es, si todos tienen fallo, ¿por cual te lo cambian?
#13. Goto #139.
#13 Yo pagaría por un nuevo i5 de tercera generación para mi ordenador, si los de Intel aprovecharan y fabricaran uno con el doble de potencia que el que tengo.
Yo lo que no entiendo como la gente asume los fallos de esta compañía y no les reclaman la CPU nueva, no se han estado forrando estos años vendiendo a precio de oro sus CPU's? Pues venga.
#11 Hacemos una conjunta? Una denuncia digo
#11. No es solo un error de INTEL, AMD o ARM, es una constante en toda la cadena tecnológica digital desde el primer microprocesador que salió al mercado. Siempre ha habido problemas de seguridad en los sistemas digitales, siempre los ha habido y nada indica que vaya a dejar de haberlos. Comprar nuevas CPUs solo sería un parche temporal más al problema.
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)
#31 No hombre, siempre puedes usar la técnica de la becaria del BOFH:
Mi pregunta es ¿Como se les ha pasado el BUG? Si es un bug. O en realidad es otra cosa.
#3 Suena a quiero poder acceder a toda la información que me dé la gana sin que nadie se de cuenta.
#4 le han jodido a la NSA americana, china y rusa, se les ha descubierto el chollo
#4 Suena a backdoor reptiliano.
#3 Meltdown si que es un poco más bug, pero Spectre es más bien una consecuencia de la arquitectura utilizada.
#19, su es una ciudad secuencia no prevista entonces se le llama bug.
#43 Bueno, no todas las ciudades secuencia se llaman Bug.
#57, puto móvil
#19 Que yo recuerde, los hardware prefetchers no deberían poder cruzar a una pagina de memoria distinta de la que se ha accedido en las ultimas peticiones de memoria, justamente para evitar este tipo de problemas. Entonces, Spectre sí que es un bug (corregidme si me equivoco, que hablo de memória).
#3 es un problema de diseño que aún se ha revelado ahora, y no creo que nadie hubiese pensado en su momento que se podrían hacer esta clase de ataques de tiempo a la caché.
#3 es un FEATURE
#3 Porque no es un bug como tal, es un ataque de canal lateral para el que tienen que darse unas condiciones muy concretas.
Eso mismo decía yo, por el bien de todos será mejor que Intel decida cambiar las CPUs, cueste lo que cueste, ya que ha sido su error, como le ha tocado hacer a todas las demás empresas, INTELGATE cociéndose en la olla.
CERT asegura que la mejor solución es cambiar la CPU afectada.
y los problemas afectan a CPUs fabricadas desde hace !!!!!20 años!!!!!! casi ná.
#1 Ni hartos de vino van a cambiar las cpus. Antes cierran el chiringuito. Primero porque aparentemente todos sus cpus están afectadas. Segundo porque seguramente tendrán que rediseñar su microarquitectura actual, testear y mandarlo a fábrica : ponle un año mínimo y 5 máximo.
#38 Los procesadores más avanzados son una minoría, la mayoría son procesadores de hace años, y esos deberían poder diseñarlos y fabricarlos en un par de meses.
La cuestión es la siguiente; si tú tienes un ordenador con un procesador i7 de segunda generación, e Intel saca una nueva versión sin el fallo, pero que además mejore el rendimiento en un 50% o un 100% ¿comprarías el procesador nuevo y lo cambiarías?
#48 para fabricar un modelo descatalogado hay que gastar millonadas en volver a tener la cadena de montaje.
Es imposible.
No van a hacer nada, como mucho el próximo modelo con el bug arreglado se podrá usar como reemplazo directo del último actual y ya está .
#48 Ni de coña un nuevo i7 mejoraría el rendimiento en un 50 o 100%. La diferencia principal son los cores, y ademas para sacarles provecho las aplicaciones deben estar diseñadas para usarlos. Si además como es habitual entre generaciones mantienen el mismo numero de cores, la diferencia de rendimiento es bastante ridicula.
#86 Ahora tienen fácil mejorar un 30%
#96 El famoso boton turbo!
#48 Los procesadores más avanzados son una minoría, la mayoría son procesadores de hace años, y esos deberían poder diseñarlos y fabricarlos en un par de meses.
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.
#131 Pero no es sólo saber cómo hacer el procesador (que supongo que saben, dado que no habran tirado las mascaras de producción por el retrete), sinó que es "hacerlo": es poner marcha un proceso que afecta a miles de personas, a maquinas que se tendran que recalibrar, proveedores, etc., Claro que se puede hacer si es necesario, pero no es "un par de meses"... es mucho mas.
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.
#1. No tiene sentido lo que propones para empezar porque no es viable economicamente para Intel aunque quisieran y para continuar porque ni siquiera tienen esos nuevos diseños en producción. #38 lleva razón.
#63 Yo no he dicho en ningún momento que vayan a cambiar las cpus. Lo que he dicho es que tardarán un tiempo en tener CPUs nuevas sin el bug este.
#38 Cuando el primer Pentium tenía un fallo en ciertas operaciones de coma flotante lo arreglaron y enviaron la versión arreglada a todos los propietarios de la fallida.
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.
#1 hasta el momento, sólo hay una rama de procesadores de AMD afectada, la FX y a un par de chips de ARM.
Lo que están diciendo "sutilmente" es que mandemos a la mierda a Intel
#1 si van a cambiar si... Como cambiaron los VW con el dieselgate.
Quien puede asegurar que esta cagada no está hecha a propósito para ahora vender más??
Las empresas solo miran por un interes: el dinero. Y los que sufren las consecuencias de ese interes somos siempre los mismos: los consumidores
#99 De momento los mismos que sacaron 15000 millones de dolares a VW en USA ya han demandado a Intel, veremos las iniciativas en el resto del mundo.
Aquí muestro 3 demandas que ya se han presentado contra Intel:
https://es.scribd.com/document/368434221/District-of-Oregon
https://es.scribd.com/document/368434313/northern-district-of-californian
https://es.scribd.com/document/368434285/southern-district-of-indiana
Pues Ryzen y a tirar.
#2 El problema que la ddr4 esta por las jodidas nueves.
#5 Pues entonces algún AMD de los de socket AM3+ o similares.
#6 Es la misma mierda ayer mire una factura del 2012 y la ddr3 esta igual de inflada el doble de precio que hace un año.
#7 Pues puede que le saque rendimiento a mis dos módulos de DDR3 que desinstalé hace unos meses...
#2: Claro me compro un Ryzen, y los pines que no encajan en la placa madre los corto con unos alicates...
Pero ya puestos: ¿Existe una tabla de equivalencias
PwnedIntel VS AMD si por casualidad me pusiera a cambiar el procesador manteniendo todo lo demás? ¿Es posible eso, o las placas madre son específicas para Intel o AMD?#24 son específicas
#24 Sí, la placa base es especifica tendrías que cambiarla, aparte de procesador (con su disipador) y placa lo único que tendrías que mirar es la RAM puede que te valga o puede que no dependiendo de si es DDR4 o DDR3, todo lo demás, caja, fuente, tarjeta grafica, discos duros, unidades ópticas, periféricos debería ser compatible (a no ser que me estés hablando de cambiar un Pentium II por un Ryzen).
#24 Me temo que los maravillosos tiempos del Socket 7 pasaron... y son específicas.
#24 No se puede eso, cada fabricante de CPUs tiene sus propios chipsets y zócalos y no son compatibles con las de otros fabricantes ni con otras familias de CPUs del mismo fabricante, aunque dependiendo de la familia y modelo de CPU, puedes llegar a usar una placa base con chipset nuevo en una CPU anterior, por ejemplo usar un i5 6600K en una placa base con chipset Z270, o en el caso de modelos antiguos de AMD, mezclar placas base modernas con socket AM3 con CPUs antiguas del socket AM2+, pero a día de hoy AMD ha hecho como Intel y a cada nueva familia de CPUs van a cambiar de socket y chipset.
Resumen: si cambias de CPU cambias de placa base y puede que hasta de RAM.
#34 Eso no es correcto. El socket AM4 que usa ryzen va a tener soporte hasta 2020 creo recordar. Cada familia de cpus no necesita socket y chipset nuevo hasta dentro de un par de generaciones de forma que Zen de 2017, Zen+ de este año y Zen2 del año que viene se podrán usar en una misma placa base. Eso si, siempre que el fabricante de soporte actualizando la BIOS.
#24 Eso no, pero recuerdo a Wardog mencionando no se qué de una becaria con unos alicates de corte y unos módulos de RAM que no le encajaban que...
#66
http://mundowdg.com/blog/2013/05/06/la-chica-de-practicas/
Daisy pasa otra vez de vuelta a su PC a medio montar con uno alicates de corte en la mano. Hija de puta. Esta criatura no atasca.
-Daisy, bonita, ¿qué vas a hacer con los alicates?
-No entra la RAM.
-Déjame ver… – me acerco a ver el interior de la carcasa. Ha elegido una placa AMD AM3 y dos módulos de memoria DDR. Si hay algún lego en la materia en la sala, por favor, sírvase de visualizar la siguiente imagen para comprender por qué Daisy, en ese momento perdió mi respeto.
Adaptador de memoria DDR a DDR3 por cojones edition:
#79 Bueno... yo conozco a todo un profesor de informática serrar una tarjeta de video por que se sobraban pines y no le entraba.
#66 Adaptador de DDR a DDR2 "por cojones edition"
#24 Si cambias de marca de procesador tienes que cambiar la placa.
#24 cortar los pines con unos alicates es una locura, si encajas la CPU a martillazos los pines sobrantes ya se doblan y caen solos
#24 La placa es específica, el socket del procesador también, por lo que no te vale ni el disipador ni el ventilador.
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.
#2 ¿Ryzen no está afectado por Spectre?. Que aunque menos grave que el bug que afecta sólo a Intel es más difícil de arreglar.
#36 Básicamente, todos los procesadores comerciales son susceptibles a Spectre así que no hay una opción buena (sólo una mala y otra pésima).
#36 No, no están afectados.
http://github.com/torvalds/linux/commit/00a5ae218d57741088068799b810416ac249a
#85 No es eso, a los micros AMD no les afecta Meltdown (que se sepa), pero Spectre afecta a practicamente todo lo fabricado en los últimos 20-30 años.
En un MacBook Pro está chupado. Sacas la radial y después a cincel despacito va saliendo.
Con los PowerPC estábamos mejor, esto de cambiar a Intel fue una conspiración desde el principio para obligarnos a renovar el ordenador
Pues reíros, pero en el armario guardo varios procesadores 486DX.
A ver si veo la foto, sino os subo una nueva, de momento os dejo mi opinión sobre Intel:
#26: Creo que el de la derecha es PWNable y el de la izquierda no.
#26: Procesadores 486, DX1, DX2 y DX4 (en teoría son imPWNeables, porque son anteriores a 1995), podéis estar tranquilos cuando viajéis en tren, los procesadores que usa el ASFA digital son 486 a 66 mHZ (imagino que sea un DX2), así que no podrán PWNear el ASFA usando este fallo:
#26 mis unpwneables: Z80, 6502, 8088, 486DX2, Pentium 133, K6-2 350
Solo que no hay una CPU compatible con el mismo zócalo a la que cambiar.
Estos del CERT son unos cachondos.
Yo no sé si habláis desde el desconocimiento o sois tontos.
Por partes: Ambos bug's, lo "único" que permiten, es acceder a partes de la memoria que no corresponden al aplicativo en ejecución, además, de una manera relativamente lenta y tosca.
Esto no implica menos seguridad "per se" si ningún software lo utiliza dado que, estos "fallos de diseño" no tienen una forma de ser explotados de manera remota.
Por lo tanto, es necesario tener en tu PC un software en ejecución (Software o script con acceso nativo, no nos vale una web) que tenga las malvadas intenciones de ejecutar este tipo de "funcionalidad no esperada".
Ese software, lo único que podría hacer con esa "funcionalidad no esperada" es acceder a lo que hay en memoria de tu PC, en memoria RAM, en ejecución (no en el disco duro), con lo cual es prácticamente irrelevante. Vale, no es irrelevante si consiguen hacerlo (Que lo veo difícil) una escala de privilegios en base a esto.
Así pues, en principio, no es más peligroso (y si mucho más dificil para quien tenga estas intenciones) que dar permiso de adminsitrador a un ejecutable (cosa que nos pasamos el dia haciendo) o que tener Windows XP donde todo se ejecuta con administrador per se.
Dicho esto, el fallo, es relevante únicamente (a mi parecer), y con relevante me refiero a una mejora de panorama para un supuesto atacante, en servidores donde hay máquinas virtuales corriendo (Entiéndase como el famoso y popular actual cloud), pues desde tu máquina virtual que puedes contratar desde 2,99 € al mes, puedes acceder a los datos en memoria de todo el sistema (otras máquinas) pudiendo, tras trabajo pero con recompensa casi segura, ver toda su memoria y probablemente aprovechar algo de lo "robado" en tus supuestos fines maquiavélicos.
Así que, todos los que habláis de cambiar de procesado o que esto sea para vender cpu's etc. etc: No digáis gilipolleces, pues a los usuarios que utilizamos nuestro propio PC sin dar acceso a otros a través de maquinas virtuales no nos afecta en "prácticamente" nada pues que un hacker decida utilizar esto es por ahora inviable, dado que tendría que conseguir una escala de privilegios a través de ese bug para poder instalar un ransom o algo a lo que le sacase más provecho que a ver que pestañas tienes abiertas en el Chrome.
Esto es solo un golpe al Cloud, que por otro lado, gracias Jesusito por que se está yendo de las manos.
Ah, y si, me creo que sea un fallo de diseño pues la NSA y demás paranoias que apuntáis lo tienen mucho más fácil por otros lados.
Este bug no vale para demasiado con los accesos que ya se ha demostrado que tienen.
#47 Yo debo ser tonto, porque algo conozco y....
> Por lo tanto, es necesario tener en tu PC un software en ejecución (Software o script con acceso nativo, no nos vale una web) que tenga las malvadas intenciones de ejecutar este tipo de "funcionalidad no esperada".
Eso lo dices tú, pero no es lo que opinan los expertos en seguridad. Es cierto que es más complicado conseguir un exploit desde javascript porque por medio está el JIT compiler (que es donde quieren mitigar el problema) pero si no se mitiga, es solo cuestión de tiempo que alguien lo consiga.
> Ese software, lo único que podría hacer con esa "funcionalidad no esperada" es acceder a lo que hay en memoria de tu PC, en memoria RAM, en ejecución (no en el disco duro), con lo cual es prácticamente irrelevante. Vale, no es irrelevante si consiguen hacerlo (Que lo veo difícil) una escala de privilegios en base a esto.
Si hablamos de Meltdown (que permite leer la memoria del kernel), esa escalada es facilísima. Por ejemplo encontrando un file descriptor de escritura a un archivo de sistema, o conseguir leer el teclado del usuario mientras hace login, o ... mil otras formas. Si puedes leer la memoria del kernel la máquina es tuya 100% seguro.
> Así que, todos los que habláis de cambiar de procesado o que esto sea para vender cpu's etc. etc: No digáis gilipolleces, pues a los usuarios que utilizamos nuestro propio PC sin dar acceso a otros a través de maquinas virtuales no nos afecta en "prácticamente" nada
Como mínimo te afectará cuando se te instale el parche que acaba de sacar Microsoft/Apple/Linux, que enlentece la CPU para ciertos workloads (como por ejemplo aquellos en que tu flamante nuevo pc lea datos a tope de un disco NVMe).
Lo de la NSA es una paranoia, estoy de acuerdo. Y los primeros y más afectados han sido los proveedores cloud, eso también es cierto (y lo explico en #49 ). Salud!
#50
> Eso lo dices tú, p... conseguir un exploit desde javascript porque por medio está el JIT ..
¿A si? pues ya me contarás como. Ilustrame porfavor. La única forma, sería un un JavaScript mixto, es decir, un JavaScript con una interfaz nativa incrustada, lo que en Android se llama JavascriptInterface en un webview de alguna aplicación que implementase una supuesta función nativa que permitiese eso, que también es improbable encontrar una ya preparadita y lista para poder "engañar al usuario" y ejecutar este "exploit" además, como ya digo, solo daría acceso a lo que hay en memoria. Irrelevante, improblable, inespecífico y estúpido como ataque.
> Ese software, lo úni... esa escalada es facilísima...
Y luego me hablas de esperar a que le usuario haga login. Entonces no es fácilisima, ya hay otros métodos mucho más fáciles y efectivos y no sería aplicable en servidores. Además que tendrías que estar escuchando la memoria en el momento preciso en la dirección exacta. Demuestrame que es tan fácil. No te digo que se imposible, te digo que es técnicamente demasiado complejo e innecesario habiendo otras formas.
> Como mínimo te afectará... ...ope de un disco NVMe).
¿NVM? Pues si que estás en tecnologías muertas antes de nacer. Ya me contarás que usuarios son esos que tienen sus SSD en PCIE, y aún así, la afectación sería por la "solución" para evitar que el software pueda leer memoria a través del sistema, lo cual ni es una solución, pues por encima del OS podrías seguir leyendo memoria no asignada, ni es por culpa del problema.
No sé si serás tonto o que conoces poco, pero vamos, que con tus mismos argumentos me estás dando la razón.
Este "fallo" es irrelevante (por suerte) para el usuario.
#52 No estoy aquí para darte clases.
> ¿A si? pues ya me contarás como. Ilustrame porfavor.
Si desde javascript no se puede disparar esa vulnerabilidad, ¿qué hace la gente de chrome desallorando mitigations? https://www.chromium.org/Home/chromium-security/ssca
> te digo que es técnicamente demasiado complejo e innecesario habiendo otras formas.
Claro, claro. Muchísimas formas hay, y tu en vez de estar ganando Pwn2Own cada año te dedicas a insultar a gente por menéame.
> Ya me contarás que usuarios son esos que tienen sus SSD en PCIE.
Todos los que se han comprado y se compren portátiles de alta gama, así como todos los que usan M.2 "moderno" (hay M.2 SATA pero eso si que está muerto).
> No sé si serás tonto o que conoces poco, pero vamos, que con tus mismos argumentos me estás dando la razón.
Tus argumentos sí que son buenos
#47 ...
Primero, que la vulnerabilidad no sea explotable de forma remota no significa que sea menos grave, sobretodo si se puede explorar haciendo que un usuario visite una simple web.
Segundo, la escalada de privilegios la puedes dar por hecha en Meltdown y aunque para Spectre, en principio no seria posible (falta por ver cómo evoluciona el tema), si no ves el problema en un script de cualquier web que es capaz de trazar las páginas que visitas y las contraseñas que escribes, no sé quién es el tonto aqui...
#56 ningún script web es capaz de nada y si crees que si, es que no tienes ni idea de lo que hablas.
O porfavor, ilustrame con esos links
#61 el propio white paper de Spectre confirma JavaScript como vector de ataque. Hay por ahí cómo volcar el gestor de contraseñas de Firefox. No te pongas en ridiculo
#71 estoy esperando a ver un ejemplo. Gracias.
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.
Menos mal que hay alguien aquí que sabe diferenciar entre kernel mode y user mode y la ejecución especulativa. Gracias #47 y #49
A los demás, os recomiendo leeros estos papers antes de opinar:
Meltdown: https://meltdownattack.com/meltdown.pdf
Spectre: https://spectreattack.com/spectre.pdf
Al igual que el dieselgate ha propiciado el fin de los coches diésel, ésto seguramente promoverá el abandono de la arquitectura x86 en favor de la arquitectura ARM. Microsoft ya está ultimando su Windows 10 para ARM y linux ya hace mucho que es capaz de funcionar sobre éste. El oligopolio de los x86 de alto consumo y ridículos disipadores toca a su fin. Seguramente el rendimiento no será el mismo en el medio plazo pero creo que el cambio va a traer más ventajas que inconvenientes.
#45 Los ARM también son vulnerables, por lo menos los más comunes en telefónos/tablets/etc: https://support.apple.com/en-us/HT208394
#45 Mejor pasar a AMD64.
#83 Puestos a soñar, mejor a RISC-V.
#45 ¿Propiciado el fin de los coches diésel? ¿Dónde, aquí en España? https://www.autocasion.com/actualidad/noticias/las-ventas-de-gasolina-y-diesel-se-igualan-en-espana-en-2017 Habrá ayudado a favorecer a la gasolina, pero ni de coña ha propiciado el fin de los diesel.
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.
1) CERT: "la única manera de solucionar por completo Meltdown y Spectre es cambiando la CPU".
2) Pero de momento no existe una CPU alternativa que sea válida para evitar este problema, o al menos que sea competitiva.
3) Conclusión: casi nos están diciendo que la única salida es apagar durante unos añitos nuestro internet
#33
2) Claro que si, Ryzen para usuarios domésticos y Epic para servidores.
3) La salida es darle la patada a Intel.
Tecnicamente si emulas, no virtualizas, todo, no tiene porque afectarte, claro que la perdida de rendimiento es heavy
#40 Eso sería como matar mosquitos con una escopeta.
Hay Meltdown y Spectre, hay meneo
#14 Hay política, hay meneo.
Hay tecnología, hay meneo.
Hay noticia, hay meneo.
A ver si estás descubriendo a estas alturas de lo que va menéame...
A ver lo que tardan en sacar un nuevo WannaCry con todo este pollo....
#9 un WannaCry* ahora sería demoledor, porque, si los equipos no están parcheados, el control que tendrían sobre el equipo sería total.
* alguna vulnerabilidad remota o algo.
Lo único que sé es que ahora da más miedo pagar con tarjeta en la red.
Y esto tambien afectará a todos los convertibles y demás portátiles con la CPU soldada a la placa.
#37 hasta donde yo conozco... Los micros de los portátiles van en un zócalo también.
#67 muchos portatiles ultra portables van soldados, no solo el micro, si no la ram y el disco duro tambien.
#37 probablemente si, y sobre todo a tablets Atom que si ya iban ajustadas de narices ahora serán trozos lentos de mierda... Yo la mía pasaré de actualizarla (en detrimento de la seguridad) a cambio de no utilizarla para nada privado (compras por internet, logins críticos, etc.).
Aún así... se está exagerando mucho esto en cuanto a las implicaciones que tiene para la gran mayoría de usuarios domésticos...
#98 La mayoria de usuarios domesticos tienen cada vez mas datos y servicios externalizados en la nube o proveedores de cloud, siendo una extension de cada uno de esos usuarios domesticos y compartiendo maquinas virtuales con otros "usuarios". Las implicaciones que esto pueda tener estan por ver.
#98 Los navegadores son vulnerables y se pueden explotar con javascript. Verás tu que alegrías....
el mío no está afectado
https://upload.wikimedia.org/wikipedia/commons/3/3c/Chimpanzee_seated_at_typewriter.jpg
Una pregunta desde el desconocimiento....
¿El tema afecta a los procesadores a la hora de ser utilizados para virtualizació?... es decir, un servidor físico dedicado... ¿en que manera se vería afectado?.
Es que lo que me lleva a confusión - y por lo que creo (seguramente de manera equívoca) - que el impacto de este problema se produce en sistemas de virtualización , independientemente de la naturaleza ,me refiero que supera a que sea la nube de amazon, de microsoft ... (que sea sistemas basados en citrix, hyper--v, vmware)... que es donde esta ahora el mercado
¿sería la solución volver a servidores físicos (y por tanto a CPDs monstruosos)?
Gracias por adelantado.
#42 Resumen: No sería solución y a tí también te afecta.
Es importante entender que esta es la primera demostración de la idea de que se pueden atacar sistemas "trasteando" con la ejecución predictiva que hacen prácticamente todos los procesadores "potentes" del mercado (desde hace años!). Los que tuvieron esa idea pensaron en formas concretas de ponerla en práctica. El resultado son, actualmente, dos ataques concretos: "Meltdown" y "Spectre".
MELTDOWN, que solo afecta a procesadores Intel, es el que más ha preocupado a corto plazo: resulta que, usando este tipo de ataque, es posible saltarse las protecciones de memoria que debería asegurar el procesador. Eso significa que un atacante puede leer CUALQUIER parte de la memoria que le de la gana, incluida la memória de otras máquinas virtuales alojadas en el mismo hardware, desde dentro de una máquina virtual mismo!
Esto dejaba "en bolas" a todos los tinglados cloud porque cualquiera podría robarle info a "sus vecinos" (que son otros clientes). Este bug es el que se han apresurado a mitigar por todos lados (ya hay patches para Linux, Windows y MacOS). Estos parches lo que hacen es putear al procesador a drede para que la ejecución predictiva no funcione, evitando así que se pueda "disparar" el bug (a costa de disminuir el rendimiento de la CPU claro!).
De aquí viene la idea de "si no virtualizo no hay problema", pero es una idea falsa. Si no virtualizas pero tienes CPU intel, lo que pasa con este ataque es que un programa cualquiera, ejecutado por un usuario cualquiera, puede leer la memoria del sistema operativo, y por tanto obtener privilegios de root/administrador/sistema y controlar tu pc por completo (el sueño de todo worm/virus/cosa maliciosa). Por eso el parche también te lo aplican a ti que no virtualizas.
SPECTRE es otro ataque, más sutil y difícil de explotar. Con este ataque (en realidad son dos) lo que se consigue es leer cualquier parte de la memoria *de tu mismo proceso* (no puedes leer lo de otros procesos). Esto puede sonar poco peligroso, pero no lo es por un sencillo motivo: ahora mismo estás usando un programa (tu navegador web) que ejecuta programas de otra gente sin preguntarte (scripts javascript). Usando este ataque, es teóricamente posible que una web cualquiera lea los datos de las otras webs que tienes abiertas, incluyendo contraseñas, cookies de sesión, etc. Vamos, que visitando una web cualquiera te podrían robar la tarjeta de crédito que estás metiendo en amazon para comprar una chorrada, por ejemplo. De momento no han conseguido llevarlo a la practica en javascript (es complicado porque hay un JIT que interpreta y compila el código javascript, así que no es fácil terminar generando instrucciones específicas para disparar el bug), pero es solo cuestión de tiempo.
Durante este tiempo, tanto los desarrolladores de navegadores, como todos aquellos programas que permitan ejecutar scripts o plugins de terceros tratarán de buscar formas para evitar que esos scripts/plugins puedan disparar el bug.
DESGRACIADAMENTE, esto será una guerra que durará mucho tiempo. Estos dos ataques concretos son solo la primera oleada de ataques basados en "trastear con la ejecución predictiva", porque en el fondo el problema es del diseño del hardware. Este diseño se viene usando desde hace más de una década, y hoy en día lo usan prácticamente todas las CPUs "potentes" (incluídas tablets y moviles). El CERN dice que lo mejor es cambiar de CPU (a una que no haga ejecución predictiva), pero... eso no existe hoy en día (con potencia como para hacer el trabajo que hacen las CPUs afectadas). Por tanto, vamos a estar haciendo "chapuzas" para evitar los ataques que vayan apareciendo, mientras otra gente se dedica a buscar nuevos ataques que exploten este problema.
Y ya para terminar de hacerme pesado, voy a explicar un poco cuál es ese problema. La idea de la ejecución predictiva es que, cuando el procesador debería quedarse esperando alguna información de la memoria, en vez de quedarse parado "asume" qué datos vendrán y va ejecutando como si los tuviera. Si cuando llega la información esta coincide con lo esperado, se sigue ejecutando con ese trabajo ya adelantado (yuhu!). Si no, el procesador "deshecha" ese trabajo que ha "adelantado", vuelve al punto donde se habría parado, y ejecuta a partir de ahí pero con la información de verdad. Esta idea está muy bien (y funciona muy bien!), pero tiene un problema: el seguir ejecutando en vez de esperar tiene efectos secundarios, aunque luego deseches el trabajo. De hecho, no está claro que sea posible deshacer TODO lo que hayas cambiando mientras "se adelantaba trabajo". Lo que si está claro es que los procesadores actuales no consiguen deshacerlo, y de eso es de lo que se aprovechan Meltdown y Spectre: consiguen que el procesador vaya "adelantando trabajo" y luego observan los efectos secundarios producidos para descubrir información que en teoría no les toca conocer!
#49 Buenísima explicación, muchas gracias.
#49 lo que se consigue es leer cualquier parte de la memoria *de tu mismo proceso* (no puedes leer lo de otros procesos).
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);
#42 Respuesta corta: sí, precisamente los entornos de virtualización son los más afectados.
Respuesta larga: ya te la ha dado el usuario aiguy
Pregunta tonta. En un sistema virtualizado habría que aplicar los parches del sistema operativo a las máquinas virtuales también o sólo al anfitrión. Me imagino que a todo Cristo ¿no?
#54 según VMware hay que parchear tanto el hypervisor como el guest.
#59, #54 Es lo logico:
parcheas los guests para que las aplicaciones no puedan acceder a memoria de kernel y de otros procesos ( a traves de leer cosas de kernel )
parcheas el host para que las VMs no puedan acceder a memoria del host y para que las aplicaciones no puedan acceder a memoria del kernel y de otros procesos.