Sujeción del índice de matriz: ¿es esta una buena idea para la mitigación de Javascript Specter?

Question

Sujeción del índice de matriz: ¿es esta una buena idea para la mitigación de Javascript Specter?

#1 de ximaera (2 votos)

3

De documento de Specter aprendí que el ataque puede tener éxito porque el compilador genera una instrucción de lectura de memoria que se refiere a la no válida. índice de matriz. Y aunque la instrucción normalmente solo se ejecuta después de verificar el índice de matriz, el acceso a los elementos fuera de los límites produce efectos secundarios indeseables a través de la ejecución especulativa en algunas CPU.

javascript:

  x=array[index];

assembler pseudocode:

  MOV reg,index
  CMP reg,array[length]
  JNC fail
  MOV x,array[reg]
  ...access probe array based on x

¿Qué sucede si se cambió el compilador para que nunca genere direcciones no válidas?

assembler pseudocode:

  MOV reg,index
  CMP reg,array[length]
  JNC fail
  AND reg,array[bit_mask] <---| bit mask of all 1's lower than
  MOV x,array[reg]            |  2*length (might be an object member)
  ...access probe array based on x

De esta manera, por el precio de un AND adicional, la dirección utilizada en la lectura especulativa está limitada a menos de 2 * longitud. A continuación, para todos los búferes de matriz, asignemos siempre 2 ^N bytes (N > = log ₂ (longitud)) y el atacante solo podrá sondear su propio no utilizado memoria (alternativamente, organice las asignaciones de memoria de modo que la única memoria disponible para sondeo sea la de sus otros buffers).

¿Es esta una buena idea?

javascript spectre

pregunta szulat 08.01.2018 - 02:19

fuente

1 respuesta

Lea otras preguntas en las etiquetas javascript spectre

PHP y MySQL encriptan los datos que necesito para descifrar en algún momento Anonimización de identidad de usuario

score 2 · Answer 1

Los desarrolladores de WebKit adoptaron un enfoque similar, entre otros medios, para mitigar los posibles efectos de Specter.

Ver: "Qué significan Specter y Meltdown For WebKit" , párrafo "Enmascaramiento de índice" .

Tenga en cuenta que el enmascaramiento de índice es diferente de su propuesta en que no requiere asignar 2 bytes ^N para cada matriz (en el peor de los casos, casi el doble de lo requerido), por lo tanto, sigue exponiendo una porción de información (algo limitada) para un atacante, pero reducir la cantidad de datos permitidos para que un atacante pueda leer en general y guardar algo de memoria en aras de la efectividad. Para las matrices grandes, podrían confiar en ASLR, lo que hace que sea menos probable que haya una asignación dentro de la accesibilidad de la máscara de índice.

Sin embargo, lo que exactamente podría estar expuesto a un atacante de esta manera en WebKit depende de su arquitectura y base de código; El tuyo puede ser diferente.

Con respecto a la efectividad de asignar casi el doble de la memoria solicitada en el peor de los casos, vale la pena mencionar que la tasa ideal de crecimiento de la matriz es cercana a 1.6 y el factor de crecimiento de 2 se usa ampliamente pero es mucho menos efectivo .

Sin embargo, suponiendo que se trate de Linux, es probable que haya un truco que se podría usar para reducir la cantidad de memoria que se está perdiendo y al mismo tiempo estar a salvo de lecturas especulativas fuera de los límites. Puede intentar escribir un asignador personalizado que, para arreglos de al menos más de 2 * tamaño de página (este último es 4K en la mayoría de las circunstancias, pero más estrictamente, sysconf(SC_PAGE_SIZE) ), primero analizará /proc/self/maps para encontrar una región de memoria no asignada de un tamaño de al menos 2 ^N bytes, N > = log ₂ (array_length), y luego asigna solo el tamaño requerido mediante mmap(MAP_FIXED) .

Se necesitaría algún trabajo posterior para garantizar que no se asignaría ninguna memoria dentro de 2 * longitud de cualquier matriz asignada anteriormente, pero esto todavía no es una ciencia de cohetes.

Las páginas de memoria asignadas y devueltas serán consecutivas en la memoria virtual, pero no se requiere que sean consecutivas en la memoria física, por lo que este enfoque no causaría la fragmentación de la memoria física . La subsiguiente fragmentación de la memoria virtual probablemente no sea un problema en un sistema de 64 bits en el futuro, ya que 16 Exabytes de memoria direccionable total deberían ser suficientes para cualquiera.

Otros sistemas operativos probablemente tengan herramientas similares a las de Linux.

Con respecto a WebKit, ya que también incluye otras mitigaciones, que en este momento están destinadas a ser suficientes para los efectos de Specter, el enmascaramiento de índices es una mitigación bastante excesiva para ellos, y su enfoque es adecuado para el modelo de amenaza restante. .

Tu modelo de amenaza, sin embargo, podría ser diferente. Eso es todo lo que sabemos.