Control de cuentas de usuario
Estudio del Control de cuentas de usuario de Windows 7
Mark Russinovich
Resumen:
- Cuentas de usuario estándar
- Control de cuenta de usuario
Contenido
Tecnologías UAC
Elevaciones y seguridad contra malware
Cuál es la diferencia con Windows 7
Autoelevación
Autoelevación y los objetivos de UAC
Las cuentas de usuario estándar ofrecen una mejor seguridad y un costo total de propiedad inferior en los entornos doméstico y corporativo. Cuando los usuarios trabajan con derechos de usuario estándar en lugar de derechos administrativos, la configuración de seguridad del sistema está protegida, incluido el antivirus y el firewall. Esto ofrece a los usuarios una zona segura que puede proteger su cuenta y el resto del sistema. En el caso de las implementaciones empresariales, no se pueden reemplazar las directivas establecidas por los administradores de TI de escritorio y, en un equipo familiar compartido, las distintas cuentas de usuario están protegidas contra los cambios hechos por otras cuentas.
Sin embargo, Windows tiene un largo historial de usuarios que trabajan con derechos administrativos. Como consecuencia, a menudo se ha desarrollado software para ejecutarse en cuentas administrativas y aceptar dependencias, con frecuencia involuntariamente, de los derechos administrativos. A fin de habilitar más software para que se ejecute con derechos de usuario estándar y para ayudar a los programadores a escribir aplicaciones que se ejecuten correctamente con estos derechos, Windows Vista incorporó el Control de cuentas de usuario (UAC). UAC es una recopilación de tecnologías que incluye virtualización del sistema de archivos y del registro, cuenta de administrador protegido (PA), petición de elevación de UAC y niveles de integridad de Windows compatibles con estos objetivos. Me referí a ellos en detalle en mis presentaciones de conferencia y en el artículo de TechNet MagazineUAC internos.
Windows 7 sigue adelante con los objetivos de UAC con las tecnologías subyacentes relativamente intactas. Sin embargo, sí incorpora dos nuevos modos en que la cuenta PA de UAC puede operar con un mecanismo de autoelevación para algunos componentes integrados de Windows. En esta entrada, trataré las motivaciones detrás de las tecnologías de UAC, revisaré la relación entre UAC y seguridad, describiré los dos nuevos modos y explicaré cómo funciona exactamente la autoelevación. Tenga en cuenta que la información de esta entrada refleja el comportamiento del candidato de versión comercial de Windows 7, que difiere de varias maneras de la versión beta.
Tecnologías de UAC
El elemento más básico y el beneficio directo de la tecnología UAC es simplemente hacer que Windows sea más fácil de usar de manera estándar. El ejemplo de presentación es la diferencia entre los requisitos de privilegios de configurar la zona horaria en Windows XP y Windows Vista. En Windows XP, cambiar la zona horaria, de hecho, incluso ver la zona horaria con el applet de fecha y hora del Panel de control requiere derechos administrativos.
Eso se debe a que Windows XP no distingue entre cambiar la hora, que es una operación de seguridad del sistema, y cambiar la zona horaria, que solamente afecta la forma en que se muestra la hora. En Windows Vista (y Windows 7), cambiar la zona horaria no es una operación administrativa y el applet de fecha y hora del Panel de control separa las operaciones administrativas de las operaciones de usuario estándar. Este cambio de por sí permite a muchas empresas configurar usuarios de viaje con cuentas de usuario estándar, gracias a que los usuarios pueden ajustar la zona horaria para reflejar su ubicación actual. Windows 7 va más allá, posibilitando acciones como actualizar la dirección IP del sistema, usar Windows Update para instalar actualizaciones opcionales y controladores, cambiar los PPP de pantalla y ver la configuración actual de firewall disponible para los usuarios estándar.
La virtualización del sistema de archivos y del registro, funcionan en segundo plano para ayudar a muchas aplicaciones que inadvertidamente usan los derechos administrativos a que se ejecuten correctamente sin ellos. Los usos innecesarios más comunes de los derechos administrativos son el almacenamiento de configuraciones de aplicaciones o datos de usuario en áreas del registro o el sistema de archivos que se son para uso del sistema. Algunas aplicaciones heredadas almacenan sus configuraciones en la parte dedicada al sistema del registro (HKEY_LOCAL_MACHINE\Software) en lugar de la parte por usuario (HKEY_CURRENT_USER\Software), por ejemplo, y la virtualización del registro desvía los intentos de escritura en la ubicación del sistema a una ubicación en HKEY_CURRENT_USER (HKCU), a la vez que conserva la compatibilidad de las aplicaciones.
La cuenta PA se diseñó para alentar a los programadores a escribir sus aplicaciones para que exigieran sólo derechos de usuario estándar mientras habilitan a la mayor cantidad de aplicaciones que comparten estado entre componentes administrativos y componentes de usuario estándar para que sigan funcionando. De manera predeterminada, la primera cuenta en un sistema Windows Vista o Windows 7, que era una cuenta de administrador completa en versiones anteriores de Windows, es una cuenta PA. Cualquier programa que ejecute un usuario PA se ejecuta con derechos de usuario estándar, a menos que el usuario eleve explícitamente la aplicación, lo que otorga derechos administrativos a la aplicación. Las peticiones de elevación las desencadenan las actividades del usuario, como instalar aplicaciones y cambiar la configuración del sistema. Estas peticiones de elevación son la tecnología UAC más visible, que se manifiesta como un cambio a una pantalla con un cuadro de diálogo permitir/cancelar y una instantánea en gris del escritorio como fondo.
Las cuentas creadas con posterioridad a la instalación son cuentas de usuario estándar de manera predeterminada que ofrecen la capacidad de elevación mediante una solicitud de “consentimiento temporal” que pide credenciales de una cuenta administrativa que se usarán para otorgar derechos administrativos. Este recurso permite a un familiar que comparte un equipo doméstico o a un usuario más consciente de la seguridad que usa una cuenta de usuario estándar ejecutar aplicaciones con derechos administrativos, siempre que conozca la contraseña de una cuenta administrativa, sin tener que cambiar manualmente a una sesión de inicio de usuario distinta. Algunos ejemplos comunes de estas aplicaciones incluyen instaladores y configuración de control parental.
Cuando UAC está habilitado, todas las cuentas de usuarios, incluidas las cuentas administrativas, se ejecutan con derechos de usuario estándar. Esto significa que los programadores de aplicaciones deben considerar el hecho de que su software no tendrá derechos administrativos de manera predeterminada y debe recordarles diseñar su aplicación para que funcione con derechos de usuario estándar. Si la aplicación o partes de su funcionalidad requieren derechos administrativos, puede aprovechar el mecanismo de elevación para permitir al usuario desbloquear esa funcionalidad. Por lo general, los programadores de aplicaciones sólo deben hacer cambios menores a sus aplicaciones para que funcionen bien con derechos de usuario estándar. Como lo indica la entrada de blog de E7 blog sobre UAC, UAC está cambiando satisfactoriamente la forma en que los programadores escriben software.
Las peticiones de elevación también ofrecen el beneficio de que “notifican” al usuario cuando el software desea hacer cambios en el sistema y dan al usuario la oportunidad de evitarla. Por ejemplo, si un paquete de software en el que el usuario no confía o no desea permitir que modifique el sistema pide derechos administrativos, puede rechazar la petición.
Elevaciones y seguridad contra malware
El objetivo principal de UAC es permitir que más usuarios trabajen con derechos de usuario estándar. Sin embargo, una de las tecnologías de UAC se parece mucho a una característica de seguridad: la petición de consentimiento. Muchas personas creen que el hecho de que el software debe pedir al usuario que otorgue derechos administrativos significa que puede evitar que el malware obtenga derechos administrativos. Además de la implicación visual de que una solicitud es una puerta de enlace a derechos administrativos sólo para la operación que describe, el cambio a un escritorio distinto para el cuadro de diálogo de elevación y el uso del mecanismo de integridad de Windows, incluido el Aislamiento de privilegios en interfaz de usuario (UIPI), parecen respaldar esa creencia.
Como hemos indicado desde antes del lanzamiento de Windows Vista, el propósito principal de las elevaciones no es la seguridad, a pesar de su conveniencia: si los usuarios tenían que cambiar de cuentas para realizar operaciones administrativas, iniciando sesión o mediante Cambio rápido de usuario a una cuenta administrativa, la mayoría de los usuarios cambiarían una vez sin tener que volver a cambiar. No habría progreso al cambiar el entorno para el que diseñan los programadores de esa aplicación. Entonces, ¿cuál es la función del escritorio seguro y el mecanismo de integridad de Windows?
El motivo principal para el cambio a un escritorio distinto para la solicitud es que el software de usuario estándar no puede "suplantar la identidad" de la petición de elevación, por ejemplo, al dibujar sobre el nombre del editor en el cuadro de diálogo para engañar a un usuario haciéndole creer que Microsoft u otro proveedor de software genera la solicitud en lugar de él. El escritorio alternativo recibe el nombre de "escritorio seguro", porque es propiedad del sistema en lugar del usuario, al igual que el escritorio en el que el sistema muestra el cuadro de diálogo de inicio de sesión de Windows.
El uso de otro escritorio también tiene un fin importante para la compatibilidad de aplicaciones: mientras que el software de accesibilidad integrado, como el teclado en pantalla, funciona bien en un escritorio que ejecuta aplicaciones de propiedad de distintos usuarios, no es el caso de algunos software de terceros. Ese software no funcionará correctamente cuando un cuadro de diálogo de elevación, que es propiedad de la cuenta del sistema local, aparezca en el escritorio de propiedad de un usuario.
El mecanismo de integridad de Windows y UIPI se diseñaron para crear una barrera de protección en torno a las aplicaciones elevadas. Uno de sus objetivos originales era impedir que los programadores de software usaran medios rápidos y aprovecharan aplicaciones ya elevadas para llevar a cabo tareas administrativas. Una aplicación que se ejecuta con derechos de usuario estándar no puede enviar entradas sintéticas de mouse o teclado a una aplicación elevada para hacer que haga todo lo que desee o inyectar código a una aplicación elevada para realizar operaciones administrativas.
El mecanismo de integridad de Windows y UIPI se usaron en Windows Vista para Internet Explorer de modo protegido, lo que dificulta que el malware infecte una instancia en ejecución de IE para que modifique una configuración de cuenta de usuario, por ejemplo, para configurarse e iniciarse cada vez que el usuario inicia sesión. Aunque un objetivo de diseño preliminar de Windows Vista era usar las elevaciones con el escritorio seguro, mecanismo de integridad de Windows y UIPI para crear una barrera impenetrable (denominada límite de seguridad) entre el software que se ejecuta con derechos de usuario estándar y derechos administrativos, hubo dos razones que impidieron que se alcanzara ese objetivo, el cual se desechó posteriormente: uso y compatibilidad de aplicaciones.
Figura 1 Muestra del nombre del archivo ejecutable.
En primer lugar, considere el cuadro de diálogo en sí. Muestra el nombre y el editor del ejecutable principal al que se le otorgarán derechos administrativos. Por desgracia, aunque mayores cantidades de editores de software firman digitalmente su código, hay algunos que no lo hacen y hay muchas aplicaciones más antiguas que no están firmadas. En el caso del software que no está firmado, el cuadro de diálogo de elevación simplemente muestra el nombre del archivo del ejecutable, que permite al malware que ya se ejecuta en una cuenta de usuario y que está atento a la elevación de un instalador de aplicación Setup.exe sin firmar, por ejemplo, reemplazar el ejecutable con un archivo Setup.exe malintencionado sin que el usuario pueda distinguirlos (consulte la figura 1).
En segundo lugar, el cuadro de diálogo no le indica al usuario cuáles DLL va a cargar el ejecutable cuando se inicie. Si el ejecutable reside en un directorio bajo el control del usuario, el malware que se ejecuta con los derechos estándar del usuario puede reemplazar cualquier DLL asociada en la ubicación que usará el software. Como alternativa, el malware puede usar funcionalidad en paralelo para provocar que el ejecutable cargue versiones malintencionadas de DLL de aplicaciones o del sistema. Además, a menos que un usuario alerta haga clic en el botón de detalles y examine cuidadosamente la ruta del archivo que se indica para elevar el ejecutable, el malware puede copiar el ejecutable en una ubicación de nombre semejante, por ejemplo, \Archivosdeprograma\Proveedor\Aplicación.exe (observe el espacio faltante en lo que debiera ser "Archivos de programa"), desde donde puede controlar cuáles DLL carga la aplicación. En la figura 2, copié un componente del Monitor de red de Microsoft en el directorio creado por el usuario C:\Archivosdeprograma que el usuario puede controlar y lo inicié.
Figura 2 Copia iniciada del componente del Monitor de red de Microsoft.
Por último, en el caso de la compatibilidad de aplicaciones, las aplicaciones elevadas comparten un estado considerable con el entorno de usuario estándar que una aplicación malintencionada podría usar para influir en el comportamiento de una aplicación elevada. El ejemplo más claro de esto es el perfil de registro del usuario, HKEY_CURRENT_USER (HKCU). Es compartido porque los usuarios esperan configuraciones y extensiones que registran como usuario estándar para que funcionen en aplicaciones elevadas. El malware podría usar extensiones de shell registradas en HKCU para que se carguen en aplicaciones elevadas que usan cualquiera de los cuadros de diálogo de exploración de shell, como Abrir archivo y Guardar archivo. Otros tipos de estado también son compartidos, en especial el espacio de nombres de Objeto nombrado de base, en el que las aplicaciones crean sincronización y comparten objetos de memoria. El malware podría aprovecharse de ese uso compartido para secuestrar un objeto de memoria compartido que una aplicación elevada usa, por ejemplo, para poner en riesgo la aplicación y a continuación, el sistema.
En cuanto al mecanismo de integridad de Windows, su eficacia como barrera está limitada por los problemas de elevación que mencioné, pero también tiene limitaciones producidas por la compatibilidad de aplicaciones. En primer lugar, UIPI no impide que las aplicaciones de usuario estándar dibujen en el escritorio, algo que podría usarse para engañar al usuario para que interactúe con aplicaciones elevadas de modo tal que otorgue derechos administrativos al malware. El mecanismo de integridad de Windows tampoco fluye a través de la red. Una aplicación de usuario estándar que se ejecuta en una cuenta PA tendrá acceso a recursos del sistema en un sistema remoto sobre el que esa cuenta PA tiene derechos administrativos. Abordar estas limitaciones tiene importantes ramificaciones para la compatibilidad de aplicaciones. Dicho lo anterior, estamos estudiando permanentemente formas de mejorar la seguridad del sistema, por ejemplo, al mejorar IE de modo protegido, al mismo tiempo que se abordan los problemas de compatibilidad de aplicaciones y se trabaja en estrecha colaboración con los programadores de software.
Entonces, ¿cuánta protección contra malware recibe cuando ejecuta una cuenta PA de Windows Vista con UAC habilitado? Primero, recuerde que para que todo esto tenga sentido, el malware debe ingresar en el sistema y comenzar a ejecutarse en primer lugar. Windows tiene muchas características de defensa en profundidad, que incluyen la Prevención de ejecución de datos (DEP), la Selección aleatoria de carga de espacios de direcciones (ASLR), IE de modo protegido, el filtro de IE 8 SmartScreen y Windows Defender que ayudan a impedir que el malware ingrese en el sistema y se ejecute.
En cuanto a la eventualidad de que el malware de algún modo se las arregle para ingresar en un sistema, gracias a que los autores de malware (como programadores legítimos) suponen que los usuarios trabajan con derechos administrativos, la mayoría del malware no funcionará correctamente. Eso por sí solo podría considerarse un beneficio de seguridad. Sin embargo, el malware que ha ingresado en un sistema y que está diseñado para explotar las oportunidades podría obtener derechos administrativos la primera vez que el usuario eleve, pero el malware ni siquiera necesita esperar una elevación “real” porque puede precipitar una que engañaría incluso a los usuarios más conscientes de la seguridad. He demostrado públicamente cómo el malware puede secuestrar el proceso de elevación en mis presentaciones UAC internos y Límites de seguridad de Windows (la demostración se encuentra en el minuto 1:03 en la charla sobre límites de seguridad). Recuerde, si el malware de hecho comienza a ejecutarse, puede lograr gran parte de las cosas que el malware desea hacer sólo con los derechos de usuario estándar, que incluye configurarse para ejecutarse cada vez que el usuario inicie sesión, robar o eliminar todos los datos del usuario o incluso formar parte de una botnet.
Cuál es la diferencia con Windows 7
Mencioné algunas de las operaciones de Windows 7 que ahora pueden realizar los usuarios estándar, pero como lo explica la entrada de blog de E7 sobre UAC, también reconocimos que podíamos hacer que la experiencia de Windows fuera más grata sin sacrificar los objetivos de UAC. Muchos usuarios se quejaron del hecho de que Windows Vista con frecuencia pide derechos administrativos cuando realiza operaciones comunes de administración del sistema. Es por nuestro propio beneficio, porque es por el beneficio de nuestros clientes hacer que Windows funcione bien en los entornos de usuario estándar. Sin embargo, las peticiones de elevación no nos informan ni alientan a hacerlo, aunque sí obligan a los usuarios a hacer clic una segunda vez a través de un cuadro de diálogo que la amplia mayoría de los usuarios no lee. Por ende, Windows 7, se propuso reducir al mínimo estas peticiones de la experiencia predeterminada de Windows y permitir a los usuarios que trabajan como administradores controlar su experiencia de peticiones.
Para hacerlo, refactorizamos más el sistema de modo tal que alguien con derechos de usuario estándar pueda ejecutar más tareas y redujimos la cantidad de peticiones en varios escenarios de múltiples peticiones (por ejemplo, instalar un control ActiveX en IE). Windows 7 también incorpora dos nuevos modos de operación de UAC que se pueden seleccionar en un nuevo cuadro de diálogo de configuración de UAC (consulte la figura 3). Puede abrir el cuadro de diálogo en el Panel de control, haciendo clic en Cuentas de usuario, y después en Cambiar configuración de Control de cuentas de usuario. (También puede llegar a él haciendo clic en el vínculo Cambiar cuando aparezcan notificaciones en una petición de elevación o recorriendo el Centro de actividades.)
Figura 3 Dos nuevos modos de operación de UAC que se pueden seleccionar en un nuevo cuadro de diálogo de configuración de UAC.
La configuración predeterminada, que se muestra en la figura 3, es uno de los nuevos niveles. A diferencia de Notificarme siempre, que es la selección en el extremo superior del control deslizante y es idéntica al modo predeterminado de Windows Vista, Windows 7 pregunta al usuario de manera predeterminada sólo cuando un ejecutable que no es de Windows pide una elevación; el comportamiento para elevaciones que no son de Windows es el mismo que había en Windows Vista.
La siguiente posición hacia abajo del control deslizante es la segunda configuración nueva y tiene la misma etiqueta excepto por "(no atenuar el escritorio)" anexado a ella. La única diferencia entre eso y el modo predeterminado es que las peticiones se dan en el escritorio del usuario en lugar del escritorio seguro. El lado positivo es que el usuario puede interactuar con el escritorio mientras una petición está activa, pero como mencioné antes, el riesgo está en que el software de accesibilidad de terceros no funcione correctamente en el cuadro de diálogo de peticiones.
Finalmente, la posición inferior del control deslizante desactiva todas las tecnologías UAC por completo, para que todo el software que se ejecuta en una cuenta PA se ejecute con plenos derechos administrativos, se deshabilita la virtualización del sistema de archivos y del registro, y se deshabilita IE de modo protegido. Aunque no hay peticiones en esta configuración, la pérdida de IE de modo protegido es una desventaja significativa de este modo.
Autoelevación
La razón por la que la elevación de (la mayoría de) los ejecutables de Windows en las dos configuraciones intermedias no originan una petición es que el sistema "autoeleva" los ejecutables de Windows. En primer lugar, ¿qué define Windows como un ejecutable de Windows en este contexto? La respuesta depende de varios factores, pero se deben cumplir dos cosas: debe estar firmado digitalmente por el editor de Windows, que es el certificado que se usa para firmar todo el código que se incluye con Windows (no basta con que esté firmado por Microsoft, de modo que no se incluye el software de Microsoft que no se envía con Windows) y debe estar ubicado en uno de los varios directorios "seguros". Un directorio seguro es uno que los usuarios estándar no pueden modificar e incluyen %SystemRoot%\System32 (por ejemplo, \Windows\System32) y la mayoría de sus subdirectorios, %SystemRoot%\Ehome, además de varios directorios bajo %ProgramFiles% que incluyen Windows Defender y Windows Journal.
Asimismo, según si el ejecutable es un archivo .exe, Mmc.exe o un objeto COM normal, la autoelevación tiene reglas adicionales. Los ejecutables de Windows (como se acaban de definir) de la variedad de archivos .exe se autoelevan si especifican la propiedad autoElevate (autoelevar) en su manifiesto, que es también donde las aplicaciones indican a UAC que desean derechos administrativos. La siguiente es la utilidad Sigcheck de Sysinternals volcando el manifiesto para el Administrador de tareas (Taskmgr.exe) con el comando "sigcheck –m %systemroot%\system32\taskmgr.exe", que muestra que se opta por el Administrador de tareas para la autoelevación, como se muestra en la figura 4.
Figura 4 La propiedad autoelevar
Una manera sencilla de buscar ejecutables de autoelevación en un árbol de directorio es usar la utilidad Strings de Sysinternals con un comando como el siguiente:
strings –s *.exe | findstr /i autoelevate
También hay una lista codificada de forma rígida de los ejecutables de Windows que reciben el tratamiento de autoelevación. Estos ejecutables de Windows también se envían de forma externa a Windows 7 y por ende deben ser capaces de ejecutarse en sistemas de nivel inferior en los que la presencia de la propiedad de autoejecución ocasionaría un error. La lista incluye Migwiz.exe, el asistente de migración, Pkgmgr.exe, el administrador de paquetes y Spinstall.exe, el instalador de Service Pack.
Microsoft Management Console, Mmc.exe, recibe un tratamiento especial ya que contiene a muchos de los complementos de administración del sistema, que se implementan como DLL. Mmc.exe se inicia con una línea de comandos que especifica un archivo .MSC que indica los complementos que MMC debe cargar. Cuando Windows ve que el archivo Mmc.exe pide derechos administrativos, que es lo que hace cuando se inicia desde una cuenta PA, valida que ese archivo Mmc.exe es un ejecutable de Windows y después comprueba el archivo .MSC. Para ser elegible para la autoelevación, el archivo .MSC debe cumplir los criterios de ejecutable de Windows (firmado por Windows en una ubicación segura) y debe indicarse en una lista interna de archivos .MSC de autoelevación. Esa lista incluye prácticamente todos los archivos .MSC enviados con Windows.
Por último, los objetos COM pueden especificar la necesidad de derechos administrativos con un valor del registro en su clave del registro creando una subclave nombrada Elevación con un valor denominado Habilitado configurado en 1. La figura 5 muestra la clave del registro para el objeto del shell Copy/Move/Rename/Delete/Link Object que el Explorador usa cuando un usuario realiza una operación del sistema de archivos en una ubicación para la que su cuenta no tiene permisos.
Figura 5 Clave del registro de shell
Para que un objeto COM sea autoelevado, también debe ser un ejecutable de Windows y un ejecutable de Windows debe haber creado una instancia suya. (No obstante, no es necesario que el ejecutable que crea la instancia esté marcado para la autoelevación.) Cuando use el Explorador para crear un directorio en el directorio %ProgramFiles% de una cuenta PA, por ejemplo, la operación se autoelevará porque el objeto COM solicita la elevación, la DLL del objeto es un ejecutable de Windows y el Explorador es un ejecutable de Windows.
Autoelevación y objetivos de UAC
Entonces, ¿qué hay detrás de todas las reglas de autoelevación especiales? La elección de qué autoelevar y qué no autoelevar era guiada por la pregunta: "¿Puede el programador de una aplicación de forma accidental o trivialmente depender de derechos administrativos aprovechando la autoelevación?". Debido a que el archivo Cmd.exe se puede usar para ejecutar scripts por lotes mediante los argumentos de la línea de comandos y los usuarios promedio no tienen necesidad de ejecutar símbolos del sistema elevados (la mayoría ni siquiera sabe lo que es un símbolo del sistema), no se manifestó para autoelevación. De la misma forma, Rundll32.exe, el ejecutable que contiene complementos del Panel de control, no se autoeleva en la versión final de Windows 7 porque no se exige su elevación para ninguna tarea administrativa común, y si se autoeleva, su capacidad de hospedar DLL mediante su línea de comandos podría provocar que un programador requiera derechos de administrador sin darse cuenta.
Los usuarios finales han estado pidiendo que Windows ofrezca una forma de agregar aplicaciones arbitrarias a la lista de autoelevación desde Windows Vista Beta. La razón que se cita generalmente es que algunas aplicaciones de terceros que usan con frecuencia los obligan a hacer clic constantemente en una petición de elevación como parte de su rutina diaria. Windows 7, al igual que Windows Vista, no ofrece esa capacidad. Comprendemos la exasperación, y podría haber una razón legítima por la que esas aplicaciones no se puedan ejecutar sin derechos administrativos, pero es demasiado alto el riesgo que los programadores eviten arreglar su código para que funcione con derechos de usuario estándar. Incluso si sólo los administradores pudieran acceder a la lista de las aplicaciones que se autoelevan, los programadores sencillamente podrían cambiar el programa de instalación de sus aplicaciones, lo que requiere una elevación de una sola vez, para agregar sus aplicaciones a la lista. En lugar de eso elegimos invertir en educar y trabajar en estrecha colaboración con los programadores de aplicaciones para garantizar que sus programas funcionen correctamente como un usuario estándar.
Varias personas han observado que es posible que software de terceros se ejecute en una cuenta PA con derechos de usuario estándar para aprovechar la autoelevación a fin de obtener derechos administrativos. Por ejemplo, el software puede usar la API WriteProcessMemory para inyectar código en el Explorador y la API CreateRemoteThread para ejecutar ese código, técnica denominada inyección DLL. Debido a que el código se ejecuta en el Explorador, el cual es un ejecutable de Windows, puede aprovechar los objetos COM que se autoelevan, como Copy/Move/Rename/Delete/Link Object, para modificar claves del registro del sistema o directorios y darle derechos administrativos al software. Aunque acertados, estos pasos requieren una intención deliberada, no son accidentales, y por ende, No son algo por lo que creemos que los programadores legítimos optarían frente a arreglar su software para que se ejecute con derechos de usuario estándar. De hecho, nos oponemos a recomendar que un programador de aplicaciones asuma una dependencia del comportamiento de elevación del sistema y que los programadores de aplicaciones prueben su software ejecutándolo en el modo de usuario estándar.
La observación de seguimiento es que el malware podría obtener derechos administrativos aplicando las mismas técnicas. Nuevamente, esto es válido, pero como señalé antes, el malware también puede poner en riesgo el sistema mediante peticiones de elevación. Desde la perspectiva del malware, el modo predeterminado de Windows 7 no es ni más ni menos seguro que el modo Notificarme siempre ("modo Vista"), y el malware que asume derechos administrativos de todas maneras fallará cuando se ejecute en el modo predeterminado de Windows 7.
Conclusión
En resumen, UAC es un conjunto de tecnologías que tiene un objetivo general: hacer posible que los usuarios trabajen como usuarios estándar. La combinación de cambios a Windows que permite a los usuarios estándar realizar más operaciones que antes requerían derechos administrativos, virtualización de archivos y del registro, y peticiones, trabaja de forma conjunta para concretar este objetivo. La conclusión es que el modo UAC predeterminado de Windows 7 hace más grata la experiencia de un usuario de PA al disminuir las peticiones, les permite controlar cuál software legítimo puede modificar su sistema y aún así logra los objetivos de UAC de habilitar a más software para ejecutarse sin derechos administrativos y seguir cambiando el ecosistema de software para escribir software que funcione con derechos de usuario estándar.
Mark Russinovich es empleado técnico de Microsoft en la división de servicios y plataformas.