Hi all,

The following vulnerabilities have not been reported at Bugtraq before, and unfortunately they seem to be largely unknown in public even though they are about a year old by now. They have both been patched by the vendors after I discovered them and reported it. It appears to be very hard (or perhaps impossible) to find anything about it at the vendors web sites though. Therefore I cannot tell you exactly which versions are patched and which ones are not, but any version released in 2012 should be ok. Since there haven't been many vulnerabilities reported in whitelisting software yet I thought it might be interesting for you with these two illustrative detailed examples:

The vulnerability in SE46 from Cryptzone:

"An EXE file starts with the letters 'MZ'. The first thing SE46 does is to look at these two bytes. If they are present it goes on to check for other things, like the PE header. If they are not present it takes a look at the extension of the file. If the extension is not BAT, CMD, COM or EXE it lets the file through for execution by Windows. How can we take advantage of this implementation? One way is if we have a file with native x86 code that does not start with the letters 'MZ' and does not have one of the four extensions. There is a kind of executable file that does not start with 'MZ' since it is completely headerless. It is the 16-bit COM file from MS-DOS. We can assemble any 16-bit COM file we wish and try to execute it. It will pass through the file header check, but it will be caught at the file extension check. All we need to do now is find an extension that Windows accepts as executable but which is not in the SE46 shortlist. PIF (Program Information File) is such an extension. Now we can run any 16-bit COM file just as long as we make sure it has a PIF extension. We can even let our executable rename a few core components of SE46 if we are running on a sufficiently privileged account. After the next reboot SE46 is no longer active on the computer and we can execute any file we wish without a single restriction."

The vulnerability in Application Control from McAfee:

"Application Control first of all checks if the file has a valid header, including the PE header, or not. If the header is not valid the file is let through to Windows for execution, presumably because it is assumed to be non-executable. This time, remember that the location of the PE header is specified at position 3Ch (hexadecimal) in an EXE file. The location is specified by a four byte long value, so that the positions 3Ch, 3Dh, 3Eh and 3Fh are used for this purpose. Now we create a file that is so small that it is missing the position 3Fh. This means that the file is really too small to be a PE-style file. Next, we set the legacy EXE header size to zero. Now it looks like the file is missing a legacy EXE header too. However, there is still the problem that the file ends with the extension EXE, so instead we change it to SCR (screensaver). If we execute such a file in Windows, without Application Control installed, it will execute despite all these problems. It will look like a legacy EXE file to Windows, and the execution will start from the very beginning of the file, with the letters 'MZ'. Fortunately these letters are in fact executable too, because when interpreted as machine code instead of as text, they mean something at least remotely comprehensible to the CPU. Next, the execution continues with the other items in the header. If we pick the right values for these we can make sure that the values are on the one hand executable, and on the other hand mean something as header values too. We also have more space following this, to the end of the file, where we can insert any code we like without worrying about what it means value-vise. Now we have a file which executes as a 16-bit legacy EXE file in Windows. If we run it in a system protected by Application Control it will execute whether it is in the whitelist database or not. Application Control finds the file invalid and simply passes it on to Windows for execution."

As I wrote in the beginning of the mail, both vulnerabilities have already been patched by the vendors.

Arne Vidström
Swedish Defence Research Agency (FOI)
http://www.foi.se/en/Our-Knowledge/Information-Security-and-Communication/Information-Security