De FileAllInformation a inotify: 19 años de metadatos como frontera desatendida
Cómo un desbordamiento de búfer que Microsoft tildó de «no explotable» en 2007 y una fuga de información que la industria llama «by-design» en 2026 son, en realidad, la misma historia contada dos veces.
Hay fallos que no envejecen: se transforman. Dos investigaciones separadas por casi dos décadas —una de 2007 sobre Windows XP, otra de 2026 sobre Linux, Android, macOS y Windows— apuntan a la misma raíz: los metadatos de archivos son una frontera de seguridad que seguimos tratando como si fuera inocua. Y en ambos casos la respuesta del vendor fue esencialmente la misma: no es un problema.
La historia merece contarse completa. Cuando un proveedor decide que algo «no es explotable», no cierra el debate: solo lo pospone hasta que alguien encuentre el ángulo correcto. Diecinueve años después, ese ángulo apareció, y viene con cifras de precisión del 100% sobre SSH y una nominación a los Pwnie Awards por la peor respuesta de vendor del año.
Parte I — 2007: el desbordamiento que Microsoft minimizó
El descubrimiento
En marzo de 2007, el investigador conocido como Lostmon documentó un desbordamiento de búfer local en el Explorador de Windows. El detonante era engañosamente simple: una cadena demasiado larga en los atributos extendidos de un archivo. Campos como Author, Title, Subject o Comment se procesaban en buffers de tamaño fijo, y al desbordarse provocaban el crash del Explorador —y, con él, la pérdida de todo el trabajo no guardado en cualquier aplicación que estuviera consultando esos atributos.
Lo interesante no era el crash en sí, sino dónde ocurría. El análisis con Filemon (Sysinternals) reveló que el fallo no estaba en la interfaz gráfica ni en un parser de documentos, sino en las tripas del sistema de gestión de archivos:
GetFileAttributesExW/GetFileAttributesWen KERNEL32NtQueryInformationFile,NtQueryDirectoryFileyNtSetInformationFileen ntdll.dll- Subfunciones
FileAllInformation()(clase 0x68) yFileNameInformation()(clase 0x08), entre otras de la tablaFILE_INFORMATION_CLASS
La traza de Filemon era inequívoca:
explorer.exe:1700 IRP_MJ_QUERY_INFORMATION C:\...\explorer_overflow.txt\:SummaryInformation:$DATA
BUFFER OVERFLOW FileAllInformationEl impacto, en palabras del propio investigador, era de «unknown impact»: un crash confirmado, con potencial desconocido. Lo que sí estaba claro era que el vector no requería abrir el archivo malformado —bastaba con abrir la carpeta, pasar el ratón por encima, o incluso borrarlo desde línea de comandos para que el Explorador cayera.
La reproducción paso a paso
El PoC original es tan sencillo que cualquiera puede reproducirlo en un Windows XP sin parchear:
- Crear un archivo
explorer.txt. - Clic derecho → Propiedades → pestaña Resumen.
- Rellenar todos los campos (Author, Title, Subject, Comment) con una cadena larga de «A».
- Aceptar y aplicar.
- Con Filemon filtrando por
explorer.exe, abrir de nuevo las propiedades o pasar el ratón sobre el archivo. - Observar cómo Filemon registra
BUFFER OVERFLOW FileAllInformation.
El equivalente programático es igual de simple. Este script VBScript enumera los atributos extendidos de todos los archivos de una carpeta y hace caer al Windows Scripting Host en cuanto toca el atributo número 9 (Author) del archivo malformado:
Dim arrHeaders(35)
Set objShell = CreateObject("Shell.Application")
Set objFolder = objShell.Namespace("C:\test")
For i = 0 to 34
arrHeaders(i) = objFolder.GetDetailsOf(objFolder.Items, i)
Next
For Each strFileName in objFolder.Items
For i = 0 to 34
Wscript.Echo i & vbtab & arrHeaders(i) _
& ": " & objFolder.GetDetailsOf(strFileName, i)
Next
NextEste detalle es importante: el fallo no está en el parser de Word ni de Office. Está en la capa común que consulta metadatos, la que cualquier aplicación de Windows usa cuando quiere mostrar información sobre un archivo.
La respuesta de Microsoft
La cronología del reporte fue la siguiente:
- 12-03-2007Descubrimiento del fallo.
- 19-03-2007Notificación privada a Microsoft.
- 22-03-2007Respuesta del vendor.
- 17-05-2007Divulgación privada a terceros (Secunia, OSVDB, etc.).
- 04-06-2007Divulgación pública.
La respuesta textual de Microsoft fue:
«We have concluded our investigations on this matter and have found this crash to be un-exploitable. This vulnerability is very similar to another milworm posting (milw0rm.com/exploits/3419). As we have not been able to find an exploitable angle for this issue this crash will get tracking into the next available Service Pack fix.»
Traducción: no vamos a arreglarlo ahora porque no hemos encontrado cómo explotarlo. En términos de gestión de riesgo, eso es exactamente lo contrario de lo que debería hacerse. «No explotable hoy» no significa «inofensivo»; significa «todavía no hemos encontrado el ángulo».
Detalle que el vendor pasó por alto: el fallo no era exclusivo de documentos de Office. Cualquier programa que usara la API de Windows y ole32.dll para abrir archivos —Notepad++, la familia Macromedia/Adobe y muchos otros— crasheaba al listar la carpeta con el archivo malformado, perdiendo todo el trabajo no guardado. El problema era estructural, no puntual.
Parte II — 2007 (bis): el fallo era estructural, no puntual
Meses después del primer aviso, Lostmon publicó un segundo estudio que demostraba que el problema era sistémico. Analizó exploits públicos para múltiples formatos —WMF (BID 16167), JPG (BID 25207), GIF y DOC— y encontró el mismo patrón en todos:
Mismo punto de crash
Todos caían en FileAllInformation() dentro de ntdll.dll.
Mismo atributo
Todos crasheaban en el atributo número 9, Author.
Mismo disparador
Todos se activaban al consultar los atributos extendidos, no al parsear el contenido.
Mismo alcance
El vector no dependía del formato: bastaba con que el archivo tuviera metadatos malformados.
Es decir: el desbordamiento no vivía en los parsers de imagen o documento, sino en la capa común que consulta metadatos. El PoC EFA_test.vbs lo confirmaba de forma elegante: basta con enumerar las propiedades de los archivos de una carpeta vía Shell.Application para que Windows Scripting Host caiga.
La conclusión de 2007 era cristalina y quedó archivada junto al CVE: el problema no era un formato, era la disciplina de tratar los metadatos como datos de confianza.
Diecinueve años después, esa conclusión resuena con una precisión incómoda.
Parte III — 2026: File Notification Attacks
El paper
En noviembre de 2026, en la conferencia ACM CCS de La Haya, el grupo de la Universidad Técnica de Graz (TU Graz) presentó el paper «File Notification Attacks: Templating and Exploiting Side-Channel Leakage from the File-Notification Systems on Linux, Windows, and macOS», firmado por Sudheendra Raghav Neela, Xufan Zhao, Jeanette Angelika Wultsch, Hannes Weissteiner, Florian Draschbacher, Stefan Gast y Daniel Gruss.
La tesis es un eco directo del hallazgo de 2007. Los subsistemas de notificación de cambios —inotify (Linux, 2005), FileObserver (Android, 2008), ReadDirectoryChangesW (Windows, 2000) y FSEvents (macOS, 2007)— informan a las aplicaciones cuando un archivo se abre, cambia, escribe o borra. No revelan el contenido. Pero el nombre, la existencia y el timing de los cambios son un canal lateral explotable.
Y en Linux y Windows, esa información está disponible incluso sin permiso de lectura sobre los archivos vigilados. Eso es lo que convierte una función de conveniencia en una vulnerabilidad de seguridad.
Linux: el caso de /dev/input
El vector más demoledor es /dev/input. Vigilar ese directorio genera una notificación en cada pulsación de tecla, porque los ficheros de dispositivo son legibles aunque el observador no tenga permisos sobre ellos. De ahí salen dos ataques devastadores:
Inter-keystroke timing local sobre siete usuarios distintos.
Inter-keystroke timing remoto a través de SSH, sin acceso físico.
Identificación de sitios visitados sobre el top 100.
Ataque de redress sobre el prompt de autenticación de KDE Plasma 6.
La vulnerabilidad recibió el identificador CVE-2025-68788 y fue parcialmente corregida en diciembre de 2025 en los kernels 5.10.248, 5.15.198, 6.1.160, 6.6.120, 6.12.64 y 6.18.3. El parche impide generar eventos access y modify sobre ficheros especiales en /dev/.
Parcialmente, porque el problema de fondo —el modelo de permisos del observador— sigue ahí. El propio paper reconoce que las mitigaciones necesarias van más allá de este parche concreto.
Android: FileObserver atraviesa FUSE
En Android, FileObserver atraviesa la capa FUSE que debería aislar el almacenamiento por aplicación. El resultado, en palabras de Neela:
«FileObserver goes past the FUSE layer meant to isolate per app storage, so a permissionless app can watch (for example) WhatsApp's private folder and see, by filename and timestamp, exactly when photos, videos, and documents are sent, received, or deleted.»
Es decir: una app sin ningún permiso puede vigilar la carpeta privada de otra app y reconstruir, solo con nombres de archivo y timestamps, la actividad completa del usuario: cuándo envía una foto, cuándo recibe un documento, cuándo borra un vídeo. No hace falta leer el contenido; el patrón de eventos es suficiente.
A pesar de la divulgación responsable entre agosto y octubre de 2025, no hay mitigación implementada en Android a día de hoy.
Windows: vigilar C:\ lo revela todo
En Windows el panorama es igual de grave. Vigilar el directorio raíz C:\ reporta la ruta completa de cada archivo tocado en el sistema, de todos los usuarios, con independencia de los permisos. Con esa información se puede hacer, en tiempo real, un ataque de fingerprinting web:
97,8% de precisión identificando qué webs visita otro usuario en Firefox, en tiempo real, solo observando qué ficheros de caché se tocan.
La respuesta de Microsoft a la divulgación fue:
«This is by-design and it's an undocumented feature.»
Esa respuesta fue nominada al premio a la peor respuesta de vendor en los Pwnie Awards 2026. El paralelismo con 2007 —donde Microsoft dijo «un-exploitable»— es tan exacto que duele.
macOS: el caso menos grave (pero no inocuo)
Apple sale mejor parada: no se encontraron bypasses para leer directorios privados. Pero FSEvents sí permite monitorizar cambios en ficheros .plist que revelan información sensible sobre el sistema y el usuario:
- Cambios en dispositivos de entrada/salida de audio.
- Cambios en la configuración de energía.
- Actualizaciones de dispositivos Bluetooth e impresoras.
- Cambios de DNS iniciados por cable de red.
- Eventos de montaje y desmontaje de volúmenes.
- Instalaciones y desinstalaciones de aplicaciones.
No es un canal tan directo como el de Linux o Windows, pero sigue siendo una fuga de información sobre la actividad del usuario y del sistema que un atacante local puede explotar para construir un perfil.
El paralelismo incómodo
Puestos uno al lado del otro, los dos hallazgos son la misma historia contada con 19 años de diferencia:
| 2007 (CVE-2007-4227 CVE-2007-5145) | 2026 (CVE-2025-68788 y familia) | |
|---|---|---|
| Vector | Metadatos extendidos malformados | Notificaciones de cambios de archivo |
| Capa afectada | ntdll.dll, FileAllInformation() |
inotify, FSEvents, ReadDirectoryChangesW, FileObserver |
| Fallo de fondo | Overflow al parsear metadatos | Infoleak al notificar metadatos |
| Asunción errónea | Los metadatos son datos de confianza | Saber que algo cambió es inofensivo |
| Alcance | Cualquier tipo de archivo con metadatos | Todos los SO modernos |
| Respuesta del vendor | «un-exploitable» | «by-design, undocumented feature» |
| Consecuencia | Archivado para el siguiente Service Pack | Nominación a los Pwnie Awards 2026 |
La lección de diseño es contundente: validar el tamaño al parsear (2007) y validar el permiso del observador al notificar (2026) son la misma disciplina. Ningún subsistema que hable de ficheros debería asumir que los metadatos son públicos.
Y hay una segunda lección, más incómoda: «no explotable» casi nunca significa «inofensivo». Significa «todavía no hemos encontrado el ángulo». En 2007 el ángulo era un crash; en 2026 es un canal lateral con 100% de efectividad sobre SSH. El coste de ignorar el aviso no desaparece: se acumula con intereses.
Qué debería cambiar
Los propios autores del paper plantean las mitigaciones necesarias. Son un buen punto de partida para cualquier equipo que diseñe subsistemas de ficheros, y un recordatorio de que los parches puntuales no sustituyen un cambio de modelo:
- Extender las comprobaciones de capacidad a la monitorización de los propios archivos y de cualquier archivo legible — no solo a los ficheros de dispositivo ya parcheados en Linux.
- En Windows, prohibir la monitorización de unidades completas. Vigilar
C:\no debería ser una operación sin privilegios. - En Windows y macOS, introducir un sistema de permisos a nivel de kernel que contemple contexto, control de acceso, archivos y directorios propios, y minifilters.
- En Android, cerrar la fuga de
FileObserversobre FUSE, que hoy permite a una app sin permisos observar el almacenamiento privado de otra. - Por defecto, no notificar. La seguridad de los metadatos debe ser opt-out, no opt-in.
A esto se podría añadir una sexta, heredada del hallazgo de 2007: validar siempre el tamaño de cualquier cadena que provenga de metadatos antes de copiarla a un buffer de tamaño fijo. Suena elemental, pero es exactamente lo que falló en FileAllInformation() hace diecinueve años, y es la clase de bug que sigue apareciendo en codebases modernas.
Conclusión
Diecinueve años después del primer aviso, el fix no es solo un parche técnico. Es un cambio de mentalidad: dejar de tratar los metadatos como información pública por defecto y empezar a tratarlos como lo que son —una superficie de ataque de pleno derecho, con implicaciones de privacidad y de seguridad medibles.
La curiosidad movió la mente en 2007. En 2026, los datos demuestran que tenía razón. La pregunta incómoda es cuántas veces más vamos a necesitar que alguien encuentre el ángulo explotable antes de que la industria decida que, quizá, los metadatos no eran tan inocuos después de todo.
Nota para equipos de desarrollo: si tu aplicación lee, escribe o notifica sobre metadatos de archivos, revisa dos cosas hoy mismo. Primero, que ningún buffer de tamaño fijo reciba datos que no controlas. Segundo, que los mecanismos de notificación que uses respeten el modelo de permisos del observador, no solo el del archivo observado. Son dos caras del mismo problema, y llevan veinte años sin resolverse.
Fuentes y referencias
- Lostmon (2007) — Buffer overflow in extended file attributes in Explorer.exe. Análisis original de CVE-2007-5145, con trazas de Filemon, PoC en VBScript y respuesta de Microsoft. lostmon.blogspot.com/2007/06/buffer-overflow-in-extended-file.html
- Lostmon (2007) — Windows Extended file attributes buffer overflow Study II. Generalización del fallo a WMF, JPG, GIF y DOC, con PoCs de CrazyAngel (BID 25207) y Dr.Pantagon. lostmon.blogspot.com/2007/08/windows-extended-file-attributes-buffer.html
- Lostmon (2026) — De FileAllInformation a inotify: 19 años de metadatos como frontera desatendida. lostmon.blogspot.com/2026/09/de-fileallinformation-inotify-19-anos.html
- Neela, S. R., Zhao, X., Wultsch, J. A., Weissteiner, H., Draschbacher, F., Gast, S., Gruss, D. (2026) — File Notification Attacks: Templating and Exploiting Side-Channel Leakage from the File-Notification Systems on Linux, Windows, and macOS. ACM CCS 2026, La Haya. Resumen en inoti.fyi
- The Register (2026) — Decades-old file security flaws found in Android, Linux, macOS, and Windows, por Thomas Claburn. theregister.com/security/2026/09/24/…
- CVE-2007-5145 — Windows XP
FileAllInformationbuffer overflow. - CVE-2025-68788 — Linux kernel file notification access/modify events on
/dev/special files. - Referencias técnicas adicionales — undocumented.ntinternals.net (FILE_INFORMATION_CLASS), Extended file attributes, Sysinternals Filemon.
Posts
