How to cause a DoS in Windows 8 explorer.exe

lunes, 30 de septiembre de 2013


We have discovered by accident how to cause a Denial of Service (DoS) in Windows 8. It’s a little bug that is present in the last version of the operating system. Since we alerted Microsoft first and they didn’t consider it a real security problem that could be attacked we’re documenting it as an anecdote.

Explorer.exe is a very important service in Windows. It’s in charge of painting the desktop and gives the security tokens to the programs that are in the same environment. It’s of vital importance that it’s running in every moment, hence if the process dies for some reason, the operating system itself will recover it automatically.

Seemingly, in Windows 8, explorer.exe doesn’t handle correctly an exception that is thrown when dealing with digital certificates and it forces it to close and launch again. This problem also affects other programs that use the same internal API that processes ASN.1 structures. For example, any program that uses .NET and processes the “signedInfo” field of a signature.



These are steps to reproduce the problem:
  • Have a signed binary (DLL or EXE) at hand. Any binary is valid if it’s signed.
  • Fill the last section of the PKCS structure with zeroes or random values. For example 256 bytes of “00”.

A part of the signature filled with 00s


In this example we’ve overwritten part of the information regarding the countersignature as we can observe when opening the ASN.1 structure with a different program. We haven’t tested exactly which part causes the problem when being overwritten.


On the left, altered ASN.1 structure, on the right, unaltered structure.


If we overwrite other kind of information Windows will simply think that the binary isn’t signed and won’t show the “Digital signatures” tab in the properties dialog.

  • Using Explorer to access the “Digital signatures” tab will crash explorer.exe with an unhandled exception. Other programs like “Total commander” also crash in the attempt of showing the certificate. This bug is only present in Windows 8. The same proof of concept in Windows XP/7 only tricks the system to show the “Digital signatures” tab without any info to display. This isn’t normal either (the tab shouldn’t be visible) but at least it doesn’t kill the process.


Other programs that check the signature such as sigcheck or signtool are not affected.
In theory this can be related to the change of design. In Windows 7 and XP the email of the signer is shown in the “Digital signatures” information tab. In Windows 8 the hash is being shown. We suppose that they became aware that very few signers include the email in the signature, and this field was usually blank.

On the left, properties of a signed file in Windows 7. On the right, in Windows 8.


A quick analysis results in our hypothesis that it’s difficult to take advantage of the bug to run arbitrary code. MSRT confirms us that it is more like a bug and not a real security problem.

Sergio de los Santos

Cómo provocar un DoS en el explorer.exe de Windows 8

jueves, 26 de septiembre de 2013

Por accidente, hemos descubierto cómo provocar un DoS de explorer.exe en Windows 8. Se trata de un pequeño bug introducido en la última versión del sistema operativo. Lo documentamos como simple anécdota, puesto que desde Microsoft no lo han considerado un problema de seguridad y parece complejo que pueda ser aprovechado para explotarlo de alguna forma.

Explorer.exe es un servicio muy importante en Windows. Se encarga de pintar el escritorio y darle el token de seguridad a los programas que heredan de él, para que se mantengan en el mismo entorno.  Es vital que se ejecute en el sistema en todo momento. Tanto, que si "muere" de alguna forma, el sistema operativo lo recupera automáticamente

Parece que en Windows 8, explorer.exe no maneja correctamente una excepción a la hora de manejar firmas digitales, y esto hace que se reinicie. También afecta a otros programas que utilizan la misma API interna de procesamiento de estructuras ASN.1. Por ejemplo, cualquier programa en C# que intente procesar signedInfo de una firma.

Para reproducir el problema, se debe:
  • Tomar un binario (DLL o EXE) firmado. Cualquiera es válido. 
  • Rellenar parte de la estructura PKCS al final del fichero con datos aleatorios. Por ejemplo "00". Con unos 256 bytes funciona.
Zona de la firma modificada con cualquier editor hexadecimal
En este ejemplo, se ha "machacado" parte de la información relativa a la contrafirma, como se observa al estudiar la estructura ASN.1 con otro programa diferente.  No hemos comprobado qué parte exactamente es necesario sobrescribir o qué mínimo es necesario para provocar el fallo.

A la izquierda la estructura ASN.1 alterada, a la derecha, la estructura sin alterar
Si se machaca otro tipo de información, Windows pensará simplemente que el fichero no está firmado y no mostrará la opción de "Firmas Digitales" en las propiedades.
  • Desde Explorer, ver las  propiedades y "Firmas Digitales" hará que explorer.exe no maneje la excepción y falle. Otros programas como Total Commander también se interrumpen. En realidad cualquier programa que no recoja la excepción de datos ASN.1 dañados, dejará de funcionar. Y aquí es donde explorer.exe hace un mal trabajo, y eso es de extrañar. Sobre todo, porque solo ocurre en Windows 8. La misma prueba de concepto en Windows XP o 7 hace que el sistema operativo muestre la pestaña de "Firmas Digitales" pero nada dentro. Una situación que no es normal, (si no hay firma, no debería mostrar la pestaña) pero al menos no hace que se reinicie el proceso.


Otros programas de comprobación de firma como sigcheck or signtool no se ven afectados.

Como hipótesis, es posible que tenga que ver con el cambio de "diseño". En windows 7 y XP, en la pestaña de firmas digitales se muestra el email del que firma. En Windows 8, el hash. Suponemos que se dieron cuenta de que pocos incluían el email en la firma, y por tanto ese campo solía estar vacío.

A la izquierda las propiedades de un fichero firmado en Windows 7. A la derecha, en Windows 8.
Un pequeño análisis previo indica que parece complicado que se pueda aprovechar para ejecutar código. Desde MSRT nos indican que efectivamente, parece más un bug que un fallo de seguridad.

Sergio de los Santos