As part of an ongoing security in partnership with Microsoft Readiness is working on application installation focused security issues.
Readiness may not be a dedicated security services group, but we really do know “a little about” application installations. As we delve deeper into the ongoing security challenges with modern desktop and server platforms, we are finding new/novel ways to extend our existing platform and help with both security related assessment and remediation issues. This posting will focus on one in issue in particular: the overlap between files contained in a Microsoft update and privatized (or application specific) files in an application directory.
In simple terms:
Readiness believes that there is a significant security risk with applications that ship core OS DLL’s (kernel.sys or GDI.DLL) in their applications. These files belong in the OS, and should be maintained and updated by Microsoft through regular, system level update processes.
Why would an application developer (ISV) do this? Why would Bloomberg put a core operating system library (like GDI.DLL) in their application install. There are few reason:
- Quicker, easier testing across platforms and OS versions
- Internal application security profiles/protocols
- Application stability (due to OS updates)
Private .NET installations put core system files into private or unmanaged directions – usually within an application’s “private” or application specific directory. This means that if these libraries are updated, Microsoft will only update the files in the OS directory (e.g. SYSTEM32) – the DLL’s and libraries in the application specific directories will remain unpatched and vulnerable.
Microsoft describes private assemblies as,
An (.NET) assembly that is deployed with an application and is available for the exclusive use of that application. That is, other applications do not share the private assembly.
There are some real benefits to developing your applications with isolated or private assemblies including:
- Isolated applications can be more stable and reliably updated because they are unaffected by the installation, removal, or upgrading of other applications on the system. Especially OS level updates.
- Isolated applications can be developed so that they always run using the same assembly versions with which they were built and tested.
Here are some examples:
- Business Objects contains OLEAUT32.DLL (the magic behind cut and paste)
- US Federal Governments/EPA TANKS contains SQLOLEDB.DLL (used/abused for SQL queries)
This makes testing and deployment easier. But what about security?
Noting that both OLEAUT32.DLL and SQLOLEDB.DLL were updated last month with critical zero-day vulnerabilities. Microsoft updated the target OS (both server and desktop) but the applications contained files/libraries/DLL’s that were publicly compromised and exploited. These were two very serious security issues.
What does this mean? If your applications contain these older/legacy files, updating your OS without updating your applications is (almost) a waste of time. Ready for a car analogy? It’s like locking your car but leaving your keys on the hood.
There is a solution. Scan your applications for:
- Private directories and libraries
- OS library/files/settings in your application installation
- File level overlaps with Microsoft updates
Readiness is here to help. It’s an automated process and updated with each Microsoft patch, change or update.
