1. C++ Catastrophes “if C allows you to shoot yourself in the foot, then C++ is giving you a machine gun!”
James Prince

2. Types of attacks
Classes that contain corrupted function pointers that can cause program flow to be tampered with.
Altering the virtual function pointer table (vtable) and automatically generated constructors, deconstructors, and assignment functions
The type of bad programming habits I will discuss focus around…
Windows, & OSX pass around a lot of function pointers and c++ is a commonly used code to work with GUI code, if the class containing a function pointer can be corrupted, program flow can be altered
the pointer to the vtable can be altered, which leads directly to running the code of the attackers choice

3. Sinful behaviors Leading to those attacks
Array new and delete mismatching
Not having proper constructor, deconstructor, copy and assignment declarations
Bad Pointer initialization
Lack of C++ Standard Library knowledge

4. Array new and delete mismatching
Know the difference between “New” and “New[]”
New – declaring one object
New[] – an array of objects
char* pChars = new char[32];
// ... some code
delete pChars;
Will only see this is poorly tested error handling code
NOTICE you are creating a char array with 128 objects but calling the delete function for a single object
the new[] operator needs the count to know how many times to call the constructor,
the delete[] operator needs the size to know how many times to call the deconstructor.
In a 64-bit system, an array of objects has the count of objects the first 8 bytes before the first object,
In a 32-bit system, an array of objects has the count of objects the first 4 bytes before the first object,
0x B0: cd cd cd cd fffff
Number of objects = 32
First object

5. When delete is matched with new[]
Instead of looking at the bits containing the count of objects it looks at the first 8bytes.
Recent OS will crash but there are still many types of heap implementation that have different behaviors.
Delete is suppose to delete a single object but..
0x B0: cd cd cd cd fffff
Incorrectly deletes this “object”

6. When delete[] is matched with new
Assumes the count precedes the object you wanted to delete
It will call the deconstructor some number of times instead of just once.
If the heap is a custom heap, the memory adjoined in either direct could be attacker-controlled.
Also, if an attacker can overwrite the count of objects, then you should assume an exploitable condition.
This leads me to the next vunerability….
0x B0: cd cd cd cd fffff
deletes whatever number of objects this is

7. Methods Automatically enumerated
Constructor and destructor:
Foo()
~Foo()
Assignment operator and copy Constructor:
Foo& operator= ( const Foo& rhs )
Foo ( const Foo& rhs)
class Foo {
public:
Bar m_Bar; };
Consider this, you are creating a class… (NON POD)
Plain old data types – classes that have no virtual methods and a trivial destructor

8. Foo foo2( foo1 ); // copy constructor Foo foo3 = foo2; // assignment
// Pass by value invokes copy constructor
ParseFoo( foo3 );
This code would invoke all of those methods (const, deconst, copy, assign)
So why is this bad?

9. public: DumbPtrHolder(void* p) : m_ptr(p)
class DumbPtrHolder {
public: DumbPtrHolder(void* p) : m_ptr(p) }
~DumbPtrHolder() { delete m_ptr; }
private: void* m_ptr; };
The attacker could take advantage of “double-freeing”. This is when the same memory location is freed twice,
This allows the hacker to overwrite a properly initialized or uninitilized class in memory.
So an uninitialized portion of this class could be attacker-controlled.
This is an example of careless programming
When an instance of this class is instantiated, the default constructor is called and uninitializes the value of m_ptr,
This creates a double-free condition, and if malicious code was placed into the object encapsulated within the class, it could be executing arbitrary
code.
So it is bad to partially initializing the class
NOTE: Also if you are doing too much work in the constructor, that throws a lot of exceptions, there is no way to know how much of it was really initialized.
So it would be best to use an Init() method, it would guaranteed to have completely initialized everything before the constructor itself is called

10. class Foo { public: Bar m_Bar; }; class Foo { public: Bar m_Bar;
private: Foo( const Foo& rhs ); // copy Foo& operator=( const Foo& rhs ); // assignment };
So we can
Counter this by declaring private copy constructor and assignment operators,
If an external class invokes them, compiler will get an error,
if your class invokes them you’ll get a linker error,
write methods that explicitly transfer ownership from one class to another.

11. pointers and clean up ~DumbPtrHolder() { delete m_ptr; }
m_ptr = NULL; }
Think of a “dangling pointer” as
"a pointer which still exists, even though the object it pointed to no longer exists".
Chances for a “dangling pointer” condition
A (non-NULL) pointer that points to unallocated memory
Pointer set to NULL
Worst case, a benign crash or no-op

12. Failure to properly Initialize a pointer
To be safe, always initialize pointers to null
Don’t assume a function will always initialize a pointer to something valid or null
Foo* pFoo; if( GetFooPtr( &pFoo ) ) { // some code } // If pFoo is uninitialized, this is exploitable pFoo->Release();
Pointer could be pointing to unallocated space with malicious content
Code review should catch this kind of error

13. Conclusion Code review Study C++ STL
Be careful using Array new and delete mismatches
Shoddy copy, assignment, constructor, and decontructor declarations and bad member initializations.
Failure to reset internal pointers on deletion.
Bad pointer initlization.
Use the strictest compiler warning settings
STUDY STL - Use an iterator for traversing through arrays, you cant go off the end.

14. Sources
Howard, Michael, David LeBlanc, and John Viega. 24 Deadly Sins of Software Security: Programming Flaws and How to Fix Them. New York: McGraw-Hill, Print.