Friday, December 20, 2013

MS12-034, keyboard layouts‏, and a bug

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

Petition to MS regarding old PowerPoint translators

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:
  1. 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.
  2. Consider opening the source to the translators. This will save MS the work of documenting these old formats.

Sunday, July 14, 2013

How I found CVE-2013-1310 in IE6 and IE7

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.

I turned full pageheap on and after I did so it crashes reliably at:

(360.51c): Access violation - code c0000005 (first/second chance not available)
eax=00000004 ebx=08042e78 ecx=0000000a edx=065acfa0 esi=08042e78 edi=065289c0
eip=3ceff096 esp=04d04ba8 ebp=04d04bf8 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
mshtml!CLineCore::AssignLine+0x37:
3ceff096 f3a5 rep movs dword ptr es:[edi],dword ptr [esi]

MS fixed this bug in the May 2013 Cumulative Update for IE6 and IE7.
Here is http://www.satzansatz.de/cssd/pseudocss/pseudocss_t004.html rendered in IE6 and IE7 before the patch:


After the patch (notice it is the same rendering as IE8+ in IE7 compat mode):

Monday, December 31, 2012

The MS OS/2 2.0 fiasco: PX00307 and DR-DOS

There are many anti-trust exhibits and other articles on the MS OS/2 2.0 fiasco and how it went from the original SDK released at the end of 1989 to "Microsoft Munchkins" and other unethical attacks (which got worse as Chicago/Win95 delayed) that was worse than the Joint Development Agreement between IBM and Microsoft (where they worked on OS/2 together) ever was. This fiasco is part of why it took 10 years after Intel introduced the 386 before 32-bit programming became popular.

But one of my favorite is PX00307, about the decision that turned 32-bit OS/2 into a fiasco in the first place. One of the red signs is that the problems of the "32-bit Windows extenders" was not even mentioned, such as no preemptive multitasking and no memory protection! Win9x fixed some but not all of the problems. For example, the Win16Mutex was used as a global mutex to simulate the Win16 cooperative multitasking system. This mutex was taken every time a 16-bit thunk was entered and was global to the system, and even most Win32 apps sometimes thunk to 16-bit (for example when calling USER32) or took the mutex for other reasons. And notice neither Gordon Letwin (the architect of OS/2) or Dave Cutler (the architect of NT) was in the To list, another red sign. Now, OS/2 had a sync input queue that made the preemptive multitasking much less useful, but that was much easier to fix and IBM hacked in a workaround in a FixPak for Warp 3.

But that is not my favorite problem with Win9x. My favorite is how Caldera used it's dependence on DOS to continue DR's lawsuit against MS, even having projects like "WinBolt" to prove it. And of course even before then, there was Windows 3.1's infamous AARD code. And guess what, OS/2 never depended on DOS. It was designed from the beginning as a full OS!

Thursday, July 12, 2012

Why the "HTML5" buzzword is a misnomer

WHATWG now consider HTML a living standard now. One reason is because no browser has perfectly matched any HTML version. In fact each browser implements "HTML5" features at its own pace. For example, <canvas> dates back to 2005, before the HTML5 term was commonly used. Even IE8 supports some features considered part of "HTML5", such as localStorage. Thus, whether a browser supports "HTML5" is almost meaningless, nor whether a page uses "HTML5". Individual features matter.

Friday, July 1, 2011

The hotfix KB972582 and how it fixes the empty dialog you see when opening "Organize Favorites" in Windows Explorer in XP when IE8 is installed

The KB article itself: http://support.microsoft.com/kb/972582

The download link: http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=972582

If you are wonder what does the title "You receive an empty dialog box when you run the "Rundll32.exe shdocvw.dll, DoOrganizeFavDlg" command on a computer that is running Windows XP or Windows Server 2003 if Internet Explorer 8 is installed" have to do with it, DoOrganizeFavDlg is the export called by BROWSEUI when clicking Tools->Organize Favorites. An update to XP SP2 and Server 2003 SP1 shipped with IE7/8 for these OSes (and incorporated into later service packs of course) updated SHDOCVW and some other related DLLs to add a wrapper to some functions that detected the availablity of IEFRAME and jumped to the IEFRAME version if it existed. IEFRAME was introduced in IE7, and it was key to separating Explorer's UI from IE's UI. Unfortunately the original wrapper for DoOrganizeFavDlg incorrectly always jumped to the original SHDOCVW version making it useless (a one-instruction mistake). This hotfix fixes that. However it does not fix the case where you show the Favorites sidebar using the menus in Explorer then you click Organize..., because in this case SHDOCVW itself calls the internal version of DoOrganizeFavDlg bypassing the wrapper. I know all this because I debugged this issue using IDA and WinDbg.

BTW, on "To resolve this problem, install the most recent cumulative security update for Windows Internet Explorer.", what this really mean is that you can solve this problem by installing the latest cumulative security update for IE6 before you install IE8 (or uninstall IE7 and IE8) to get the updated SHDOCVW.

Monday, June 13, 2011

The history of CSS - part 1

 Back in October 1994, the first draft of  "Cascading HTML Style Sheets" was released. Around the same time, what was then called Mosaic Communication Corp. released Netscape 0.9, with new tags and attributes including CENTER and FONT tags.

In December 1994, Netscape 1.0 was released. By March 1995, Arena and emacs-w3 was supporting the then-drafts of CSS. In April 1995, Netscape 1.1 was released introducing more new elements. By August 1995, Netscape 1.2 was released and Netscape has gained a monopoly in web browsers.  Other browsers (including early MSIE) had to copy the new elements Netscape introduced. And Netscape did not support CSS and had no plans to do so. In fact, Netscape with it's monopoly effectively killed HTML 3.0 which Arena and emacs-w3 also supported, preventing it from becoming a standard and forcing W3C to create HTML 3.2 instead.