Detours is a library offered by Microsoft Research for interception of functions on x86 and x64 platforms. It is sold for commercial use to various vendors that build products ranging from security to gaming applications.
Detours is often injected into most or all of the processes, either system-wide or in the context of the logged in user. The most common way this is done is through the AppInit_Dlls registry value. Because the injection is typically applied to a large number of processes running under various permissions, extra care must be taken to ensure the library and its usage are very carefully reviewed by engineers with a strong understanding of the implications of such wide hooking.
We have used this library in our own security products at Cisco (both CSA and AnyConnect) to provide certain security functions on the system. During one of our research projects earlier this year, we noticed a peculiar pattern on Windows systems where processes we were hooking had a change in the in-memory permissions, which marked the headers of the modules from the normal READ/EXECUTE to now include WRITE as well.
This was quite alarming to us, because a dll should not be writeable when loaded into memory. What was interesting, and led to clues of what might be the cause, was that it was only the dlls that had functions we were actively trying to hook. They were the common Win32 dlls that one would typically intercept methods for, such as Kernel32.dll.
Read More »
Tags: DLLs, Dynamic Link Libraries, Microsoft, security, third party software
Cisco SecCon 2012 brought together hundreds of engineers, live and virtually, from Cisco offices around the globe with one common goal: to share their knowledge and learn best practices about how to increase the overall security posture of Cisco products.
It is amazing to see how many definitions the word “hack” has out on the Internet. Just look at Wikipedia: http://en.wikipedia.org/wiki/Hack. In short, the word “hack” does not always mean a “bad” or “malicious” action.
I’ve had the opportunity and honor to present at SecCon several times, 2012 being my fourth year. My session this year was titled “Cisco PSIRT Vulnerability Analysis: What Has Changed Since Last SecCon”. As you probably already know (or might have guessed), I’m part of Cisco’s Product Security Incident Response Team (PSIRT). During my talk I went over an analysis of the vulnerabilities that were discovered, driven to resolution, and disclosed during this past year, as well as lessons learned from them. I also highlighted several key accomplishments Cisco has achieved during the last few years. For example, Cisco now has the ability to correlate and patch third-party software vulnerabilities. Additionally, we have grown Cisco’s Secure Development Lifecycle (CSDL) into a robust, repeatable and measurable process. As Graham Holmes mentioned in a recent blog post:
Our development processes leverage product security baseline requirements, threat modeling in design or static analysis and fuzzing in validation, and registration of third-party software to better address vulnerabilities when they are disclosed. In the innermost layer of our products, security is built-in to devices in both silicon and software. The use of runtime assurance and protection capabilities such as Address Space Layout Randomization (ASLR), Object Size Checking, and execution space protections coupled with secure boot, image signing, and common crypto modules are leading to even more resilient products in an increasingly threatening environment. Read More »
Tags: Cisco Security, cisco-seccon-2012, CSDL, intellishield, product security, psirt, SecCon, security, third party software
The practice of using Open Source Software (OSS) and other third-party software (TPS) to build products and services is well established. Not only can it create tremendous efficiency–why build an operating system or web server if you don’t need to?–it also allows individual products to leverage best-of-breed functionality. This best-of-breed functionality can be critical on today’s Internet as security and scalability are often difficult or even patently ignored until it is too late.
The use of TPS to build things has been so successful and is so widespread that many products may even be assembled from a majority of software written by unknown third parties. This practice is not without its challenges. One of those challenges is security.
How does the security of a product’s constituent TPS affect its own security? How does the creator of the product learn of, manage and ultimately resolve security issues that originate in the relevant TPS packages?
These are the types of questions I attempted to address during a recent presentation at O’Reilly OSCON 2012. During that session I touched on seven challenges and offered five tools that I believe can make a difference.
Our friends on the Cisco Security Marketing team have posted the slides from that presentation online at slideshare.net.
Is this an area of concern for you? If it is, I’d like to know how you are tackling it. What is working well? What is working not-so well?
Tags: open source, product security, security, third party software