Since these two functions deal with conversion, the size of MultiByte and WideChar buffers are expected.  In addition, upon successful return, the number of converted characters is also returned.  These three counts must be carefully provided in order to ensure security.

Rules of thumb
1. MultiByte parameters always expect byte counts, the number of bytes in the corresponding buffer
2. WideChar parameters always expect character counts, the number of wide characters in the corresponding buffer
3. Return value follows rule #1 or #2, depending the type of output

Let’s study a bad example to illustrate some common errors.

wchar_t wstrTest1[] = L"123456789";
    char strTest1[9];

    int result = WideCharToMultiByte(CP_UTF8, 0, (LPCWSTR) wstrTest1, sizeof(wstrTest1), strTest1, sizeof(strTest1), NULL, NULL);

Using sizeof() seems reasonable for both parameters, as WideCharToMultiByte expects size of the corresponding buffers.  sizeof() returns the byte count of a buffer.  Following the rules of thumb, let’s find the bug. 

The bug lies in the count of wstrTest1.  It expects the number of wchar_t characters, rather than the byte count.  The proper value should be character count, not byte count, therefore, sizeof(wstrTest1)/sizeof(wchar_t).

The correct call should be as follows:

int result = WideCharToMultiByte(CP_UTF8, 0,  (LPCWSTR) wstrTest1,
sizeof(wstrTest1)/sizeof(wchar_t),
strTest1, sizeof(strTest1), NULL, NULL);

What is so bad about getting the count wrong?  It is possible to cause buffer overflows.  Considering MultiByteToWideChar, destination count is expected to be the count of wchar_t.  If the actual size is used, destination size erroneously doubles.  MultiByteToWideChar would gladly copy data up to double the size of the valid buffer.  As a result, buffer overflow occurs.

A couple functions that are almost as dangerous are still lurking without corresponding safe versions.  They are MultiByteToWideChar and WideCharToMultiByte, which are used for translating strings between Unicode and ANSI.  https://msdn.microsoft.com/en-us/library/cc500362.aspx.  Similar to strcpy, they are dangerous because they are not guaranteed to produce null-terminated strings.  Unlike strcpy, they return 0 when destination buffer is not large enough.  Even though they perform size checks, I will explain the security pitfalls of using MultiByteToWideChar and WideCharToMultiByte. 

The first installment focuses on the possibility of producing non-null terminating strings.  Let's start with explaining the return values of MultiByteToWideChar and WideCharToMultiByte.  They return 0 when destination buffer is not large enough, or fails with other reasons.  They return the number of characters saved in the destination buffer if execution is successful.  Non-null terminated strings can be produced by both successful and unsuccessful execution of these APIs.  Let's illustrate them with a couple examples.  WideCharToMultiByte is used in all examples, as the same principle applies to MultiByteToWideChar too.

    wchar_t wstrTest1[] = L"123456789";
    char strTest1[9];

    // Case 1: Parse 2 characters without a null-terminating character
    int result = WideCharToMultiByte(CP_UTF8, 0, (LPCWSTR) wstrTest1, 2, strTest1, sizeof(strTest1), NULL, NULL);

    // Result: 2 (Success) strTest1: 2 characters long without null-terminated
    printf("Result: %d\n", result);
    printf("Converted: %s\n", strTest1);

    // Case 2: Parse all characters, which are larger than the destination buffer
    result = WideCharToMultiByte(CP_UTF8, 0, (LPCWSTR) wstrTest1, 10, strTest1, sizeof(strTest1), NULL, NULL);

    // Result: 0 (Fail) strTest1: 9 characters long without null-terminated
    printf("Result: %d\n", result);
    printf("Converted: %s\n", strTest1);

From these two code examples, it illustrates that both successful and unsuccessful execution can result in non-null terminated strings.  In the first code example, WideCharToMultiByte is asked to process two characters without a trailing null character.  WideCharToMultiByte successfully converts the first two characters, but does not terminate the output string with a null character.  This case is somewhat acceptable as "garbage in, garbage out" principle applies.

However, the second case is worse. Destination buffer is not large enough to hold translated data.  WideCharToMultiByte fails correctly by returning 0, but destination buffer is nevertheless filled with data without a null trailing character.  If destination buffer is used without checking return value, a non-null terminating string will propagate through subsequent use of the string.

Some developers are aware of this issue, and they have an elegant way of handling the return value.  They add a null character to the destination buffer at the index indicated by the return value. 

    wchar_t wstrTest1[] = L"123456789";
    char strTest1[9];

    // Parse 2 characters without a null-terminating character
    int result = WideCharToMultiByte(CP_UTF8, 0, (LPCWSTR) wstrTest1, 2, strTest1, sizeof(strTest1), NULL, NULL);

    // Some developers add this check
    strTest1[result] = NULL;

    // Result: 2 (Success) strTest1: 2 characters long and null-terminated
    printf("Result: %d\n", result);
    printf("Converted: %s\n", strTest1);

When WideCharToMultiByte fails, it returns 0, and strTest1[0] is set to NULL.  It is a reasonable outcome because failed execution should return an empty string.  On the other hand,  When WideCharToMultiByte succeeds, it returns the number of characters written to the destination buffer. strTest1[result] means that a null character is appended to the return string.

The above code works very elegantly in most cases, except a boundary case.  It is always the boundary case, isn’t it?  It has a subtle non-exploitable buffer overflow bug.  What happen if the return value is equal to number of characters allowed in the destination buffer? 

When that occurs, a null character is written past the end of the destination buffer.  It can potentially destabilize the system and cause denial of service. There are many ways to fix this issue.  A fix is to add a conditional statement to handle where return value is equal to the number of characters in the buffer.  Another fix is to increase the size of destination buffer by 1 to accommodate the extra null character.  This example illustrates the first fix.

    wchar_t wstrTest1[] = L"123456789";
    char strTest1[10];

    // Parse all characters
    int result = WideCharToMultiByte(CP_UTF8, 0, (LPCWSTR) wstrTest1, 10, strTest1, sizeof(strTest1), NULL, NULL);
    if (result == sizeof(strTest1))
        strTest1[result-1] = NULL;
    else
        strTest1[result] = NULL;

    // Result: 10 (Success) strTest1: 9 characters long and null-terminated
    printf("Result: %d\n", result);
    printf("Converted: %s\n", strTest1);

Developer Checklist

1. Always check the return values of MultiByteToWideChar and WideCharToMultiByte.  If not, code reviewers should file them as bugs
2. Adopt the suggested fixes if you don’t need any custom error handling

There are more common pitfalls related to using these two APIs.  It will be in the next installment.

Podcasts

Security Now (https://www.grc.com/securitynow.htm)

CNet Security Bites (https://securitybites.cnet.com)

Blogs

Schneier on Security
https://feeds.feedburner.com/schneier/fulltext

Security Vulnerability Research & Defense
https://blogs.technet.com/swi/rss.xml

The Microsoft Security Response Center (MSRC)
https://blogs.technet.com/msrc/rss.xml

Dark Reading
https://www.darkreading.com/

The Security Development Lifecycle
https://blogs.msdn.com/sdl/rss.xml

Microsoft Hackers blog
https://blogs.msdn.com/hackers/

MS08-067 fixes a vulnerability in the Server service that would allow malicious code to remotely execute code on successfully exploited computers.

This impacts all versions of Windows.  Bug severity is critical for platforms other than Windows Vista and Windows Server 2008.  For Vista and Windows Server 2008, its severity is important.

For more information, please refer to https://www.microsoft.com/technet/security/bulletin/ms08-oct.mspx.

Every second Tuesday, MSRC releases security patches for Microsoft products that have fixed vulnerabilities.  The best is to have no patches for patch Tuesdays, and many administrators can take a break from installing patches across their server farms and enterprise desktops.  It will be a long road ahead before Microsoft can get to zero security bugs for all products.

Before reaching the elusive zero-bug milestone, Microsoft continues to innovate on security bug release process to better inform the public of those vulnerabilities so that administrators can make informed decisions on their patching schedule.

From October 2008 patch Tuesday, Exploitability Index will be associated with each bulletin.  Exploitability index is a number from 1 to 3 to indicating exploitability, with 1 being the most serious in terms of exploitability.

Here is another data point to measure risk and decide on priority of patching for any given bulletins.

I had a very strange networking issue last weekend.  After connecting to corpnet via VPN and direct hookup, I was able to ping all remote servers, but was not able to do anything, such as web browsing and remote desktop.  It was not the first time that I faced this issue, and helpdesk told me that IPSec settings may have messed up.

The following set of commands has helped me flush settings related to networking and IPSec, and restored my corpnet connection in both situations.

1. Launch a DOS command prompt
2. netsh int ip reset all
3. netsh winsock reset
4. ipconfig /flushdns
5. nbtstat -RR
6. gpupdate /force

Akin to "Ctrl-Atl-Del" of your networking settings, this series of commands should flush IP interface, DNS, Winsock, NetBIOS and group policy settings. 

Good luck to troubleshooting your networking and IPSec issues.

During my security reviews, I routinely find that many web applications turn on ValidateRequest (It is on by default), and do not follow XSS mitigation techniques, such as output encoding by HTMLEncode or ACE Anti-XSS library.  They believe that ValidateRequest can fix all XSS problems.

However, there are a couple downsides of relying on ValidateRequest:
1. ValidateRequest may miss some crafty inputs.  Please read MS07-040 for a recent MSRC fix on ValidateRequest.

2. ValidateRequest cannot be turned on in all cases, as characters that trigger XSS may also be needed in valid user scenarios.  For example, AJAX transmits XML blobs between client and server, but ValidateRequest will throw HttpRequestValidationException as it contains "dangerous" characters, such as < and >.  Exchange 2007 OWA cannot run with ValidateRequest turned on. 

In conclusion, ValidateRequest should be turned on if it does not block valid user scenarios.  However, even with ValidateRequest turned on, it MUST not be regarded as a sure-fire way to mitigate XSS.  Please read https://msdn2.microsoft.com/en-us/library/ms998274.aspx for full XSS mitigation.

Let me illustrate a picture from https://www.devx.com/MicrosoftISV/Article/34934

MOICE converts Office 2003 documents of supported types to Office 2007 XML formats (Metro) in an isolated environment.  Granted that the same conversion engine is used in the Microsoft Office Compatibility Pack, how does running in an isolated environment enhance security?

Think of wearing pads and helmets while playing American football.  It is the nature of American football that players will get hit hard.  Wearing pads and helmets does not change the nature of American football, but it does lessen the chance of inflicting serious injuries on players

The same principle applies to MOICE.  MOICE does not alter the fact that malicious documents are out there to exploit vulnerable machines.  MOICE is like a pad and a helmet to reduce the chance of Office softwares being being exploited.  Exploitation may still happen, but isolated environment provided by MOICE reduces possible damages inflicted by the malicious documents.

In addition, applying MOICE is as simple as putting on a pad and a helmet.  MOICE can be installed as a recommended update via Microsoft Update, and execution of ASSOC replaces regular rendering with MOICE.  For more information, please visit https://support.microsoft.com/kb/935865.

Last but not least, MOICE is not a replacement of properly patching your machines.  Now, go patch your machines, enjoy a cup of MOICE and most importantly, don't click on suspicious Office documents via emails.