Solve two difficult security issues
Michael Howard
Secure Windows Initiative
August 14, 2002
I often discuss some small amounts of errors you found and make people know that they are very beneficial. In this month's column, I want to discuss two themes:
Interactive service call _alloca ()
Security, service and interactive desktop
Similar to the UNIX daemon, the service is the hub of Microsoft Windows NT®, providing an important feature to the operating system and user without the need for users. When you create a service, there are some questions to pay attention.
The services in Microsoft Windows® are usually console applications, and their run does not need to participate, and there is no user interface. However, in some instances, the service may need to interact with the user. Services running in a higher security environment (such as system) should not be run as an interactive service. In the Windows user interface, the desktop is a secure boundary, any application running on an interactive desktop can interact with any window on the interactive desktop, even if the window is not visible. This is the case whether the security environment of the application of the window is created.
Due to these design features, any service that opens the window on an interactive desktop is open to the application executed by the login user. If the service tries to control its function with a window message, the login user can interfere with this function by using malicious messages.
Will the service as the System run (ie, the service is not advisable by calling the interactive desktop by calling OpenWindowStation and GetThReadDesktop). Note that the future version of Windows may completely cancel support for interactive services.
We recommend that service writers use client / server technology (such as RPC, socket, named pipes, or COM) to implement interactions with login users from a service, using MessageBox with MB_Service_Notification with interaction with MB_SERVICE_NOTIFICATION. Simple status. If your service code has any properties, please be vigilant:
Run as a localSystem and the service is tagged in the Security Configuration Manager ("Log in to" -> "Allow services and desktop interaction"), or registry key-> hklm / ccs / services / myservice / type & 0x0100 == 0x0100) CreateService, and dwServiceType & SERVICE_INTERACTIVE_PROCESS == SERVICE_INTERACTIVE_PROCESS call MessageBox (), which uType and (MB_DEFAULT_DESKTOP_ONLY | MB_SERVICE_NOTIFICATION |! MB_SERVICE_NOTIFICATION_NT3X) = 0 call OpenDesktop ( "winsta0", ...) and create a user interface in OpenDesktop on the Desktop Upset loadLibrary / getProcaddress
Be careful _alloca
_alloca functions can allocate dynamic memory in the stack. The allocated space will be automatically released when the call function exits, not just the release of an outward range. Here is sample code to use _alloca:
Void function (char * szdata) {
PVOID P = _alloca (lstrlen (szdata));
// use P
}
If an attacker provides SZDATA that is longer than the stack size, _alloca will trigger an exception and cause the application to stop. If the code is in the server, the situation will be worse. The correct way to handle this error is to package the call to _alloca in the exception handler and reset the stack when an error occurs. Void function (char * szdata) {
__Try {
PVOID P = _alloca (lstrlen (szdata));
// use P
} __except ((eXception_stack_overflow == getExceptioncode ())?
EXCEPTION_EXECUTE_HANDLER:
Exception_Continue_Search) {
_resetstkoflw ();
}
}
Related questions: ATL conversion macro
You should also be careful that some call _alloca's ATL string conversion macro. These macros include A2W, W2A, and CW2CT, and the like. If your code is a server code, you must consider the length of the data when you call any of the conversion functions. This is not easy to believe in another example of the input. If an attacker provides a 10 MB string to your code, it will destroy the stack and trigger an exception; or if it is not triggered, it will fail. So don't do this!
Discover defect
No one can see the mistake in the last week of code, but many people are close to the goal. The problem is to use the same buffer for the clear text and ciphertext. You can never do this.
At first glance, use the same buffer to store its plain text, and then the ciphertext generated by the declined text seems to be very good. This is also true in most cases. But it is not the case in a multi-threaded environment. Imagine a "competitive state" in your code, and you don't know. (Competitive status is caused by unexpected strict dependence on the relative time of the event in the software. They usually appear together with synchronous errors.) Help, you will never know that there is a serious competition, etc. It's too late. Consider your application, the normal process of your application is as follows:
Use a plain text to load buffer. Encrypted buffer. Send the buffer content to the recipient.
This looks normal. However, envision that you have a multi-thread application, for some reason, the last two steps are exchanged due to competition states:
Use a plain text to load buffer. Send the buffer environment to the recipient. Encrypted buffer.
Receiver only receives some plain text! This is a bug in Internet Information Server 4.0. In a very special load and a small number of cases, when using a security socket layer (SSL) protection from the server to the user's data channel, the server may follow this mode and send an unencrypted data packet to the user. . This potential problem is small; only one packet is sent only to the user (or possibly an attacker). And when the user receives the packet, the client software will disconnect. It is said that the problem has been fixed by Microsoft. For more information on this defect, please visit http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/ms99-053.asp.
The repair method is to use two buffers. A buffer is used in plaintext, another for ciphertext, and ensuring that ciphertext has been emptied when performing different calls.
Can you point out the error in this code?
Void shuffleandupdate (char * szname, char * szpwd,
DWORD INDEX,
DWORD D) {
DWORD DWARRAY [32];
ZeromeMory (DWARRAY, SIZEOF (DWARRAY));
Bool FallowAccess = false; if (isvaliduser (szname, szpwd) {
Fallowaccess = true;
ShuffleArray (dwarray, szname);
}
DWARRAY [INDEX] = D;
IF (FallowAccess) {
/ / Execute some sensitive operations
}
}
Michael Howard is a security program manager for Microsoft Secure Windows InitiTive group, one of the author of Writing Secure Code (English), is also the main author of Designing Secure Web-Based for Applications for Windows 2000 (English). His main job is to ensure people design, build, test, and record unfamiliar safety systems. What is his favorite, it is "short, and the inch".
