Dangling pointers occur when a programmer creates, uses, and then frees an object in memory, but does not change the object's pointer value accordingly -- in this case, to a null pointer. Instead, the pointer inaccurately refers to the memory location of the de-allocated memory. The pointer is considered to be "dangling" since it points to memory that may no longer hold a valid object. Because the memory may contain completely different data, unpredictable behavior can result when a programmer mistakenly dereferences the pointer to access the object.
Experts at online risk management company
And we have seen how damaging and effective buffer overflow attacks can be. Corrupted data structures, information leaks, privilege escalation and execution of malicious code are all possible exploits when an attacker meddles with computer memory. Although dangling pointers can probably be found in most mature applications, hackers are going to focus on Web server applications because they often contain a high volume of sensitive data.
Smart pointers are popular data types that can better manage memory. A smart pointer typically uses reference counting to reclaim objects. Reference-counting mechanisms calculate the smart pointers that refer to the same object, and once the count equals zero, the object is deleted.
Some other defensive measures include the "tombstones method" and the "locks-and-keys method." Once an object is dead, an associated tombstone can provide automatic nullification of any pointers that may be referencing it. In a locks-and-keys scenario, pointer access is determined by comparing the two values of a pair of ordered keys. Other available products like Valgrind, a suite of debugging equipment, and the Boehm-Demers-Weiser garbage collector, a tool that cleans up code, can also help prevent dangling pointers.
Since dangling pointers can no longer be considered a benign problem, developers need to adjust software development processes so that dangling pointers are prevented from reaching production code. Because the problem may become too serious to leave until the quality control stage, protective measures should be placed earlier in the development lifecycle. With high-level languages, the process will be relatively straightforward. For those developing and maintaining programs in other languages, relying on the above-mentioned best practices is recommended.
About the author:
Michael Cobb, CISSP-ISSAP is the founder and managing director of Cobweb Applications Ltd., a consultancy that offers IT training and support in data security and analysis. He co-authored the book IIS Security and has written numerous technical articles for leading IT publications. Mike is the guest instructor for several SearchSecurity.com Security Schools and, as a SearchSecurity.com site expert, answers user questions on application security and platform security.
This was first published in September 2007