Administración de Windows

En el kernel de Windows Vista: Parte 3

Mark Russinovich

 

Resumen:

• Confiabilidad
• Recuperación
• Seguridad

En esta serie hemos tratado hasta ahora las mejoras del kernel de Windows Vista relacionadas con los procesos, E/S, administración de la memoria, inicio del sistema, apagado y administración de la energía. En esta tercera y última

entrega, me centro en las características y mejoras de las áreas de confiabilidad, recuperación y seguridad.

Una característica de la que no me ocupo en esta serie es el control de cuenta de usuario (UAC), que comprende varias tecnologías distintas, como la virtualización del sistema de archivos y el Registro para aplicaciones heredadas, el consentimiento de elevación para tener acceso a los derechos administrativos, y el mecanismo del nivel de integridad de Windows® para aislar los procesos que se ejecutan con derechos administrativos desde procesos con menos privilegios ejecutados en la misma cuenta. Busque una explicación exhaustiva de los elementos internos del UAC en un futuro número de TechNet Magazine.

Windows Vista™ aumenta la confiabilidad del sistema y su capacidad de diagnosticar problemas del sistema y las aplicaciones mediante varias características y mejoras nuevas. Por ejemplo, el registro de eventos de seguimiento de kernel para Windows (ETW) está siempre activo y genera eventos de seguimiento para actividades de archivo, de Registro, de interrupción y de otros tipos en un búfer circular. Cuándo surge un problema, la nueva Infraestructura de diagnóstico de Windows (WDI) puede capturar una instantánea del búfer y analizarlo de forma local o cargarlo en el servicio de soporte técnico de Microsoft para solucionar dicho problema.

El nuevo Monitor de rendimiento y confiabilidad de Windows ayuda a los usuarios a relacionar los errores, por ejemplo, los bloqueos e interrupciones, con los cambios realizados en la configuración del sistema. La eficaz Herramienta de reparación del sistema (SRT) reemplaza a la consola de recuperación para la recuperación sin conexión de los sistemas que no se pueden iniciar.

Hay tres áreas que dependen de los cambios del sistema en el nivel del kernel y que merecen un estudio más detallado en este artículo: Administrador de transacciones de kernel (KTM), un tratamiento mejorado de los bloqueos y versiones anteriores.

Administrador de transacciones de kernel

Uno de los aspectos más tediosos del desarrollo de software es el control de las condiciones de error. Esto sucede sobre todo si en el curso de una operación de alto nivel, una aplicación ha completado una o más subtareas que generan cambios en el sistema de archivos o el Registro. Por ejemplo, un servicio de actualización de software de una aplicación podría realizar varias actualizaciones del Registro, reemplazar uno de los archivos ejecutables de la aplicación y, más adelante, recibir una denegación de acceso al tratar de actualizar un segundo ejecutable. Si el servicio no desea dejar la aplicación en un estado de inestabilidad, debe realizar el seguimiento de todos los cambios que realiza y estar dispuesto a deshacerlos. Probar el código de recuperación de errores es difícil y, en consecuencia, a menudo se omite, pues los errores del código de recuperación pueden hacer que no valga la pena.

Las aplicaciones escritas para Windows Vista pueden, con muy poco esfuerzo, obtener capacidades de recuperación automática de errores mediante la nueva compatibilidad transaccional en NTFS y el Registro con el Administrador de transacciones de kernel. Si una aplicación desea hacer varios cambios relacionados, puede crear una transacción del Coordinador de transacciones distribuidas (DTC) y un identificador de transacción de KTM, o bien crear un identificador de KTM directamente y asociar las modificaciones de los archivos y claves del Registro a la transacción. Si todos los cambios se realizan correctamente, la aplicación confirma la transacción y se aplican los cambios, pero en cualquier momento hasta ese punto la aplicación puede revertir la transacción y entonces se descartan los cambios.

Otra ventaja es que las demás aplicaciones no ven los cambios realizados en una transacción hasta que ésta se confirma, y las aplicaciones que usan el DTC de Windows Vista y el próximo Windows Server®, denominado por el momento "Longhorn", pueden coordinar sus transacciones con SQL Server™, Microsoft® Message Queue Server (MSMQ) y otras bases de datos. Por lo tanto, un servicio de actualización de aplicaciones que utilice transacciones de KTM no dejará nunca una aplicación en un estado de inestabilidad. Ésa es la razón por la que tanto Windows Update como la característica Restaurar sistema usan transacciones.

KTM, como esencia de la compatibilidad transaccional, permite que los administradores de recursos de transacciones como NTFS y el Registro coordinen sus actualizaciones para un conjunto concreto de cambios realizados por una aplicación. En Windows Vista, NTFS usa una extensión para proporcionar compatibilidad con transacciones denominadas TxF. El Registro usa una extensión parecida denominada TxR. Estos administradores de recursos del modo de kernel funcionan conjuntamente con el KTM para coordinar el estado de la transacción, de la misma forma que los administradores de recursos del modo de usuario usan DTC para coordinar el estado de la transacción a través de varios administradores de recursos del modo de usuario. Las aplicaciones de otros fabricantes también pueden usar KTM para implementar sus propios administradores de recursos.

TxF y TxR definen un conjunto nuevo de API del sistema de archivos y del Registro que se parecen a las existentes, salvo que incluyen un parámetro de transacción. Si una aplicación desea crear un archivo en una transacción, primero usa KTM para crear la transacción y, a continuación, pasa el identificador de transacción resultante a la API de creación del nuevo archivo.

TxF y TxR dependen de la funcionalidad de registro del sistema de archivos de alta velocidad del Sistema de archivos de registro comunes o CLFS (%Sys­tem­Root%\System32\Clfs.sys) introducido en Windows Server 2003 R2. TxR y TxF usan CLFS para almacenar permanentemente los cambios de estado transaccionales antes de que confirmen una transacción. De este modo pueden ofrecer recuperación transaccional y garantías incluso si se produce una interrupción del suministro eléctrico. Además del registro de CLFS, TxR crea un conjunto de archivos de registro relacionados para realizar el seguimiento de los cambios de las transacciones del archivo del Registro del sistema en %Systemroot%\System32\Config\Txr, como se muestra en la Figura 1, además de conjuntos independientes de archivos de registro para cada subárbol del Registro de usuarios. TxF almacena los datos transaccionales de cada volumen en un directorio oculto en el volumen denominado \$Ex­tend\$RmMetadata.

Figura 1** Archivos de registro TxR del subárbol del Registro del sistema  **(Hacer clic en la imagen para ampliarla)

Compatibilidad mejorada con los bloqueos

Si Windows encuentra un error irrecuperable del modo de kernel (debido a un error de controlador de dispositivo, a un hardware defectuoso o al sistema operativo), trata de evitar que se dañen los datos del disco mediante la detención del sistema después de mostrar la característica pantalla azul de error y (si se ha configurado así) mediante la escritura del contenido de la memoria física, o de parte de ella, en un archivo de volcado. Los archivos de volcado son útiles porque al reiniciar el equipo después de un bloqueo, el servicio Online Crash Analysis de (OCA) Microsoft puede analizarlos para buscar la causa raíz. Si lo desea, también los puede analizar usted mismo con las herramientas de depuración de Microsoft para Windows.

En versiones anteriores de Windows, sin embargo, la compatibilidad con archivos de volcado no se habilitaba hasta que el proceso Administrador de sesión (%Systemroot%\Sys­tem32\Smss.exe) empezaba a paginar los archivos. Esto significaba que los errores graves que se producían antes de ese momento generaban una pantalla azul, pero ningún archivo de volcado. Puesto que la mayor parte de la inicialización de los controladores de dispositivo tiene lugar antes de que se inicie Smss.exe, los bloqueos tempranos nunca ocasionan archivos de volcado y el diagnóstico de las causas resulta muy difícil.

En Windows Vista se reduce el periodo de tiempo en que no se genera archivo de volcado, mediante la inicialización de la compatibilidad con archivos de volcado una vez que se han inicializado todos los controladores de dispositivo de inicio, pero antes de cargar los controladores de inicio del sistema. Como consecuencia de este cambio, si experimenta un bloqueo durante la primera parte del proceso de inicio, el sistema puede capturar un archivo de volcado, lo que le permite usar OCA para resolver el problema. Además, Windows Vista guarda los datos en un archivo de volcado en bloques de 64 KB, mientras que las versiones anteriores de Windows los escribían en bloques de 4 KB. Este cambio hace que los archivos de volcado de gran tamaño se escriban con una velocidad 10 veces mayor.

El manejo de los bloqueos de aplicaciones también se ha mejorado en Windows Vista. En versiones anteriores de Windows, cuando una aplicación se bloqueaba, se ejecutaba un controlador de excepción no controlado. El controlador iniciaba el proceso Informe de errores de aplicaciones (AER) de Microsoft (%Systemroot%\System32\Dwwin.exe) para mostrar un cuadro de diálogo que indicaba que el programa se había bloqueado y preguntaba si se deseaba enviar un informe del error a Microsoft. Sin embargo, si la pila del subproceso principal del proceso se dañaba durante el bloqueo, el controlador de excepción no controlado se bloqueaba al ejecutarse, lo que hacía que el kernel finalizara el proceso, desaparecieran las ventanas del programa, y no se mostrara el cuadro de diálogo de informe de errores.

Windows Vista saca el manejo de errores fuera del contexto del proceso bloqueo y lo lleva a un servicio nuevo, Informe de errores de Windows (WER). Este servicio se implementa mediante un archivo DLL (%Sys­temroot%\System32\Wersvc.dll) en un proceso de hospedaje de servicios. Cuándo se bloquea una aplicación, se sigue ejecutando un controlador de excepción no controlado, pero el controlador envía un mensaje al servicio WER, que inicia el proceso Informe de errores WER (%Systemroot%\System32\Werfault.exe) para mostrar el cuadro de diálogo de informe de errores. Si se daña la pila y se bloquea el controlador de excepción no controlado, el controlador se vuelve a ejecutar y se vuelve a bloquear, hasta que se consume toda la pila del subproceso (área de trabajo de la memoria), momento en que interviene el kernel, que envía el mensaje de notificación del bloqueo al servicio.

Puede ver la diferencia entre estos dos enfoques en las Figuras 2 y 3, que muestran la relación del proceso de Accvio.exe, un programa de prueba que se bloquea, y los procesos de informes de errores resaltados en verde, en Windows XP y Windows Vista. La nueva arquitectura de control de errores de Windows Vista significa que los programas ya no se cierran silenciosamente, sin ofrecer la oportunidad de que Microsoft obtenga un informe del error y los desarrolladores de software puedan mejorar las aplicaciones.

Figura 2a** Control de errores de aplicaciones en Windows XP **(Hacer clic en la imagen para ampliarla)

Figura 2b(Hacer clic en la imagen para ampliarla)

Figura 3a** Control de errores de aplicaciones en Windows Vista **(Hacer clic en la imagen para ampliarla)

Figura 3b

Instantáneas de volumen

Windows XP introdujo una tecnología denominada Instantáneas de volumen para crear instantáneas de un momento dado de los volúmenes de disco. Las aplicaciones de copia de seguridad pueden usar estas instantáneas para crear imágenes de copia de seguridad coherentes, pero aparte de eso, las instantáneas quedan ocultas a la vista y se conservan sólo durante el proceso de copia de seguridad.

Las instantáneas no son en realidad copias completas de los volúmenes. Son más bien vistas de un volumen de un momento anterior que comprenden los datos reales del volumen que tienen superpuestas copias de los sectores del volumen que han cambiado desde que se tomó la instantánea. El controlador del Proveedor de instantáneas de volumen (%Systemroot\%System32\Drivers\Volsnap.sys) supervisa las operaciones dirigidas a los volúmenes y crea copias de seguridad de los sectores antes de permitir que cambien; almacena los datos originales en un archivo asociado a la instantánea en el directorio de Información de volumen del sistema del volumen.

Windows Server 2003 mostraba la administración de instantáneas a los administradores del servidor y a los usuarios de los sistemas cliente con las Instantáneas para carpetas compartidas. Esta característica habilitaba instantáneas persistentes a las que los usuarios podían tener acceso a través de la ficha Versiones anteriores de los cuadros de diálogo Propiedades del Explorador para sus carpetas y archivos ubicados en los recursos compartidos de archivos del servidor.

La característica Versiones anteriores de Windows Vista proporciona esta compatibilidad a todos los sistemas cliente, creando automáticamente instantáneas de volumen, por lo general una vez al día, a las que se puede tener acceso desde los cuadros de diálogo de propiedades del Explorador, con la misma interfaz usada en Instantáneas para carpetas compartidas. Esto permite ver, restaurar o copiar versiones anteriores de los archivos y directorios que se pueden haber modificado o eliminado accidentalmente. Si bien no se trata de una tecnología nueva, la implementación de Versiones anteriores de Windows Vista de Instantáneas de volumen optimiza la de Windows Server 2003 para el uso en entornos de escritorio de cliente.

Windows Vista aprovecha también la ventaja de las instantáneas de volumen para unificar los mecanismos de protección de datos del usuario y del sistema y evitar que se guarden datos redundantes de copia de seguridad. Si un cambio de la instalación o la configuración de una aplicación causa comportamientos incorrectos o no deseados, puede usar Restaurar sistema, una característica de los sistemas operativos Windows NT® introducida en Windows XP para restaurar archivos del sistema y datos a su estado en el momento que se creó un punto de restauración.

En Windows XP, Restaurar sistema usa un controlador de filtro del sistema de archivos (un tipo de controlador que puede ver los cambios en el nivel de archivo) para hacer copias de seguridad de archivos del sistema en el momento en que cambian. En Windows Vista, Restaurar sistema usa instantáneas de volumen. Si se usa la interfaz de usuario de Restaurar sistema en Windows Vista para volver a un punto de restauración, en realidad se están copiando en el volumen en funcionamiento versiones anteriores de archivos del sistema modificados de la instantánea asociada al punto de restauración.

BitLocker

Windows Vista es la versión más segura de Windows que existe. Además de contar con el motor anti spyware Windows Defender, Windows Vista introduce numerosas características de seguridad y defensa, como el cifrado de volumen completo de BitLocker™, la firma digital de código para el código del modo de kernel, los procesos protegidos, la selección aleatoria de carga de espacios de direcciones y las mejoras a la seguridad del servicio de Windows y el Control de cuentas de usuario.

Un sistema operativo sólo puede aplicar sus directivas de seguridad cuando está activo, de modo que es preciso tomar medidas adicionales para proteger los datos cuando la seguridad física de un sistema pueda estar en peligro y sea posible tener acceso a los datos desde fuera del sistema operativo. Los mecanismos basados en hardware, como las contraseñas de BIOS y el cifrado, son dos tecnologías usadas comúnmente para impedir el acceso no autorizado, sobre todo en equipos portátiles, que pueden perderse o ser sustraídos más fácilmente.

Windows 2000 introdujo el Sistema de cifrado de archivos (EFS) y, en su versión de Windows Vista, EFS incluye varias mejoras respecto a las implementaciones anteriores: mejoras de rendimiento, compatibilidad con el cifrado del archivo de paginación y almacenamiento de claves de EFS de usuario en tarjetas inteligentes. Sin embargo, EFS no se puede usar para proteger el acceso a áreas sensibles del sistema, como los archivos del subárbol del Registro. Por ejemplo, si la directiva de grupo le permite iniciar sesión en su equipo portátil aún cuando no esté conectado a un dominio, los verificadores de sus credenciales de dominio se copian en la memoria caché del Registro, de modo que un atacante podría usar herramientas para obtener el hash de su contraseña de cuenta de dominio y usarlo para tratar de obtener su contraseña mediante un buscador de contraseñas. La contraseña proporcionaría acceso a su cuenta y a los archivos EFS (asumiendo que no haya almacenado la clave de EFS en una tarjeta inteligente).

Para que resulte fácil cifrar el todo el volumen de inicio (el volumen con el directorio de Windows), con todos sus archivos del sistema y de datos, Windows Vista introduce una característica de cifrado de todo el volumen denominada Cifrado de unidad BitLocker de Windows. A diferencia de EFS, implementado por el controlador de sistema de archivos NTFS y que funciona en el nivel del archivo, BitLocker cifra en el nivel del volumen mediante el controlador de cifrado de volumen completo (FVE) (%Systemroot%\Sys­tem32\Drivers\Fve­vol.sys) como muestra el diagrama de la Figura 4.

Figura 4** Controlador de filtro de FVE de BitLocker **(Hacer clic en la imagen para ampliarla)

FVE es un controlador de filtro, de forma que ve automáticamente todas las solicitudes de E/S que NTFS envía al volumen, cifrando los bloques mientras se escriben y descifrándolos mientras se leen. Para ello, usa la Clave de cifrado de volumen completo (FVEK) asignada al volumen cuando se configura inicialmente para el uso de BitLocker. De forma predeterminada, los volúmenes se cifran mediante una clave AES de 128 bits y una clave de difusor de 128. Dado que el cifrado y el descifrado tienen lugar por debajo de NTFS en el sistema de E/S, el volumen se muestra a NTFS como si no estuviera cifrado, y no es necesario que NTFS esté informado de que BitLocker está habilitado. Si trata de leer datos del volumen desde el exterior de Windows, parece que los datos son aleatorios.

FVEK se cifra con una clave maestra de volumen (VMK) y se almacena en una región especial de metadatos del volumen. Al configurar BitLocker, existen varias opciones para proteger VMK, en función de las capacidades del hardware del sistema. Si el sistema cuenta con un Módulo de plataforma segura (TPM) que satisface la versión 1.2 de la especificación de TPM y tiene asociada compatibilidad con el BIOS, puede cifrar VMK con TPM, puede hacer que el sistema cifre VMK con una clave almacenada en TPM y otra almacenada en un dispositivo de memoria flash USB, o bien puede cifrar la clave con una clave almacenada en TPM y un PIN que se escribe cuando se inicia el sistema. Para sistemas que no cuentan con TPM, BitLocker ofrece la opción de cifrar VMK con una clave almacenada en un dispositivo externo de memoria flash USB. En cualquier caso, necesitará un volumen sin cifrar del sistema NTFS de 1.5 GB, en el que se guardan el Administrador de inicio y la Base de datos de configuración de inicio (BCD).

La ventaja de usar un TPM es que BitLocker usa las características de TPM para asegurarse de que no descifrará VMK y desbloqueará el volumen de inicio si el BIOS o los archivos de inicio del sistema han cambiado desde que se habilitó BitLocker. La primera vez que se cifra el volumen del sistema, y cada vez que se realicen actualizaciones de cualquiera de los componentes mencionados, BitLocker calcula los valores hash SHA-1 de los componentes y almacena cada hash, denominado medida, en distintos Registros de configuración de la plataforma (PCR) del TPM, con la ayuda del controlador de dispositivo de TPM (%Systemroot%\Sys­tem32\Drivers\Tpm.sys). A continuación, usa TPM para sellar el VMK, operación que usa una clave privada almacenada en TPM para cifrar el VMK y los valores almacenados en PCR junto con otros datos que BitLocker pasa TPM. Después, BitLocker almacena el VMK sellado y FVEK cifrado en la región del metadatos del volumen.

Cuándo se inicia el sistema, mide sus propios valores hash y el código de carga de PCR y escribe el hash en el primer PCR del TPM. A continuación, mide el hash del BIOS y almacena esa medida en el PCR apropiado. El BIOS, a su vez, mide el hash del siguiente componente de la secuencia de inicio, el Registro de inicio maestro (MBR) del volumen de inicio, y este proceso continúa hasta que se mide el cargador del sistema operativo. Cada parte de código subsiguiente que se ejecuta es responsable de medir el código que carga y de almacenar la medida en el registro apropiado del TPM. Por último, cuando el usuario selecciona el sistema operativo que va a iniciar, el Administrador de inicio (Bootmgr) lee el VMK cifrado del volumen y pide a TPM que lo abra. Sólo si todas las medidas son iguales que cuando se selló el VMK, incluso el PIN opcional, el TPM descifrará correctamente el VMK.

Este esquema es como una cadena de comprobación, donde cada componente de la secuencia de inicio describe el componente siguiente al TPM. El TPM sólo revelará su secreto si todas las descripciones que recibe coinciden con las originales. Por lo tanto, BitLocker protege los datos cifrados aún cuando se extraiga el disco y se ponga en otro sistema, el sistema se inicie con otro sistema operativo, o los archivos sin cifrar del volumen de inicio estén en peligro.

Comprobación de la integridad del código

El código malintencionado implementado como controlador de dispositivo del modo de kernel se ejecuta en el mismo nivel de privilegio que el kernel y, por lo tanto, es muy difícil de identificar y quitar. Dicho código puede modificar el comportamiento del kernel y de otros controladores y puede resultar virtualmente invisible. La integridad del código de Windows Vista para la característica de código del modo de kernel, también denominada firma del código del modo Kernel (KMCS), sólo admite la carga de controladores de dispositivo si han sido publicados y firmados digitalmente por desarrolladores sometidos a examen por parte de una entidad de certificación (CA). De manera predeterminada, KMCS se aplica en Windows Vista para los sistemas de 64 bits.

Las entidades de certificación cobran honorarios por sus servicios y realizan comprobaciones básicas sobre los antecedentes, como por ejemplo, la identidad de una empresa; es más difícil producir código malintencionado anónimo del modo de kernel que se pueda ejecutar en Windows Vista de 64 bits. Además, el código malintencionado que consigue colarse por el proceso de comprobación podría dejar indicios que lleven al autor si dicho código se detecta en un sistema en peligro. KMCS tiene usos secundarios: ofrece información de contacto del equipo de análisis de bloqueos en línea de Windows si se sospecha que un controlador contiene un error que bloquea los sistemas de los clientes y desbloquea contenido multimedia de alta definición, lo que describiré en breve.

KMCS usa tecnologías de criptografía de clave pública que se han usado en Windows más de diez años y requiere que el código del modo de kernel contenga una firma digital generada por una entidad de certificación de confianza. Si un publicador envía un controlador al Laboratorio de calidad del hardware de Microsoft Windows (WHQL) y el controlador pasa las pruebas de confiabilidad, Microsoft actúa como la entidad de certificación que firma el código. La mayoría de los publicadores obtendrán las firmas a través del WHQL, pero cuando un controlador no tenga un programa de pruebas del WHQL, el publicador no desee someterse a las pruebas del WHQL, o el controlador sea un controlador de inicio que se carga al principio del inicio del sistema, los publicadores deberán firmar el código ellos mismos. Para hacerlo, primero deben obtener un certificado de firma de código de una de las entidades de certificación que Microsoft haya identificado como de confianza para la firma de código del modo de kernel. A continuación, el autor crea digitalmente el hash del código, firma el hash cifrándolo con una clave privada y adjunta el certificado y el hash cifrado al código.

Cuándo un controlador trata de cargarse, Windows descifra el hash adjunto al código mediante la clave pública almacenada en el certificado y comprueba que el hash coincide con el incluido en el código. La autenticidad del certificado se comprueba de la misma forma, pero se usa la clave pública de la entidad de certificación, que está incluida en Windows.

Windows comprueba también las cadenas del certificado asociado hasta llegar a una de las entidades emisoras raíz incrustadas en el cargador de inicio de Windows y el kernel del sistema operativo. En un sistema de producción no debe haber nunca intentos de cargar un controlador de 64 bits sin firmar, pues a diferencia del Administrador Plug and Play, que muestra un cuadro de diálogo de advertencia si se le indica que cargue un controlador sin una firma digital que confirme que ha pasado las pruebas del WQHL, Windows Vista de 64 bits escribe en modo silencioso un evento en el registro de eventos de aplicación Integridad del código, como el que se muestra en la Figura 5, siempre que bloquea la carga de un controlador sin firmar. Windows Vista de 32 bits comprueba también las firmas digitales de controlador, pero permite que se carguen controladores sin firmar. Su bloqueo interrumpiría los sistemas mejorados de Windows XP que requieren los controladores cargados en Windows XP; además, proporciona compatibilidad con hardware para el que sólo hay controladores de Windows XP. Con todo, Windows Vista de 32 bits también escribe eventos en el registro de eventos de la Integridad del código cuando carga un controlador sin firmar.

Figura 5** Eventos de intento de carga de controlador sin firmar **(Hacer clic en la imagen para ampliarla)

Puesto que la firma de código se usa normalmente para etiquetar código como publicación oficial que ha superado pruebas rigurosas, por lo general los publicadores no desean firmar el código de prueba. Por ello, Windows Vista dispone de un modo de firma de prueba que se puede habilitar y deshabilitar con la herramienta Bcdedit (descrita en mi artículo de TechNet de marzo de 2007), en el que cargará controladores del modo de kernel firmados digitalmente con un certificado de prueba generado por una entidad de certificación interna. Este modo se ha diseñado para que lo utilicen los programadores mientras desarrollan el código. Cuándo Windows se encuentra en este modo, muestra en el escritorio marcadores como el que se muestra en la Figura 6.

Figura 6** Modo de firma de prueba de Windows Vista **

Procesos protegidos

La nueva generación de contenido multimedia, como HD-DVD, BluRay y otros formatos con licencias del Advanced Access Content System (AACS, Sistema de contenido de acceso avanzado), será más habitual en los próximos años. Windows Vista dispone de varias tecnologías, conocidas colectivamente como Ruta de acceso a medios protegida (PMP), que el estándar del AACS exige para que se pueda reproducir este tipo de contenido. PMP incluye el Audio de modo de usuario protegido (PUMA) y Ruta de acceso de vídeo protegida (PVP) que ofrecen mecanismos para los controladores de audio y vídeo, así como aplicaciones de reproductor de medios, para impedir que el software o hardware no autorizados capturen contenido con formato de alta definición.

El PUMA y la PVP definen interfaces y compatibilidad específicas del audio y vídeo, los controladores de dispositivos, y el hardware, pero la PMP depende también de un mecanismo general del kernel introducido en Windows Vista, denominado proceso protegido. Los procesos protegidos se basan en el proceso estándar de Windows que encapsula una imagen ejecutable en ejecución, sus archivos DLL, el contexto de seguridad (cuenta bajo la que se ejecuta el proceso y sus privilegios de seguridad) y los subprocesos que ejecutan código en el proceso, pero impiden ciertos tipos de acceso.

Los procesos estándar implementan un modelo de control de acceso que concede acceso completo al propietario del proceso y a las cuentas administrativas con el privilegio de depuración de programas. El acceso completo permite al usuario ver y modificar el espacio de direcciones del proceso, incluso el código y los datos asignados al proceso. Además, los usuarios también pueden insertar subprocesos en el proceso. Estos tipos de acceso no satisfacen los requisitos de la PMP, porque permitirían al código no autorizado obtener acceso a contenido de alta definición y a claves de la Administración de derechos digitales (DRM) almacenadas en un proceso que reproduce el contenido.

Los procesos protegidos restringen el acceso a un conjunto limitado de interfaces de información y de administración de procesos que incluyen la consulta del nombre de la imagen del proceso y la terminación o suspensión del proceso. El kernel hace que la información de diagnóstico de los procesos protegidos esté disponible a través de funciones generales de consulta del proceso que devuelven datos relativos a todos los procesos de un sistema y, por ello, no requieren acceso directo al proceso. Los accesos que supongan un riesgo para los medios sólo son admitidos por otros procesos protegidos.

Además, para evitar riesgos internos, todo el código ejecutable cargado en un proceso protegido, incluso su imagen y archivos DLL ejecutables, debe estar firmado por Microsoft (WHQL) con un marcador de entorno protegido (PE), o si es un códec de audio, firmado por el desarrollador con un certificado de firma DRM obtenido de Microsoft. Dado que el código del modo de kernel puede obtener acceso completo a todos los procesos, incluidos los protegidos, y Windows de 32 bits admite la carga de código sin firmar del modo de kernel, el kernel ofrece una API para que los procesos protegidos consulten la "limpieza" del entorno del modo de kernel y usen el resultado para desbloquear el contenido principal únicamente si no se carga código sin firmar.

Identificar un proceso protegido

No hay ningunos API que identifiquen específicamente los procesos protegidos, pero se pueden identificar indirectamente en función de la información limitada disponible sobre ellos y la incapacidad de depurarlos incluso desde una cuenta administrativa. El proceso Aislamiento de gráficos de dispositivo de audio (%Systemroot%\System32\Audiodg.exe) se usa para reproducir DVD con codificación de sistema de codificación de contenido (CSS) y se puede identificar como un proceso protegido en el panel de Administrador de tareas por el hecho de que el Administrador de tareas no puede obtener el estado de su línea de comandos, virtualización y prevención de ejecución de datos aunque se ejecute con derechos administrativos.

Administrador de tareas mostrando el proceso protegido(Hacer clic en la imagen para ampliarla)

Selección aleatoria de carga de espacios de direcciones

A pesar de medidas como la prevención de ejecución de datos y la comprobación mejorada de errores del compilador, los autores de código malintencionado siguen descubriendo vulnerabilidades de desbordamiento de búfer que les permiten infectar procesos abiertos a la red como Internet Explorer®, servicios de Windows y aplicaciones de otros fabricantes para introducirse en un sistema. Sin embargo, una vez han logrado infectar un proceso, deben usar API de Windows para lograr su objetivo, leer los datos de usuario o establecer una presencia permanente mediante la modificación de la configuración del usuario o el sistema.

De la conexión a una aplicación con puntos de entrada de API exportados por archivos DLL se ocupa normalmente el cargador del sistema operativo, pero estos tipos de infección de código malintencionado no pueden usar los servicios del cargador. Ello no suponía un problema para el código malintencionado en versiones anteriores de Windows, porque en las distintas versiones de Windows, las imágenes de ejecutables del sistema y los archivos DLL se cargan siempre en la misma ubicación, lo que hace que el código malintencionado asuma que las API residen en direcciones fijas.

La característica Selección aleatoria de carga de espacios de direcciones de Windows Vista (ASLR) impide que el código malintencionado pueda descubrir dónde están las API: para ello, carga los archivos DLL y ejecutables del sistema en una ubicación distinta cada vez que se inicia el sistema. En una fase temprana del proceso de inicio, el Administrador de memoria escoge una referencia aleatoria de carga de la imagen de DLL de una de las 256 direcciones alineadas de 64 KB en la región de 16 MB de la parte superior del espacio de direcciones del modo de usuario. Como los archivos DLL que tienen el nuevo marcador de reubicación dinámica en el encabezado de su imagen se cargan en un proceso, el Administrador de memoria los pone en la memoria, empezando en la dirección de referencia de carga de la imagen y avanzando hacia abajo.

Los archivos ejecutables que tienen el marcador reciben un tratamiento parecido y se cargan en un punto aleatorio alineado de 64 KB dentro de 16 MB de la dirección de carga base almacenada en el encabezado de su imagen. Si un archivo DLL o ejecutable concreto se vuelve a cargar una vez que lo han descargado todos los procesos que lo usan, el Administrador de memoria selecciona otra ubicación aleatoria para cargarlo. En la Figura 7 se muestra un ejemplo de diseño de espacio de direcciones para un sistema de Windows Vista de 32 bits, con las áreas en que ASLR selecciona la referencia de carga de la imagen y la dirección de carga de los archivos ejecutables.

Figura 7** Efecto de ASLR en las direcciones de carga de los archivos ejecutables y DLL **(Hacer clic en la imagen para ampliarla)

Sólo se reubican las imágenes que tienen el marcador de reubicación dinámica, que incluye todos los archivos DLL y ejecutables de Windows Vista, porque si se movieran las imágenes heredadas se podrían destruir suposiciones internas de desarrolladores acerca de donde se cargan sus imágenes. Visual Studio® 2005 SP1 agrega compatibilidad con el establecimiento del marcador de forma que desarrolladores de terceros puedan sacar partido de las ventajas de ASLR.

La carga aleatoria de las direcciones de los archivos DLL en una de 256 ubicaciones no imposibilita que el código malintencionado descubra la ubicación correcta de una API, pero ralentiza en gran medida la velocidad de propagación de un gusano de red e impide que el código malintencionado que sólo tiene una oportunidad para infectar el sistema funcione correctamente. Además, la estrategia de reubicación de ASLR tiene como ventaja secundaria que los paquetes de espacios de direcciones son más compactos que en versiones anteriores de Windows, lo que crea regiones más grandes de memoria libre para asignaciones de memoria contiguas, reduce el número de tablas de página que el Administrador de memoria asigna para realizar el seguimiento del diseño de espacios de direcciones y minimiza los errores del búfer de traducción de direcciones (TLB).

Mejoras de la seguridad de servicios

Los servicios de Windows son el blanco perfecto del código malintencionado. Muchos proporcionan acceso de red a su funcionalidad, lo que podría exponer a un sistema al acceso de forma remota. La mayor parte de ellos se ejecuta con más privilegios que las cuentas de usuario estándar, ofreciendo la oportunidad de elevar los privilegios en un sistema local si se ven sometidos a riesgos por parte de código malintencionado. Por ello, Windows empezó a evolucionar con los cambios realizados en Windows XP SP2, que reducían los privilegios y el acceso asignado a los servicios únicamente a los necesarios para sus funciones. Por ejemplo, Windows XP SP2 introdujo las cuentas de servicio local y de servicio de red, que sólo contienen un subconjunto de los privilegios disponibles para la cuenta donde siempre se ejecutaban previamente los servicios, el sistema local. Así se minimiza el acceso que puede obtener un atacante al aprovechar un servicio.

ASLR en acción

Los efectos de ASLR se pueden ver muy fácilmente, comparando las direcciones de carga de DLL de un proceso en dos sesiones de inicio distintas mediante una herramienta como Explorador de procesos de Sysinternals. En estas dos capturas de pantalla, tomadas en dos sesiones distintas, Ntdll.dll se cargó en el Explorador, primero en la dirección 0x77A30000 y después en la dirección 0x77750000.

Direcciones base distintas para ntdll.dll(Hacer clic en la imagen para ampliarla)

Direcciones base distintas para ntdll.dll(Hacer clic en la imagen para ampliarla)

En mi artículo anterior, describía cómo los servicios se ejecutan aislados de las cuentas de usuario en su propia sesión, pero Windows Vista amplía su uso del principio de privilegios mínimos mediante una reducción aún mayor de los privilegios y el acceso a los archivos, las claves del Registro y los puertos del firewall que asigna a casi todos los servicios. Windows Vista define una nueva cuenta de grupo, denominada Identificador de seguridad del servicio (SID), exclusiva de cada servicio. El servicio puede establecer permisos en sus recursos, de forma que sólo tenga acceso su SID de servicio, impidiendo que los servicios que se ejecutan en la misma cuenta de usuario puedan tener acceso si un servicio se ve en peligro. El SID de un servicio se puede ver usando el comando sc showsid seguido del nombre del servicio, como se muestra en la Figura 8.

Figura 8** Consultar un SID de servicio **(Hacer clic en la imagen para ampliarla)

Los SID de servicio protegen el acceso a recursos propiedad de un servicio concreto, pero de manera predeterminada los servicios continúan teniendo acceso a todos los objetos a los que puede tener acceso la cuenta de usuario en la que se ejecutan. Por ejemplo, un servicio que se ejecute en la cuenta de servicio local podría no tener acceso a los recursos creados por otro servicio que se ejecute como servicio local en otro proceso que haya protegido sus objetos con permisos que hagan referencia a un SID de servicio, pero sí puede leer y escribir objetos para los que tenga permiso el servicio local (y a los grupos a los que pertenezca el servicio local, como el grupo de servicios).

Windows Vista introduce así un nuevo tipo de servicio restringido denominado servicio restringido de escritura, que concede un acceso de escritura de servicio sólo a los objetos accesibles para su SID de servicio, al grupo Todos y al SID asignado a la sesión de inicio. Para ello usa SID restringidos, un tipo de SID introducido en Windows 2000. Cuando el proceso que abre un objeto es un servicio restringido de escritura, el algoritmo de comprobación de acceso cambia para que un SID que no se haya asignado a un proceso, de forma tanto restringida como sin restricciones, no se pueda usar para conceder al proceso acceso de escritura a un objeto. Puede consultar si un servicio es restringido con el comando siguiente:

sc qsidtype [service]

Hay otro cambio que hace fácil que un servicio impida que otros servicios que se ejecutan en la misma cuenta tengan acceso a los objetos que crea. En versiones anteriores de Windows, el autor de un objeto es también el propietario del objeto y los propietarios tienen la capacidad de leer y cambiar los permisos de sus objetos, concediendo acceso completo a sus propios objetos. Windows Vista introduce el nuevo SID de derechos de propietario, el cual, si existe en los permisos de un objeto, puede limitar los accesos que un propietario tiene a su propio objeto, incluso eliminando el derecho de establecer y consultar los permisos.

Otra mejora del modelo de seguridad de servicios de Windows Vista permite que el desarrollador de un servicio especifique exactamente qué privilegios de seguridad necesita el servicio para funcionar cuando el servicio se registra en un sistema. Por ejemplo, si el servicio necesita generar eventos de auditoría, podría contener el privilegio de auditoría.

Cuándo el Administrador de control de servicio inicia un proceso que hospeda uno o varios servicios de Windows, crea un token de seguridad (objeto del kernel que enumera la cuenta de usuario de un proceso, las pertenencias a grupos y los privilegios de seguridad) para el proceso que sólo contiene los privilegios necesarios para los servicios del proceso. Si un servicio especifica un privilegio que no está disponible para la cuenta en que se ejecuta, el servicio no se puede iniciar. Si ninguno de los servicios que se ejecutan en un proceso de cuenta de servicio local necesita el privilegio de depuración de programas, por ejemplo, el Administrador de control de servicio elimina dicho privilegio del token de seguridad del proceso. Así, si el proceso del servicio se ve en peligro, el código malintencionado no puede usar los privilegios no solicitados explícitamente por los servicios que se ejecutan en el proceso. El comando sc qprivs indica qué privilegios ha solicitado un servicio.

Conclusión

Así concluye mi análisis en tres partes de los cambios del kernel de Windows Vista. Hay características y mejoras que no he tratado ni mencionado, por ejemplo, un nuevo grupo de subprocesos de trabajo para desarrolladores de aplicaciones, los nuevos mecanismos de sincronización, como los bloqueos de lector/escritor compartidos, el etiquetado de subprocesos de servicios, la compatibilidad con la comprobación y el cambio de tamaño de discos de NTFS, y un nuevo mecanismo IPC del kernel denominado Llamada avanzada a procedimiento local (ALPC). Puede buscar más información sobre estas y otras características en la próxima edición de Windows Internals, que se publicará a finales de 2007.

Ver el servicio de escritura restringida

Sólo un proceso de hospedaje de servicios de Windows Vista aloja servicios restringidos; se puede identificar con una herramienta de consulta de procesos como Process Explorer, como el que tiene la línea de comandos:

svchost -k LocalServiceNoNetwork

Los servicios configurados para ejecutarse en este proceso son Motor de filtro de base, Servicio de directivas de diagnóstico, Firewall de Windows, Registros y alertas de rendimiento, e Inicio de servicios de Windows Media® Center.

En esta pantalla se muestra la forma de texto del SID del servicio Motor de filtro de base, NT SERVICE\BFE, mencionado una vez con el marcador de restringido y otra vez sin él, de modo que el proceso tiene acceso a los recursos accesibles para esa cuenta. Con todo, no tiene necesariamente acceso a otros objetos normalmente accesibles para la cuenta del servicio local. Por ejemplo, como la cuenta de NT AUTHORITY\SERVICE no aparece en el token del proceso con el marcador de restringido, el proceso no puede modificar objetos que conceden acceso de escritura únicamente a esa cuenta y no a otras del token que tienen el marcador de restringido.

Los servicios que se ejecutan en este proceso limitan también sus privilegios, porque los privilegios enumerados en la parte inferior del cuadro de diálogo de propiedades son un subconjunto de los disponibles para la cuenta del servicio local.

Marcadores SID en un servicio(Hacer clic en la imagen para ampliarla)

Mark Russinovich es técnico de Microsoft en la división de plataformas y servicios. Es coautor de Microsoft Windows Internals (Microsoft press, 2004) y ponente habitual en conferencias de TI y desarrolladores, incluidos Microsoft Tech•Ed y el PDC. Entró a formar parte de Microsoft con la reciente adquisición de la empresa que cofundó él mismo, Winternals Software. También creó Sysinternals, donde publicó muchas utilidades muy conocidas, como Process Explorer, Filemon y Regmon.

© 2008 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos; queda prohibida la reproducción parcial o total sin previa autorización.