How to cause a DoS in Windows 8 explorer.exe

Monday, September 30, 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

How does blacklisting work in Java and how to take advantage of it (using whitelisting)

Sunday, September 22, 2013

Oracle has introduced the notion of whitelisting in its latest version of Java 7 update 40. That is a great step ahead (taken too late) in security for this platform but... how does it work? how does it deal with older versions? And what is most important... how to block everything but the applets you want?

This is the first time in years that Java allows to whitelist applets. This has become a true necessity for security, because of quite aggressive kits exploiting everything related with Java and its self "natural born insecurity". Before this version Java was the one blacklisting some applets, but it was managed by Oracle only, updated in each new version, not dynamic and very badly documented. But now, at last with Java 7u40 we have the chance to whitelist applets. It is not trivial though. But it is not trivial though.

What you will need is a ruleset.xml file, compile it and sign it. For signing it you may use a real certificate or a selfsigned certificate created by yourself but installed in your trust-store.

Step by step. Creating the ruleset.xml

This is a standard XML file with a simple syntax. It defines which applets to block or allow depending on the domain they come from or who signed them. It also defines which version of Java has to be used to run the applet. Wildcards and rules by default are accepted, doing it may be quite granular. Let's create a file that allows only applets working with the ones hosted in java.com, and deny other applets.

<ruleset version="1.0+">
<rule>
  <id location="http://*.java.com" />
  <action permission="run" version="SECURE-1.7" />
</rule>
<rule>
<id />
  <action permission="block">
  <message>Bloqueado por las reglas del sistema</message>
</action>
</rule>
</ruleset>

Last "id" means this is the "by default" rule and matches everything not matched before. The "version" tag may be handy... or tricky. It allows you to specify that an applet will run only with a desired (older) version that will, by definition, have security problems. So if the computer is keeping older versions (6.x) and an applet uses it... be aware this rule doesn't work for branch 6 (nothing will be blocked). So, if keeping this branch in the computer, this may all be useless.

Ruleset allows to execute, for example, only applets signed by a certificate and much more. Specifications are here.)

Step by step. Creating the jar and signing it

Download JDK and execute:

C:\Archivos de programa\Java\jdk1.7.0_40\bin>jar -cvf DeploymentRuleSet.jar rulset.xml

Then, sign it:

C:\Archivos de programa\Java\jdk1.7.0_40\bin>jarsigner -verbose -keystore keystore.jks -signedjar DeploymentRuleSet.jar DeploymentRuleSet.jar selfsigned


Where "keystore.jks" may be your actual key store and "selfsigned" the alias of your certificate. If you already have a valid certificate (signed by a CA), skip the following part. If not, create a self signed one with the command:

keytool -genkey -keyalg RSA -alias selfsigned -keystore keystore.jks -storepass 123456 -validity 360 -keysize 2048

Where "123456" is the password to unlock the keystore (do not confuse it with the password of the certificate itself).

It will ask some questions. It does not matter how you answer them.

Finally, export the certificate:

keytool -export -alias selfsigned selfsigned.crt -keystore keystore.jks

And import it as a trusted root. You may do it in Windows (installing it as a trusted root in certmgr.msc) or inside Java certificate store. This is the way to do it:

C:\Archivos de programa\Java\jdk1.7.0_40\bin>keytool -importcert -alias selfsign
ed -file self.crt -trustcacerts -keystore ..\..\jre7\lib\security\cacerts

Now  DeplymentRuleSet.jar is signed, copy it to its place (funny how Oracle still keeps some "Sun" names, four years later).

C:\Archivos de programa\Java\jdk1.7.0_40\bin>copy DeploymentRuleSet.jar c:\WINDOWS\Sun\Java\Deployment\DeploymentRuleSet.jar

Execute javacpl.cpl and check Java is aware of the rules.


Checking it all

So, if you check applets hosted inside the specified domain, they will run but any other will be blocked. This is a great and very expected security measure if you do not have to deal with older versions.



Do not forget:
  • This is useless if other Java security measurements are not deployed. For example rise up the security leverage to "high" in security options. So far, with this leverage we could be "protected" against self-signed java malware, but what about properly signed ones? This feature tries to cover that gap.
  • Very important: whitelisting an applet by any kind of rule makes other warning screens introduced in java 7u10 go away, like this one (it will not show up if whitelisted):
  • This is useless if Java is not updated and older versions deleted in the system.
Just to check, using a not trusted certificate for DeploymentRuleSet.jar will block applets with a different message.


It's important to notice that Oracle has warned that they will blacklist certificates that sign DeploymentRuleSet.jar files that allow to execute everything.

Anyhow, Oracle had to keep backwards compatibility with 1.6 branch, and when they drop support for it, this is the best way they have found to help administrators with some native tool to control Java plugin madness. Not bad.

Sergio de los Santos
ssantos@11paths.com
@ssantosv