Comodo Launches Memory Firewall

By diademed at 9:39 pm on January 21, 2008 | 1 Comment

Dark Reading reports that Comodo, an security interest group / company has developed and released a memory firewall, purported to block 90% of all buffer overflow attacks, as well as several other common attack vehicles. Comodo also markets several products, including the standard suite of anti-virus, network firewall, and anti-malware, as well as consulting and network monitoring services.

The prospect of a ‘firewall’ that a user can run to prevent attacks on various types of buffer overflow attacks is really quite exciting. Presumably working by blocking execution of code in invalid memory regions (namely the stack or the heap), it holds the potential to be an excellent preventative measure for anyone concerned about the security of their applications.

While the product is just out of beta, and information and reviews hard to find, such an application brings to light some interesting issues regarding performance, security, and trust. In order to detect attempted illegal execution locations in an arbitrary virtual memory space, the firewall would likely need to be run with elevated permissions. In addition, peeking into foreign virtual memory spaces will have some performance impact, however small, which may or may not be a significant impact to performance-critical applications.

Using the application while aware of both, or either of these issues implies a fair amount of trust in Comodo as a company. From their website, they are involved in many facets of the security world, not just developing secure applications. They disclose a fair number of partners, as well as a research program, and offer ‘services’ in both research and cryptographic expertise.  While probably most of this information is completely benign, it nonetheless opens potential avenues for vulnerabilities to manifest in a company that provides you with a program to be run at elevated permissions.

Filed under: Current Events1 Comment »

1 Comment

  • 1
    Get your own gravatar for comments by visiting gravatar.com

    Comment by cbhacking

    January 22, 2008 @ 1:42 am

    Marking the stack (and heap) as non-executable is a feature supported in hardware by modern processors, and Windows XP and above also support this in software for systems with older CPUs (presumably with the performance hit mentioned in the post).

    My guess is that this “firewall” does considerably more than that – possibly monitoring the size of memory allocations and blocking attempts to write over allocation boundaries, or providing checks called ‘canaries’ (after the birds used by old-time miners as warnings of poisonous air) consisting of inserting a known value into memory at a location likely to be overwritten by a buffer overflow, then checking that value to ensure it hasn’t changed.

    It might even add a feature found in a few operating systems (Vista, OS x Leopard, OpenBSD) called Address Space Layout Randomization, which munges (usually a simple XOR mask) the addresses where linked resources (.dll, .a, .so, and executable files) are placed in memory, then XORs the function pointers in an executable when it is loaded. Since the mask is random and changes on every reboot, the attacker can’t easily execute an attack (typically known as a “return-to-libc”) where the return address is redirected into an executable function in a program’s memory space – such as the C library most programs link against – to get around data execution protection (with ASLR, the address that might normally point to the entry point for the execve method – or anything else the attacker wishes to do – instead probably points to an invalid location resulting in the program crashing).

    Alternatively, it might function like some network firewalls and watch for intrusion signatures – things like shellcode, long NOP strings, the stager used by programs such as metasploit to retrieve large payloads, or the payloads themselves – and block those. This has the advantage that even if some completely new form of attack is discovered, if it uses a recognizable paylod it will still be stopped. It has the disadvantage that, like anti-virus definitions, it will always need updating as new attack code is discovered, and still not know about the most recently developed versions.

    Finally, there are two additional risks here: like network firewalls (and most other security measures in common usage), this has the potential to block valid programs (Windows provides an option to disable data execution prevention for programs that intentionally execute code in their own data memory spaces, for example), and if (as seems necessary) it can look into and even access the memory spaces of other programs, it must be running as ring 0, that is to say kernel-level code. This has several important implications beyond those outlined in the post: if such an application gets exploited itself it can do literally anything with the system (including direct hardware access, which even a root process must go through the OS for), and if it crashes it may freeze the entire computer (just as happens with kernel-mode device drivers and antivirus software).

RSS feed for comments on this post