Kernel Crash-Exploit descubierto

[Carlos Manuel Duclos Vergara]

>> el punto seria buscar la manera de evitar que alguien pueda cambiar los
>> bits de la FPU mas que evitar que la interrupcion provoque la debacle;

>La interrupcion dentro del nucleo provoca la debacle porque _no_ la
>interceptan/manejan adecuadamente. Creian que interrupciones de la FPU en
>el nucleo eran imposibles...

el punto es que no debieran ocurrir, al menos no de esta forma

>>
>no
>> puse mayor atencion al codigo del ejemplo, pero habria que preguntarse:
>> 1.- que privilegios requiere el codigo para ser ejecutado?

>Usuario corriente.

puedo entender que el usuario corriente pueda leer el registro, pero
cambiarlo? es como un sistema de seguridad que usa identificacion
biometrica + tarjetas de seguridad encriptadas + cuanta cosa se pueda usar
y que tiene un ventana sin vidrio...

>> 2.- como es que un registro sensible como el estado de la FPU esta
>> disponible para ser cambiado?

>Porque son flags de estado de la FPU, no es privilegiado de ninguna
forma.

su lectura, pero la escritura es tirado de las mechas que no sea
privilegiado

>> 3.- se necesita cambiar el valor de ese registro?

>Yep. Cada vez que efectuas una operacion de punto flotante cambian,
registran modo de redondeo, genero NaN, ...

eso lo _DEBE_ hacer el procesador, no el usuario o los x86 son peores de
lo que pensaba

>> 3.a.- No: es posible cambiar el mapa de memoria y dejar ese registro en
una
>> region ro?

>Imposible. Son flags de la CPU.

mayor razon aun, el usuario lo unico que necesita es saber si funciono o
no, no necesita pichicatear la FPU para nada...