[escepticos] Stuxnet

Mie Oct 6 16:20:39 WEST 2010

[Borja] 

Pero ¡si es lo que estoy diciendo! ¿De dónde viene la mezcla? Pues porque para que un proceso de usuario pueda "salirse del tiesto" y, por ejemplo, cambiar su identificador de usuario en la tabla de procesos, una posible vía es que el procesador se lo permita. Y una posible vía para ello sería que un microcódigo malicioso (insertado, por ejemplo, en la fábrica) "reconozca" determinada secuencia de instrucciones, o algo tan tonto como determinada instrucción ilegal, y proporcione ese permiso al proceso.

A ver si se entiende ahora... Microcódigo malicioso permite que un proceso modifique sus credenciales de usuario en la tabla de procesos, violando la protección de memoria. 

[Adrià]

Vale vale.  Al final (como suele pasar) se dice lo mismo con otras palabras.  Yo simplemente mostraba un escenario de un ataque a un sistema con una CPU "sana" (sin manipulación de fábrica ni bugs).  Está claro que todo sistema de seguridad, por sofisticado que sea, es sorteable si está manipulado...

[Borja]

No, eso son (en terminología Intel) las tablas que se utilizan para gestionar la memoria virtual... 

[Adrià]

Cierto!  Oxidado que tiene un el tema.  Me había confundido porque (nomenclatura Intel) en la GDT también se guardaban los TSS que me suena eran descriptores de procesos (igual eran los utilizados para la conmutación de tareas, me lo tendría que releer... han pasado muchos años :P).  Igualmente, me suena -si mi memoria no me (vuelve) a fallar- que la tabla de procesos suele estar también en memoria privilegiada (..y que sí, sería manipulable si la CPU estuviera "trucada" o tuviera algún bug), pero no quiero hablar más que no quiero volver a meter la pata.. :)

[Borja]

Mira las páginas de manual de kvm(3) o sysctl(3) en FreeBSD, por poner un ejemplo. Es muy fácil obtener las direcciones de memoria donde están esas tablas. Quizás en sistemas no Unix es más complicado, no lo he mirado.  En los Unix es habitual tener acceso a una tabla de símbolos, etc.

[Adrià]

Les echaré un ojo... Thanks! 

Adria Comos / Software Engineer / Timing & Computing / Dorna Sports S.L.
Tel. +34 934 702 832  /  Fax. +34 934 737 779
Narcís Monturiol 2, 08960, Sant Just Desvern - Spain

www.motogp.com
www.dorna.com

cid:image001.jpg en 01C9A7C0.EE87DAD0

******************************************* DISCLAIMER ***********************************************
This message is intended exclusively for the named person. It may contain confidential, propietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it an notify the sender. Your must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient.
Please note that internet e-mail neither guarantees the confidentiality nor the proper receipt of the message sent. If the addressee of this message does not consent to the use of internet e-mail, please communicate it to us immediately.

****************************************** AVISO LEGAL ***********************************************
Este mensaje es solamente para la persona a la que va dirigido. Puede contener información confidencial o legalmente protegida. No hay renuncia a la confidencialidad o privilegio por cualquier transmisión mala/errónea. Si usted ha recibido este mensaje por error, le rogamos que borre de su sistema inmediatamente el mensaje asi como todas sus copias, destruya todas las copias del mismo de su disco duro y notifique al remitente. No debe, directa o indirectamente, usar, revelar, distribuir, imprimir o copiar ninguna de las partes de este mensaje si no es usted el destinatario.
Nótese que el correo electrónico via Internet no permite asegurar ni la confidencialidad de los mensajes que se transmiten ni la correcta recepción de los mismos. En el caso de que el destinatario de este mensaje no consintiera la utilización del correo electrónico via Internet, rogamos lo ponga en nuestro conocimiento de manera inmediata.

**********************************************************************************************

-----Original Message-----
From: escepticos-bounces en dis.ulpgc.es [mailto:escepticos-bounces en dis.ulpgc.es] On Behalf Of Borja Marcos
Sent: Wednesday, October 06, 2010 4:49 PM
To: Lista Escépticos
Subject: Re: [escepticos] Stuxnet

On 6 Oct 2010, at 16:25, Adria Comos wrote:

> 
> ¿Disculpa? ¿Qué crees que hace falta en Unix/Linux para que un proceso que pertenece al usuario X pase a ser del superusuario? Pues cambiar un valor en la tabla. Si estás usando un sistema de seguridad más complejo, basado por ejemplo en políticas MAC, ¿qué crees que son las etiquetas de confidencialidad/integridad? Pues lo mismo, un par de numerillos en una tabla.
> 
> [Adria]
> 
> Creo que sí, que estas mezclando cosas, debido a la nomenclatura "usuario".  
> 
> Hablando de los sistemas que conozco -Windows, Unix, Linux- (de otros 
> no se, pero me extrañaría que no fuese así), una cosa son los 
> "permisos del usuario" (escritura, lectura, ejecución, acceso a 
> dispositivos, etc...) de un usuario/superusuario a nivel de S.O, y 
> otra los privilegios de los procesos a nivel de CPU.  Son dos mundos 
> totalmente diferentes e independientes

Pero ¡si es lo que estoy diciendo! ¿De dónde viene la mezcla? Pues porque para que un proceso de usuario pueda "salirse del tiesto" y, por ejemplo, cambiar su identificador de usuario en la tabla de procesos, una posible vía es que el procesador se lo permita. Y una posible vía para ello sería que un microcódigo malicioso (insertado, por ejemplo, en la fábrica) "reconozca" determinada secuencia de instrucciones, o algo tan tonto como determinada instrucción ilegal, y proporcione ese permiso al proceso.

A ver si se entiende ahora... Microcódigo malicioso permite que un proceso modifique sus credenciales de usuario en la tabla de procesos, violando la protección de memoria. 

> Al final es cierto que todo son tablas, pero la diferencia es que de 
> la que hablo está protegida por hardware (la CPU. No el S.O., no, la 
> CPU!), y eso es lo que la hace, si no hay un fallo imperdonable en el 
> núcleo del S.O., inexpugnable totalmente.  La tabla de procesos de que 
> hablo es la GDT y la LDT, que se encuentra en memoria en segmentos 
> privilegiados y lugar desconocido -y cambiante- ...y que sólo

No, eso son (en terminología Intel) las tablas que se utilizan para gestionar la memoria virtual. La tabla donde está lo que se conoce en los libros de texto de "sistemas operativos" como PCB (Bloque de control de proceso). O sea, esto: http://en.wikipedia.org/wiki/Process_control_block

Y estoy usando terminología abstracta deliberadamente.

>  accede el sistema operativo de forma totalmente exclusiva.  Ni usuario, ni superusuario pueden cambiar nada de esta tabla, porque se lo impide la CPU (ni Windows ni Linux tienen nada que decir aquí más allá de haber implementado correctamente un protocolo más que trillado).

Estoy hablando de la tabla donde el sistema operativo pone cosas como "este proceso pertenece al usuario pepito, arrancó tal día, lleva ejecutándose no se cuánto tiempo de CPU y bla, bla". O sea, la tabla de procesos, no de memoria virtual. 

> Si se pudiera modificar esta tabla sería por un bug gigantesco o error intencionado de los programadores del S.O, acompañado de un chivatazo de algún programador del sistema descontento (o bien un fallo no menos escandaloso en la CPU).   No tiene nada que ver con ser superusuario.  De hecho, es 

Es de lo que estoy hablando, de sabotaje deliberado en el microcódigo, por decirlo de alguna manera.

> más que posible que este bug hipotético fuese perfectamente explotable seas superusuario o no.  Y el error sería imperdonable primero porque la parte de un sistema operativo que se ejecuta a nivel máximo de privilegio suele ser pequeña y muy acotada (y por tanto, fácil de proteger), y segundo porque es algo que está resuelto y blindado desde hace más de tres décadas.  

O no, depende del sistema en cuestión.

> Si fueras superusuario (legalmente o por trampas), seguirías siendo un 
> proceso de nivel de privilegio bajo (3 en Intel) para la CPU.  Si aún 
> así consiguieras ejecutarte (por alguna negra técnica y un escandaloso 
> error en el S.O.) en nivel 0, lo único que conseguirías es tener toda 
> la CPU disponible

La CPU no te puede hacer superusuario. Son niveles de abstracción muy diferentes. Lo que sí puede hacer es permitirte manipular la tabla de PCBs del sistema operativo, lo que entre otras cosas puede hacer que te hagas superusuario. ¿Qué objeto crees que han tenido algunos ataques contra, por ejemplo, el kernel de Linux? Pues eso, manipular estructuras de datos del sistema.

> para tí...que tampoco es mucho dado a que es como estaban el 99% de los ordenadores personales -y no tan personales- antes del fin del siglo pasado y tampoco se terminó el mundo.  A partir de allí, podrías hacer muchas cosas, pero en lo que se refiere a nivel de acceso archivos o demás posiblemente nada que no hubieras podido hacer sin reventar la seguridad del procesador.  Porque la seguridad de las tablas de usuarios y el acceso a ciertos archivos del sistema está por otros lados.

Por eso necesitas el primer empujón del procesador. De ahí que esté teorizando sobre la utilidad de un microcódigo malicioso como primer elemento de una "puerta trasera".

> Además, la implementación de estas tripas del sistema no forma parte de la especificación de nada.   Cada cual la implementa como quiere, y puede perfectamente cambiar entre versiones porque es algo total y absolutamente interno.  Por ello es inviable establecer ninguna técnica de ataque perdurable más allá de una versión (o ni eso).

La implementación de las tripas de ese tipo en cualquier Unix es algo trivial de conseguir, documentadísimo y parametrizable además. Todos contienen una tabla con la lista de símbolos que te permite leer los PCBs, las tablas de descriptores de archivos, conexiones de red, etc, etc.

Mira las páginas de manual de kvm(3) o sysctl(3) en FreeBSD, por poner un ejemplo. Es muy fácil obtener las direcciones de memoria donde están esas tablas. Quizás en sistemas no Unix es más complicado, no lo he mirado.  En los Unix es habitual tener acceso a una tabla de símbolos, etc.

Sobre versiones y demás, ¿qué crees exactamente que hacen los miles de "exploits" que se emplean? Pues eso, atacar determinada versión con determinada configuración. Algunos son muy específicos, otros lo son menos.

Pero en fin, que estoy describiendo un escenario teórico. Desde luego, posible es. :)

Borja.

_______________________________________________
Escepticos mailing list
Escepticos en dis.ulpgc.es
http://correo.dis.ulpgc.es/mailman/listinfo/escepticos