As we've talked about previously Secure Development Life-cycles are neither easy or cheap, contrary to what you may have heard. This is why we've previously proposed the idea of 'Secure Mindfulness' as a more agile / lightweight way to lessen the likelihood of the inevitable security car crash without stifling a teams productivity or having to invest Greece's deficit in security.
In order for security to scale we need to get the basics right. With applications developed in native programming languages, such as C and C++, on modern operating systems such as Microsoft Windows, BSD, OSX and Linux this doesn't mean setting out to eradicate every memory corruption bug (a nigh impossible task in our opinion). Instead this means at a minimum doing those security related activities that have the highest return on investment first. An example of such an activity is utilizing the security defences provided by the operating system and developer tool chain which are cheap.
Vendors such as Microsoft and RIM (bias disclosure: I was behind this initiative at RIM) have good documentation on the features they provide and how to utilize them. The key to success however is ensuring their adoption.
We recently presented at CRESTCon (Council of Registered Ethical Security Testers) on 'Finding the weak link in Windows binaries' (we'll also being giving the talk at Source Boston). The talk covers the whats, whys and hows of identifying binaries that haven't utilized the low cost features of the developer tool chain or operating system to enhance security. We think these assurance exercises should be undertaken as part of many different types of security assessment, software QA and procurement activities; but that's a subject for another post. At the high-level what we've observed is if a feature has to be turned on as opposed to it being on by default then the likelihood is it won't be used unless the development team are either security aware or it's easy to so.
So to the reason for this post; product installers and turning on some extra security defences in a simple manner. If you're trying to make a secure product, then security activities aren't confined to certain groups of developers. Security starts with the development team who write the product installer. Why? you may ask. Well, in the case of Windows there are three defences that applications can opt into (there are some caveats around the server product line here) via modifications to the registry:
- DLL Planting Mitigations.
- Safe SEH Overwrite Protection - more technical details here.
- Force ASLR On - Although you might want to read our small print.
To encourage and ease adoption we've released today, under the BSD license a developer support tool: RECX Installer Defence. Simply put, we're making the process of turning on these features extremely easy. In the download you'll find:
- RecxInstallerDefence.h - Header file for you to include in your install/product with a simple function to call
- RecxInstallerDefence.cpp - Source code to RecxInstallerDefence.exe / example of calling the function
- RecxInstallerDefence.exe - Command line tool so if you're not a developer, or you want to script your installs or alternatively want to perform host lock down.
For developers RecxInstallerDefence.h has the following function:
// // Function : ProtectImage // Takes : String - Image name i.e. 'Foo.exe' // Boolean - Force ASLR on - Windows 7 client // Boolean - DLL planting mitigations - Vista onwards // Boolean - SEHOP protection - Windows 7 client // Returns : 0 on success // > 0 on failure // DWORD ProtectImage(TCHAR *strImageName, BOOL bForceASLR, BOOL bDLLPlanting, BOOL bSEHOP)
You can then call this function as part of your installation program. For the non-developers, companies that script their installer or individuals who want to opt applications in as part of a host lock-down exercise we provide a command line tool. Running the command line tool is as simple as:
This will then turn on all three protections. The major difference between the two is that the function gives you granular control of which defences to enable, whilst the command line tool just turns them all on.
For QA teams needing to validate it has worked from the command line do the following (important output in blue text):
C:\>reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\Foo.exe"
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\Foo.exe
MitigationOptions REG_QWORD 0x300
CWDIllegalInDllSearch REG_DWORD 0xffffffff
DisableExceptionChainValidation REG_DWORD 0x0