Friday, December 20, 2013

I have reverse engineered this patch and its effects on keyboard layouts a bit. The patch works by shipping a new version of win32k for XP and Server 2003 that pay attention to a registry key. When this registry key is added, it restricts loading of keyboard layouts to the System32 folder (already done in Vista and later). This prevents further exploits on the keyboard layout loading code. This is the first part shipped in KB2676562.

The second part is a patch (KB2686509) that adds this registry key. Before this registry key is added, a DLL called kblchecker.dll is loaded that is shipped inside the patch. This DLL is supposed to enumerate all the keyboard layouts on the system and make sure they are all in the system32 folder because any other keyboard layout DLL is going to be disabled by this update. What I found out by black box testing this patch is that any registry key value (not subkeys or any value inside a subkey) in the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Keyboard Layout key regardless of name is going to make this check fail with no FaultyKeyboards.log being created, which looks like a bug. The reason MS is not fixing this bug is probably because all it does is makes the installation of this patch fail.

Tuesday, August 27, 2013

Word formats dating to Word 1.x for Windows and Word 4.x for Macintosh and Excel formats dating to version 2.x (with exception of Microsoft Excel Chart (.xlc)) can be opened by changing File Block policy even in Office 2013 for Windows. Old PowerPoint formats however required separate translators. These translators was shipped with PowerPoint 2003 and earlier (though disabled by default in SP3), but no longer ships with 2007 or later. The name of these translator DLLs are PP4X322.DLL (for PowerPoint 4.0 and older) and PP7X32.DLL (for PowerPoint 95).

We ask MS to:

Ship these DLLs separately from PowerPoint 2003 along with a utility to call them, to provide users with a way to read these old formats.

Consider opening the source to the translators. This will save MS the work of documenting these old formats.

Sunday, July 14, 2013

From http://www.satzansatz.de/cssd/pseudocss.html#fltadjacent:
"Now, when such a .ipsum construct gains "layout" by a subset of layout properties (position: absolute; / float: any value; / display: inline-block; / zoom: 1;), what will happen? Right. Some will have to cancel the frozen process, others will have to reboot, data gets lost. Don't do it. (No, I don't link to a testcase here. IE7b3 is still crashing after scrolling/resizing. Depending on the memory already burned, you might have difficulties to stop the process...)"

I created this test manually (save http://www.satzansatz.de/cssd/pseudocss/pseudocss_t004.html and add zoom: 1 to .ipsum) and not only this bug is still in final IE7, I also noticed that there is also a potentially exploitable crash bug by opening the about box after opening this page. When this happens, it crashes with EIP at an invalid address.

After this, by adding onclick="window.showModalDialog('target.htm')" to <p class="ipsum">, creating the target.htm, then opening the page and clicking inside the box, I triggered various crashes including attempts at executing data (note that IE7 do not enable DEP by default) and heap termination on corruption.