Sudhakar Govindavajhala y Andrew W. Appel de la Universidad de
Princetown (Nueva York), han publicado un interesante estudio sobre
permisos y control de acceso en sistemas Microsoft Windows. En el
estudio se desmitifica el funcionamiento del sistema operativo Windows a
la hora de controlar el acceso a sus recursos y se explica cómo algunos
comportamientos han provocado vulnerabilidades no sólo en el sistema
operativo, sino en conocidos programas comerciales.

Estos investigadores han usado la programación lógica para implementar
lo que han llamado MulVAL (Multihost, Multistage, Vulnerability
Analysis) una herramienta que han utilizado para analizar profundamente
el control de acceso de los sistemas Windows XP. Mediante la información
recopilada desde distintas fuentes del sistema (el registro, sistema de
ficheros…) el modelo implementado elabora una especie de «mapa» por el
que se revelan varias posibles fórmulas y distintas vías de ataque,
todas destinadas a elevar los privilegios de un usuario local en el
sistema. Con esta herramienta, entre otras, se han encontrado hasta 20
formas distintas de escalar privilegios desde cuentas del grupo
«usuarios avanzados» a administradores. Aunque los usuarios avanzados
poseen bastantes privilegios sobre la máquina, no llegan a los totales
poderes del administrador.

En el estudio se habla también de forma clara y sencilla sobre los
potenciales peligros de la implementación incorrecta de las listas de
control de acceso a los objetos Windows y se plantean fórmulas por las
que se puede llevar a un usuario del sistema a poder ejecutar cualquier
tipo de código con los permisos del administrador o de cuentas
reservadas del sistema con altos privilegios.

Si Unix tiene un modelo simple de control de acceso basado en tres
privilegios (además del bit UID) que se dan a distintos objetos del
sistema (ficheros, directorios…), el sistema de Windows es mucho más
complejo. Se arrastra una lista de control de acceso de hasta 30
permisos diferentes para operaciones sobre unos 15 tipos distintos de
objetos, todo ello con la posibilidad de negar o permitir explícitamente
el privilegio. Esto permite afinar en extremo los permisos, pero también
puede suponer un verdadero galimatías para un administrador o para un
programador que quiera desarrollar una herramienta que interactúe con
los objetos del sistema, pues deben documentarse profusamente y
comprender la compleja estructura de permisos.

Aunque los permisos en Windows están bien documentados y detallados,
resulta muy común observar cómo los creadores de software profesionales
a menudo no evalúan correctamente el impacto que puede llegar a tener la
instalación de su programa en un sistema sin haber afinado correctamente
los permisos que han elegido para sus aplicaciones. La consecuencia es
que mucho software comercial puede llevar a la elevación de privilegios
por parte de usuarios en sistemas compartidos, y de hecho ya se han dado
casos concretos.

Hace poco, a principios de febrero de 2006, se han identificado errores
de permisos en ficheros y directorios en varios productos Adobe tales
como Adobe Photoshop CS2, Illustrator CS2, y Adobe Help Center. El grupo
«Todos» tenía permiso de escritura en 170 archivos (ejecutables y
librerías) de productos Adobe. Un atacante podría sustituirlos por
código malicioso en local y esperar a que el administrador los ejecutara
para poder arrancar ese código con mayores privilegios. La configuración
estándar de AOL, entre otros, también permitía a un usuario invitado
ejecutar código con los permisos de cualquier otro usuario (incluso los
de «Local System»), simplemente manipulando claves de registro. Los
permisos de las ramas de registro, según apunta el estudio, pueden
suponer también habitualmente un problema de seguridad.

La herramienta que desarrollaron estos investigadores ha ayudado a
descubrir muchos problemas de permisos tanto en software comercial como
en componentes del sistema. El caso de los servicios es especialmente
significativo. Al existir tantas formas y combinaciones posibles de
permisos, los desarrolladores optan por distintas vías (por no existir
una convención única) para implementar la funcionalidad de un servicio
propio que correrá en sistemas Windows. Cada servicio tiene un
descriptor de seguridad que especifica a qué usuarios se les permite
configurar o arrancar o parar un servicio. Algunos fabricantes no
aplican correctamente el modelo de control de acceso de Windows en sus
servicios y por ejemplo, otorgan indiscriminadamente el permiso «SERVICE
CHANGE CONFIG» que permite modificar el ejecutable ligado al servicio.
Microsoft recomienda que este permiso sea sólo dado a los
administradores, pero en su documentación no avisa explícitamente de que
este permiso también permite no sólo modificar el ejecutable sino
especificar quién lo hará, de forma que si, a través de cualquier
programa instalado se posee este privilegio, se puede ejecutar
potencialmente cualquier fichero bajo cualquier cuenta del sistema.

Por ejemplo, el grupo «Todos» tenía este permiso de configuración
activado en el servicio «Macromedia Licensing Service» que instalaban
varios productos de Macromedia. Afortunadamente este problema fue
solucionado en junio de 2005. Existen otros agujeros menos graves en
servicios de fabricantes ajenos a Microsoft, pero en el estudio no se
dan detalles a la espera de que puedan ser solventados.

No sólo a través de servicios de terceros es posible elevar privilegios.
Por ejemplo, según el estudio, varios servicios de Windows XP, tales
como «Servicio de descubrimientos SSDP» y «Host de dispositivo Plug and
Play universal» tenían hasta hace poco ese privilegio («SERVICE CHANGE
CONFIG») activado por defecto para el grupo «Usuarios Autenticados».
Cualquier usuario con cuenta en el sistema pertenece a ese grupo, por lo
que potencialmente cualquier usuario podía modificar el ejecutable que
arrancaba estos servicios y la cuenta bajo la que iba a ejecutarse. Se
permitía así, indirectamente, la instalación de un troyano o software
dañino modificando la configuración del servicio y esperando a que fuese
reiniciado. Esto fue solucionado por Microsoft en agosto de 2004, aunque
el peligro estaba presente desde casi dos años antes. Otros servicios
del sistema se descubrieron vulnerables y también fueron parcheados
posteriormente.

El problema se basa en que las aplicaciones que instalamos necesitan
normalmente muchos menos privilegios de los que realmente poseen para
acceder a los datos con los que operan. Encontrar el conjunto de
permisos estrictamente necesarios para que funcione una aplicación bajo
condiciones lo más asépticas posibles de seguridad, es objeto de otro
estudio liderado en 2005 por Shuo Chen, y titulado «A black-box tracing
technique to identify causes of least-privilege incompatibilities». En
él se explica una técnica para encontrar en los programas los m&iacu
te;nimos
privilegios posibles y necesarios que le son necesarios para funcionar.

En definitiva, con la herramienta desarrollada por Sudhakar
Govindavajhala y Andrew W. Appel, se permite facilitar la tarea del
estudio de los controles de acceso a sistemas Windows, algo, como se ha
visto, delicado. Como la herramienta puede considerarse potencialmente
peligrosa, no se ha hecho pública, aunque sí se recomienda a los
administradores usar herramientas análogas de estudio y modificación de
permisos, tales como SubInACL de Microsoft, y estudiar con ellas
cuidadosamente los permisos de los ficheros y objetos del sistema.

Tanto en entornos domésticos como corporativos, gran parte de los
problemas de seguridad de Windows vienen por el hecho de usar el sistema
en modo administrador. Entender los permisos y controles de acceso es
fundamental para limitar el impacto de los fallos de seguridad del
software, pero parece ser que Microsoft, en este sentido, no termina de
entenderse con los usuarios ni con los programadores de aplicaciones. No
hay razón para pensar que los desarrolladores de Adobe, Macromedia o AOL
han sido los únicos que han cometido errores y es seguro que otros
fallarán en los mismos términos. Estudios como los expuestos demuestran
que un cambio de rumbo y una mayor concienciación por ambas partes en
este sentido haría de Windows un sistema operativo más seguro.
Microsoft Windows y el control de acceso, al desnudo