Appendix G: SDL Requirement: No Shared Sections
Binaries that are shipped as part of the product must not contain sections marked as shared, which are a security threat and should not be used. Use properly secured, dynamically created shared memory objects instead.
On This Page
The Portable Executable (PE) format allows binaries to define sections—named areas of code or data—that have distinct properties, such as size, virtual address, and flags which define the behavior of the operating system as it maps the sections into memory when the binary image is loaded. An example of a section would be text, which is typically present in all executable images. This section is used to store the executing code and is marked as Code, Execute, Read, which means code can execute from it, but data cannot be written to it. It is possible to define custom sections with desired names and properties by using compiler/linker directives.
One such section flag is Shared. When it is used and the binary is loaded into multiple processes, the shared section maps to the same physical memory address range. This functionality makes it possible for multiple processes to write to and read from addresses that belong to the shared section.
Unfortunately, it is not possible to secure a shared section. Any malicious application that runs in the same session can load the binary with a shared section and eavesdrop or inject data into shared memory (depending on whether the section is read-only or read-write).
To avoid security vulnerabilities, use the CreateFileMapping function with proper security attributes to create shared memory objects.
Detecting Existing Shared PE Sections
You can use the following linker directive to create a shared section:
The following directives in C/C++ source code can be used:
// (this introduces a new PE section) #pragma data_seg(".shared") int mySharedData = 1; #pragma data_seg()
#pragma section(".shrd2", read, write, shared) __declspec(allocate(".shrd2")) int mySharedData2 = 2;
This documentation is not an exhaustive reference on the SDL process as practiced at Microsoft. Additional assurance work may be performed by product teams (but not necessarily documented) at their discretion. As a result, this example should not be considered as the exact process that Microsoft follows to secure all products.
This documentation is provided “as-is.” Information and views expressed in this document, including URL and other Internet website references, may change without notice. You bear the risk of using it.
This documentation does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes.
© 2012 Microsoft Corporation. All rights reserved.