Investigadores de seguridad de Google han descubierto una forma de burlar la seguridad de AMD, lo que les permite cargar microcódigo no oficial en sus procesadores y modificar a voluntad el comportamiento del silicio. Para demostrarlo, crearon un parche de microcódigo que obliga a los chips a devolver siempre 4 cuando se les pide un número aleatorio. Esta capacidad también socava la virtualización cifrada segura de AMD y los mecanismos de seguridad de raíz de confianza.
|
etiquetas: amd , microcódigo , vulnerabilidad 
RFC 1149.5 specifies 4 as the standard IEEE-vetted random number
Así que no sé de qué se las dan los investigadores estos de Google, ni que hubieran descubierto la pólvora.
Son muy grandes...
" El IPoAC ha sido implementado con éxito para nueve paquetes, con un ratio de pérdida del 55% por fallos del operador,2 y un tiempo de respuesta entre 3000 y 6000 segundos (54 minutos y 1.77 horas, respectivamente), por lo que esta tecnología sufre de una alta latencia. Aun así, para grandes transferencias, las palomas son capaces de un alto rendimiento, implementando una sneakernet. En los
… » ver todo el comentario
Eso sería si cada paloma llevase
8 tarjetas SD
(ej: nanoSD, microSD)
145.6/(512*16*8/3600) ≈ 8
512 GByte / SD
16 palomas
8 bits / Byte
3600 segundos / hora
Otra opción serían 2 tarjetas de 2 TB cada una por cada paloma.
No recuerdo quién comentaba hace ya algún tiempo, cuando las conexiones no eran lo que son ahora, que el bandwidth de coger unos cuantos discos y llevarlos en coche al CPD era muy superior a las mejores conexiones del momento, y había algún artículo sobre llevar un huevo de discos en un autobús, que posiblemente no se haya superado todavía
Para coordinarnos con AMD, hicimos una excepción única a nuestra política estándar de divulgación de vulnerabilidades y retrasamos la divulgación pública hasta hoy, 3 de febrero de 2025. Esta divulgación conjunta se produce 46 días después de que AMD compartiera la solución con sus clientes y 131 días después del informe inicial de Google
Para lo demás goto #15
No. No dice como hacerlo te pone un test.
"we will not be sharing full details at this time in order to give users time to re-establish trust on their confidential-compute workloads. "
De todos modos, está guay que se comente y se corrija.
Tras entrar en una máquina, puedes usar una elevación de privilegios y luego modificar la entropía con esta vulnerabilidad, si lo consigues en un "host" de virtualización sospecho que todas comunicaciones de todas las máquinas virtuales estarían comprometidas, entre otras cosas.
Dime que no es jugosa la vulnerabilidad.
Es como decir que has encontrado una manera para burlar una parte de la alarma de casa pero para ello tienes que tener acceso al codigo de la alarma...
Que entiendo que lo puedas cambiar para hacerlo mas coloquial. Pero la noticia también dice que es en algunas CPU de AMD (Zen 1 a 4). No en cualquier CPU de AMD.
#17 La noticia está bien. Yo solo me quejo del titular, sobre todo porque llevo días viendo titulares del estilo.
El titular directamente es erróneo. De cualquier CPU zen NANAI.
¿No sucede lo que dice la noticia en portada?
¿Se deberia silenciar lo que ocurre con AMD para no ser maliciosos?