Daniel Martín's blog : Component-Based Servicing (CBS)

Mecanismos de protección de integridad en Windows 2000/XP/Vista y 7: Windows File Protection y Windows Resource Protection

dmartin — Sun, 07 Jun 2009 16:36:00 GMT

Desde que salió a la luz Windows Vista, y ahora con las versiones preliminares de Windows 7, me he dado cuenta de que el número de problemas cuya solución implica el registro de una DLL (mediante el comando regsvr32 nombreDLL) ha descendido notablemente en estos dos últimos sistemas operativos. Una de las causas de esto, para mí, es la inclusión de Windows Resource Protection (WRP), mecanismo que garantiza la integridad de los componentes vitales del sistema operativo y que supone una tremenda mejora con respecto a Windows File Protection (WFP), sistema de protección de archivos de sistema presente en Windows 2000 y XP.

Windows File Protection (WFP)

Windows 2000 y XP incorporaron una característica denominada WFP (Windows File Protection), encargada de proteger los archivos más importantes del sistema operativo para evitar que sean modificados o eliminados.

Su funcionamiento se basa en uno o varios hilos de tipo centinela residentes en el proceso Winlogon e implementados en la DLL Sfc_os.dll. Es decir, estos hilos están al tanto de cualquier tipo de modificación que se realice sobre directorios del sistema (típicamente \System32 y \System32\drivers). Si hubiera cambiado alguna DLL de estos directorios, se registra dicho suceso en una cola destinada a tal efecto. En ese momento se señaliza un evento que despierta a otro hilo encargado de realizar la verificación del correspondiente archivo y su recuperación desde la cache (carpeta oculta \WINDOWS\System32\dllcache). Si no estuviera en cache, se mostrará una interfaz al usuario informándole de tal situación e invitándole a introducir el CD de Windows 2000/XP para intentar recuperar la versión original del archivo.

Windows Resource Protection (WRP)

La llegada de Windows Vista supuso que la estructura interna del sistema operativo cambiara radicalmente. Ahora el sistema operativo está formado por componentes, claves de Registro, manifiestos XML y ficheros binarios, entre otras cosas, por lo que la aproximación empleada en versiones anteriores de Windows ya no podía seguir siendo válida. Este aspecto puede ser interpretado como una ventaja, pues si se desarrolla un sistema de protección para cada uno de los componentes del sistema operativo, ya no solo estaremos protegiendo ejecutables y DLL, como en Windows 2000/XP, sino que estaremos protegiendo también claves de Registro y otro tipo de recursos que son igualmente vitales para el correcto funcionamiento del equipo. Este sistema de protección recibió el nombre de Windows Resource Protection (WRP).

Cada uno de los componentes que conforman el sistema operativo Windows Vista/Windows 7 contiene un fichero denominado manifiesto. Un manifiesto es un fichero de tipo XML que contiene información específica sobre el componente, es decir, archivos que lo componen, archivos de los que depende, claves de Registro, privilegios con los que se ejecutará por defecto, idioma, etc. Uno de estos posibles parámetros (etiquetas XML) es la protección del recurso en cuestión, etiqueta <systemProtection></systemProtection>. Existen distintos valores posibles para el parámetro behavior (comportamiento) de esa etiqueta:

readOnlyIgnoreWrites: El recurso solo puede ser modificado por el sistema operativo, durante una instalación (servicio TrustedInstaller). Cualquier intento de escritura por parte de una aplicación será descartado; es decir, se le informará de que la escritura se realizó con éxito pero el fichero no se verá modificado.
readOnlyFailWrites: El recurso solo puede ser modificado por el sistema operativo, durante una instalación (servicio TrustedInstaller). Cualquier intento de escritura por parte de una aplicación tendrá como consecuencia que reciba un error.
OSOnlyIgnoreWrites: Similar a readOnlyIgnoreWrites, pero las modificaciones las puede hacer cualquier componente del sistema operativo.
OSOnlyFailWrites: Similar a readOnlyFailWrites, pero las modificaciones las puede hacer cualquier componente del sistema operativo.
applicationVirtualized: Cualquier cambio que se haga sobre el recurso supondrá que el sistema operativo cree una copia privada a la aplicación que lo ha modificado. El recurso global no se ve modificado.
userVirtualized: Similar a applicationVirtualized pero la copia privada es por usuario, no por aplicación.

En el mismo fichero de manifiesto se indica también qué descriptor de seguridad usar para dicho componente. Por ejemplo, la carpeta Winsxs de Windows Vista tiene este descriptor de seguridad:

O:S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464

G:S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464

D:PAI

(A;OICI;FA;;;S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464)
(A;OICI;0x1200a9;;;BA)
(A;OICI;0x1200a9;;;SY)
(A;OICI;0x1200a9;;;BU)"

Donde S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464 es el SID de TrustedInstaller, un servicio encargado de instalar actualizaciones y componentes en Windows Vista y Windows 7.

Vamos a explicar un poco el descriptor de seguridad: Las dos primeras líneas indican que el propietario (O, de owner) como el grupo (G, de group) es TrustedInstaller. La línea D:PAI quiere decir que el DACL es protegido (es decir, que no hereda listas de control de acceso o ACL) y además se hereda automáticamente. A continuación se indica que TrustedInstaller tiene acceso total al recurso (FA, de full access); el grupo de administradores, sistema y usuario (BA, SY y BU, respectivamente) tienen acceso genérico de lectura/escritura. Así pues, ni siquiera un administrador podrá modificar el contenido del directorio Winsxs. Tan solo TrustedInstaller, con motivo de la instalación/desinstalación de actualizaciones, Service Packs o componentes opcionales de Windows podrá modificar ese directorio.

Si quiere saber más sobre ACL y DACL le recomiendo el libro Windows Internals, escrito por Mark Russinovich y David Solomon, ya sea en su cuarta o su quinta edición.

Veámoslo con un ejemplo

Abriendo el fichero de manifiesto del componente Bloc de notas de Windows Vista podemos observar entre otras cosas lo siguiente:

<dependentAssembly> <assemblyIdentity name="Microsoft-Windows-Kernel32" version="6.0.6001.18000" processorArchitecture="x86" language="neutral" buildType="release" publicKeyToken="31bf3856ad364e35" versionScope="nonSxS" /> </dependentAssembly>

Aquí se hace referencia a que Bloc de notas depende del componente Microsoft-Windows-Kernel32 (que contiene entre otras cosas la DLL Kernel32.dll) para funcionar correctamente.

<systemProtection xmlns="urn:schemas-microsoft-com:asm.v3" behavior="readOnlyFailWrites" perUserVirtualization="Disabled" />

Aquí se hace referencia a que cualquier intento de escritura sobre el componente Bloc de notas dará como resultado un error y no se llevará a cabo la modificación. La virtualización está desactivada, por tratarse de un componente de Windows.

<shortCut arguments="" destinationPath="$(runtime.documentsSettings)\Default\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Accessories" destinationName="Notepad.lnk" targetPath="$(runtime.system32)\notepad.exe" iconPath="$(runtime.system32)\notepad.exe,0" windowStyle="normal" workingDirectory="%HOMEDRIVE%%HOMEPATH%" description="@%SystemRoot%\system32\Shell32.dll,-22563" displayResource="$(runtime.system32)\shell32.dll,22051" />

Aquí se hace referencia a la configuración del acceso directo al bloc de notas que hay en el menú Inicio.

<registryKey keyName="HKEY_CLASSES_ROOT\Applications\notepad.exe\shell\open\command" owner="false"> <registryValue name="" valueType="REG_EXPAND_SZ" value="%SystemRoot%\system32\NOTEPAD.EXE %1" operationHint="replace" owner="true" />

Aquí se hace referencia a una de las claves de Registro gobernadas por Bloc de notas, la correspondiente a las asociaciones de ficheros.

Como puede observar, la integridad del sistema operativo fue uno de los objetivos principales para Microsoft mientras diseñaba Windows Vista. La protección de todos y cada uno de los recursos vitales del sistema operativo mediante Windows Resource Protection (WRP) hacen que Windows Vista y Windows 7 sean sistemas mucho más estables y robustos que sus predecesores.

El caso de la instalación fallida de IIS en Windows Vista

dmartin — Wed, 07 Jan 2009 16:11:00 GMT

El caso de hoy es el de un sistema Windows Vista en el que no era posible instalar el componente IIS (Internet Information Server), que sirve para publicar páginas web tanto local como remotamente y es un requisito previo a la instalación de algún que otro programa, como por ejemplo Virtual Server. Para instalar componentes opcionales en Vista, como sabrá, hay que ir a Panel de control, Programas, Instalar o desinstalar componentes de Windows.

El mensaje de error que aparecía era el siguiente:

Una de las primeras cosas que hay que examinar cuando hay problemas para instalar un componente de Windows, un paquete de idiomas, una actualización, un Service Pack, etc. es el fichero C:\Windows\Logs\CBS\CBS.log. Es posible que el registro sea bastante extenso y por ello se haya creado un fichero CBS.persist.log con las entradas más antiguas. En tal caso, es posible que tengamos que examinar este fichero también.

Buscando en el fichero de abajo hacia arriba, encontré el error que probablemente estaba abortando la instalación:

2008-12-23 11:57:34, Error CSI 00000012@2008/12/23:10:57:34.500 (F) d:\rtm\base\wcp\sil\silp.h(2661): Error STATUS_INVALID_PARAMETER originated in function Windows::Rtl::SystemImplementation::CFile_IRtlFileTearoff::SetAttributes expression: Valid flags check failed: Attributes [gle=0x80004005]

Estas líneas quieren decir que ha fallado la comprobación de parámetros de una función del servicio de componentes de Vista. Concretamente la función es SetAttributes, que probablemente tenga como objetivo aplicar ciertos atributos sobre un fichero. La parte "[gle=0x80004005]" (gle es la función GetLastError) quiere decir que el último error surgido durante la ejecución de dicha función es un error HRESULT que básicamente quiere decir que el error es inespecífico. Obviamente necesitaba información mucho más útil, así que examiné el reporte a partir de ese punto y me encontré con esta línea, mucho más interesante:

2008-12-23 11:57:34, Error CSI 00000011 (F) STATUS_INVALID_PARAMETER #3228437# from Windows::Rtl::SystemImplementation::CFile_IRtlFileTearoff::SetAttributes(Attributes = 2048 (0x00000800))[gle=0xd000000d]

El error 0xd000000d quiere decir STATUS_INVALID_PARAMETER pero, ¿qué atributos se le estaba pasando a la función? El valor Attributes = 2048 (0x800 en hexadecimal) nos da la clave. Una búsqueda en el fichero Winddk.h del DDK de Windows devolvió el siguiente resultado:

#define FILE_ATTRIBUTE_COMPRESSED 0x00000800

Como ve, el atributo que se estaba pasando es el atributo comprimido. La compresión de ficheros es una característica del sistema de ficheros NTFS y no tiene nada que ver con los archivos .zip o .rar. Ya estaba cerca de desvelar el misterio, pero para poder aplicar una solución necesitaba saber qué fichero o ficheros estaban involucrados en el error. Observando minuciosamente el fichero CBS.log me encontré con esa información:

2008-12-23 11:57:49, Info CSI 00000013 Error STATUS_INVALID_PARAMETER while executing operation SetFileInformation on [l:138{69}]"\??\C:\Windows\System32\inetsrv\config\schema\FX_schema.xml, N/A, N/A"

Hay que tener en cuenta que el fichero FX_schema.xml no había sido servido aún al directorio C:\Windows\System32\inetsrv\config\schema\ (directorio de instalación de IIS), pues la instalación no pudo completarse, por lo que le indiqué al usuario que acudiera al almacén de componentes (C:\Windows\winsxs) y buscara allí el componente que contuviera ese fichero FX_schema.xml. El usuario me informó de dos resultados:

amd64_microsoft-windows-iis-sharedlibraries_31bf3856ad364e35_6.0.6000.16386_none_6ad14c4c7044b7ae (estaba sin comprimir)
amd64_microsoft-windows-iis-sharedlibraries_31bf3856ad364e35_6.0.6001.18000_none_6d080e486d2fc882 (comprimido, es decir, en color azul).

El primer resultado es el componente instalado por la versión RTM de Windows Vista; el segundo es el instalado por el Service Pack 1.

Así pues, el usuario descomprimió la segunda carpeta desde el panel de propiedades, botón Opciones avanzadas, y ya pudo instalar IIS.

¿Por qué estaba comprimida esa carpeta? Ciertamente lo desconozco, pero mi opinión es que algún software o el propio usuario lo hizo con el objetivo de ahorrar espacio en disco debido al elevado espacio en disco consumido por el directorio C:\Windows\winsxs en Windows Vista. Como puede leer en este blog del equipo de Windows, el espacio realmente ocupado es mucho menor y, como ya pudo comprobar, comprimirlo puede tener como consecuencia no poder instalar un componente de Windows.

¡Caso cerrado!

Actualización (27 de octubre de 2009): En según qué casos, puede ser que necesitemos echar un vistazo también al fichero de reporte específico de IIS, a saber, %windir%\iis.log.

El comando Sfc.exe en Windows Vista

dmartin — Sat, 04 Oct 2008 15:49:00 GMT

Una de las acciones más recomendables cuando nos enfrentamos a cierto tipo de problemas en Windows es comprobar la consistencia de los ficheros del sistema operativo, para asegurarnos de que ningún usuario o aplicación los haya eliminado o modificado con versiones incorrectas. El comando que lleva a cabo todo este proceso recibe el nombre de Sfc.exe (System File Checker).

Diferencias entre el comando Sfc.exe en Vista y en versiones anteriores de Windows

Pese a que la sintaxis básica de Sfc.exe se ha mantenido prácticamente inmutable a lo largo del tiempo, los cambios en la arquitectura de Windows Vista han derivado en que la manera de actuar de Sfc.exe ha tenido que cambiar también. Mientras que en Windows XP la unidad básica podríamos decir que es el fichero, en Windows Vista la unidad básica es el componente. Un componente es un contenedor de recursos, entendiendo por recurso un fichero binario, una clave de Registro, un manifiesto (fichero XML con extensión .manifest), etc. Esta jerarquía ha facilitado enormemente la implementación de Windows Vista, tanto para el usuario final, como para Microsoft. Sin embargo, hay ocasiones en las que los componentes del sistema operativo, pese a estar protegidos por WRP (Windows Resource Protection, tema que se tratará en un posterior artículo), se dañan, produciendo comportamientos negativos de lo más variado, como por ejemplo impedir la instalación de una actualización o de un Service Pack. La herramienta Sfc.exe en Windows Vista comprueba la consistencia de dos aspectos del sistema operativo a través del proceso TrustedInstaller.exe ("Instalador confiable"):

Los componentes del sistema operativo.
Los controladores Plug and Play del sistema operativo (almacén DMI).

Comprobación de los componentes del sistema operativo

En primer lugar se debe comentar que Sfc.exe solo puede reparar componentes que no sean del tipo SxS (Side-by-Side). Este artículo no pretende explicar en qué consisten los componentes SxS, en la web de MSDN dispone de información sobre esta funcionalidad que tantos quebraderos de cabeza da a los desarrolladores de aplicaciones. Para determinar si un componente está dañado o no, se comprueba su manifiesto y los ficheros que lo forman. Si el manifiesto estuviera dañado o no existiera, el sistema aún puede recuperarlo desde el backup, el directorio %windir%\winsxs\Backup. Si esto ocurre y la recuperación se realiza con éxito, el fichero CBS.log del directorio %windir%\Logs\CBS\ registra una línea similar a "[SR] Recovered manifest [...] from backup".

Una vez que los manifiestos han sido verificados y, en caso necesario, reparados, se procede a analizar los binarios que forman el componente. Antes de seguir, conviene explicar que un componente puede presentar varios estados en el sistema operativo:

Ausente: Ni siquiera los manifiestos del componente están presentes en el sistema.
Resuelto: Los manifiestos están presentes en el equipo, pero los ficheros no.
Staged: Los ficheros y manifiestos están presentes, pero aún no han sido proyectados (es decir, el sistema operativo no los está usando).
Instalado: Los ficheros y manifiestos están correctamente instalados en el sistema.

Para saber si el componente que está siendo analizado por Sfc está en el estado staged o alguno más avanzado, se examina la clave de Registro HKEY_LOCAL_MACHINE\COMPONENTS\DerivedData\Components. Los valores que comienzan por "c!" hacen referencia a componentes y los que comienzan por "f!" hacen referencia a archivos.

El hash del fichero se compara con el que está presente en el manifiesto y, en caso de que no coincidieran, se intenta recuperar el binario desde el almacén (%windir%\winsxs\). Si tampoco fuera posible extraerlo de ahí o si también estuviera corrupto, se recurre de nuevo al directorio %windir%\winsxs\Backup\.

Comprobación de los controladores Plug and Play

En esta fase se verifica el estado de los controladores Plug and Play que haya instalados en el sistema. En primer lugar, la lista de dichos controladores se enumera desde la clave de Registro HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Setup\PnPLockDownFiles. La comprobación de cada uno de los controladores se realiza contra el correspondiente catálogo presente en el almacén de catálogos (Catroot). Si el controlador estuviera corrupto, se intenta extraer una copia desde el almacén de controladores (%windir%\inf), almacén que contiene los controladores incluidos de serie en una instalación de Windows Vista.

Como ve, el comando Sfc.exe funciona de manera completamente diferente en Windows XP y en Windows Vista. Debido a la nueva arquitectura basada en componentes, en ocasiones esta utilidad va a reportarnos en el fichero CBS.log que no ha sido capaz de solucionar los problemas de consistencia del sistema operativo. Si el almacén de componentes estuviera corrupto, puede probar con la utilidad System Update Readiness, si es que Windows Update no se la ha ofrecido ya. Si aún así siguiera el problema, habrá que examinar con paciencia el fichero CBS.log y determinar el lugar exacto donde está la inconsistencia. A partir de ahí, podría intentarse la extracción desde la imagen WIM presente en el DVD de Windows Vista, proceso que, si bien es arduo y laborioso, nos puede ahorrar una instalación limpia de Windows Vista. Quizá explique este procedimiento en un próximo artículo.