More Mysteries of the Win32 MessageBox Bug Revealed

Continued tests by BetaNews on the form of the Win32 API message box call discovered two weeks ago, capable of crashing Microsoft Windows Vista as well as earlier versions, indicates that while the executable code remains a problem, its capacity for damage to Windows computers may be limited to merely crashing the system.

Last month, security engineers discovered the latest incarnation of a problem first encountered eight years ago: When an API function dating back to the first version of the Win32 library tells the system to display a dialog box as though it were coming from the OS itself and not the active application, and when the text to be displayed in that message box appears to contain what may be a disused character code sequence, then memory becomes corrupted. At least one, sometimes more, repeated calls can cause Windows to crash.

But if memory is corrupted, can it be exploited, and for how long? BetaNews' tests on clean, virtual Windows XP and Windows Vista environments indicate the answers are as follows: Probably not, and if that proves wrong, for not long at all.

First, however, it's important to note that our latest tests could not replicate the same problems we encountered during our first runs: specifically, a corruption of the security event logs. In Vista, this particular set of logs is only accessible to an account with administrator privileges; not even User Access Control can elevate a "Standard" user to "Administrator" level to enable him to see this log. For this task, a user must formally log onto an administrator account. (Even then, curiously enough, the admin user, if policy restricts him, may be forced to "elevate" his own privilege anyway before viewing the security logs, either by clicking on Continue or by signing in at the logon prompt.)

But after our first set of tests in a virtual Vista environment, even our admin account was denied access to the Security logs after just one run of the compiled, intentionally buggy code. Furthermore, the standard user account from which the buggy code was run, could not then gain access to its own system folders, including Documents (Vista's equivalent of "My Documents" in XP).

To determine whether this problem was chronic, we started out with a clean, new Vista environment, without installing any new applications (our first Vista environment did have Office 2007 installed). After making only policy changes to UAC to help secure the standard user account, we ran our test code again. Though it continued to crash Vista, this time, it did not corrupt the security logs, or lock out access to the Documents folder. Successive tests yielded similar, non-damaging results.

Also, after our initial report, we received some advice from Muj Beg, a professional developer for a healthcare firm who has made periodic posts of advice and requests for help to the MSDN forums. In our earlier report, we suggested a macro was necessary to help convert the message box contents string from 8-bit to 16-bit characters, as now required by Unicode. As Beg demonstrated, we could also make a change to the Visual Studio project settings, to allow for multi-byte character strings, while making a much more minor adjustment to the proof-of-concept code than our major macro. To quote a wise man...D'oh!

So with much thanks to Beg, that's what we did, and with a more minor adjustment in hand, we compiled a cleaner version of the bug code. In a new set of tests in our virtual Vista environment, we discovered some interesting facts: First of all, the initial call of the MessageBox function that causes the memory corruption, sets the stage for a crash just waiting to happen. It does not necessarily take a repeat of the same call to trigger the crash; some other function, such as starting up Notepad, may incur the wrath of the Blue Screen of Death.

In Vista, only the admin account is told that the system recovered from a serious error; the standard user, once logged back on, receives no such message. The security logs, though present, don't actually reveal anything about this particular problem; it only shows the results from periodic security audits, the cycle of which was notably broken by the unexpected shutdown. But those events (which Vista codes as "event ID: 6008") were recorded in the System event logs, with their time cues set to the time of the virtual system reboot. In our initial tests, these event codes had not been recorded, leading us to believe there may have been other intervening factors exacerbating the effects of those initial tests. The system event logs are visible to both standard and administrative users.

One of the more curious observations we noted is this: In one non-virtual Windows XP environment which happened to include a language package for Japanese Hiragana script, our test of the Beg-revised code resulted in the title bar of the faulty message box revealing Hiragana script. On the Vista environment, where no such package had yet been installed, the text was merely garbaged. Perhaps the character sequence in question was originally meant to trigger an international script, or a non-Western code base.

Beg pointed us to a Microsoft page describing new message box functions in Windows Presentation Foundation, which includes a new set of customizable task dialogs intended to replace MessageBox. But while developers are being advised to use these new WPF functions instead, the Win32 API will no doubt be included with Windows operating systems for some time to come, if only for the sake of backward compatibility.

As security engineers advised two weeks ago, the memory corruption caused by this particular invocation of MessageBox could perhaps be exploitable – as they said, potentially to elevate the privilege of the active user. This last claim has yet to be substantiated, particularly in light of the fact that it is an old API call to a library embedded in Windows, not a scripting language function. While server-side includes have been developed over the years to make Win32 functions addressable from server scripts, those includes are not automatically deployed to clients. Meanwhile, assuming this faulty function truly does render Windows vulnerable, the window of that vulnerability, so to speak, is extremely narrow -- simply changing the page in the Web browser could trigger the next Windows crash.

With that said, it still appears at present that the bug that sounded the alarm bells at major US publications, including several outside the technology press, may be an effective one but not yet a dangerous or exploitable one. It's an old flaw, not an exploit.