Intel detecta problema en sus procesadores

AikonCWD

#329 En #68 tienes un mini resumen muy básico, luego tienes el video de #222 que lo explica muy bien y es un poco más extenso.

Parches para Windows, para clientes y servidores

#317 https://www.reddit.com/r/sysadmin/comments/7o1769/go_check_your_proccpuinfo_it_will_contain_cpu/ para comprobar el bug en Linux

1 1 respuesta
B

#322 se llevan diciendo muchas cosas desde el inicio del post. Desde pérdidas del 30% a 0 pérdidas y mejora de rendimiento incluso.
Una cosa son habladurías, esto son pruebas.
Pero a lo tuyo.

1
B

#322 en #56 puse yo los primeros benchmark y dentro del articulo habia otro enlace a pruebas en juegos , supongo que se refiere a eso.

B

Por aqui estamos expectantes a ver que dicen los desarrolladores, al parecer Microsoft en las release notes hablan de un registro que, en teoria, deberia crear el Antivirus, aunque no se sabe con claridad qué impacto tendra crear dicho registro, si debía de estar creado con anterioridad, y el impacto del mismo.

Por el momento el parche solo esta para Windows 10 y para el resto el proximo martes.

1 respuesta
Naith

#334 https://support.microsoft.com/en-us/help/4072699/important-information-regarding-the-windows-security-updates-released

1 respuesta
Kaiserlau

No es por nada pero cualquiera se fia del parche en windows. Es por ponerme gratuitamente el tinfoil.

B

#335 Microsoft has identified a compatibility issue with a small number of anti-virus software products.

Y no dicen que av estan afectacdos...

1 respuesta
B

Mi ESET se ha actualizado esta mañana. Tengo miedo

Naith

#337 algo de info. https://docs.google.com/spreadsheets/d/184wcDt9I9TUNFFbsAVLpzAtckQxYiuirADzf3cL42FQ/edit#gid=0

1 1 respuesta
B

#339 Se supone que con el parche se añade tambien la key ? Yo tengo nod32 y veo que si lo agrega, pero tengo conocidos que no usan eset y no se si el parche agrega la key

Kaiserlau

Los antivirus son el bien

1
DiSKuN

creo que Debian aún no han publicado el parche a sus repositorios -_-

1 respuesta
xBoSS

#342
Debian con la calma, para 2020 si eso.

1 1 respuesta
DiSKuN

#343 ya , ya. Han de testearlo hasta en una cuchara para que lo publiquen xD.

De CentOS no encuentro info si lo han publicado -_-

2
SiCk

Edit: dupe de #330.

1
DiSKuN

#331 los patches del link de servers, ¿los publican luego mediante Windows Update? Porque el de 2012 R2 aparece, pero cuando paso el check updates me indica que no hay ninguna update para descargar :\

Soy pez en Windows Server

2 respuestas
AikonCWD

#346 Los meterán en el auto-update el martes

1 respuesta
B

#346 En nuestro Wsus ha bajado parches esta noche de 2008, 2008r2, 2012 y 2012r2. Aun no nos han autorizado para instalar, no te puedo decir mas.

1 respuesta
DiSKuN

#347 #348 Pues ando en la duda si meterlo manual en las máquinas de entorno de DEV o no. Joder, primera semana sólo en el equipo y pasa esto xD Y no tengo un conocimiento profundo de la plataforma

2 respuestas
Kaiserlau

https://lkml.org/lkml/2018/1/3/797

Why is this all done without any configuration options?

A competent CPU engineer would fix this by making sure speculation
doesn't happen across protection domains. Maybe even a L1 I$ that is
keyed by CPL.

I think somebody inside of Intel needs to really take a long hard look
at their CPU's, and actually admit that they have issues instead of
writing PR blurbs that say that everything works as designed.

.. and that really means that all these mitigation patches should be
written with "not all CPU's are crap" in mind.

Or is Intel basically saying "we are committed to selling you shit
forever and ever, and never fixing anything"?

Because if that's the case, maybe we should start looking towards the
ARM64 people more.

Please talk to management. Because I really see exactly two possibibilities:

  • Intel never intends to fix anything

OR

  • these workarounds should have a way to disable them.

Which of the two is it?

               Linus
1
AikonCWD

#349 Nah, no parchees todavía los servers. Y menos si no los tienes publicos a Internet.

B

#349 En desarrollo yo lo pondria, asi ves si algo peta antes de produccion. Nosotros creo que lo empezaremos a poner ya el lunes, el tema del rendimiento acojona y se lo van a pensar.

SiCk

Me surge una duda (perdón por las posibles incongruencias que escriba).
Un exploit aprovechando este agujero sería capaz de hacer lecturas indetectables de toda tu memoria, no? Sería como un megakeylogger (mega porque no sólo lee lo que "escribas" si no la memoria en sí).
No sería indetectable el exploit en sí, pero el backdoor como tal sí. Joder, sería el sueño de un atacante. Si lo "pillas" no sabes "qué" ha visto.

Es decir, fuera del tema del rendimiento y servidores, este agujero (que como siempre con todos tardará años en parchearse en todos los equipos y siempre habrá vulnerables) como alguien en remoto (típico ataque hoy día, no?) consiga acceso de ejecución a tu pc/servidor es ya no control total, es conocimiento total de cualquier instancia-ejecución-actividad :/

Se me ocurren pocos agujeros de seguridad más grandes. Y creo que para usuarios domésticos saldrán mil mierdas aprovechándolo... (sí, que con parches blabla, pero ya sabéis cuando llegan los parches a según qué pcs...).
¿Más o menos o me equivoco mucho?

1 respuesta
AikonCWD

#353 Estos bugs tienen un impacto teórico muy grande, pero un impacto real bastante más reducido. Ese megakeylogger que imaginas ya existe desde hace tiempo y sin necesidad de explotar bugs, basta con escalar privilegios, instalar driver en ring0 y hookear el teclado. Lo mismo ocurre para dumpear datos d eun proceso externo... lanzas un proceso (o lo inyectas), elevas a SE_DEBUG_PRIVILEGE y dumpeas la memoria de un proceso ajeno (passwords de chrome/firefox, hashes NT de sesión, passwords de steam, skype, etc...). Todo eso que imaginas se puede alcanzar desde hace tiempo con otros métodos más fáciles.

A partir de la semana que viene empezarán a salir en public-disclosure y veremos el impacto/alzance real. De momento los payloads y demos que hemos visto en gifs y videos son PoC sobre targets preparados para tal.

2 1 respuesta
B

Yo al final me he decidido y he actualizado todo, en las pruebas que he hecho la diferencia maxima ha sido del 15% con una media por debajo del 9% asi que tampoco es para tanto.

1 respuesta
B

#355 Hombre, perder un 10% de rendimiento no es moco de pavo :D

1 respuesta
B

#354 Me flipa leerte tio, hazte profesor o algo o dame clases particulares

3
B

#356 Hombre, esta ahi, pero una peticion que tardaba 120ms de media ahora tarda 130ms. Teniendo en cuenta que se supone que era una de las cargas de trabajo que peor iban a salir paradas pues tampoco esta tan mal.

1 2 respuestas
B

#358 Yo ya te digo, viendo los múltiples benchmarks que van saliendo, ya no me preocupo en cuanto a rendimiento.

1 respuesta
GaN2

#358 #359 Hay aplicaciones y sistemas en las que la pérdida de incluso un 5% tiene un impacto para negocio brutal, ya no te digo de un 30%. En los Bechmarks que se pusieron más atrás salía uno para PostgreSQL y la ostia era curiosa trás aplicar el parche...

1 respuesta

Usuarios habituales