I know that C/C++ programs are highly susceptible to overflow errors that lead to program compromise. But I was wondering, are there any other vulnerabilites that can exist other than overflow errors? I am aware of dangling pointer references, off by one and integer errors, but is there any way other than leveraging overflow errors to exploit programs? If yes, then please suggest some readings and references. Thanks

closed as too broad by Arminius, Steve, AJ Henderson, WhiteWinterWolf, Serge Ballesta Jul 18 '17 at 14:31

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • Implementing encryption incorrectly, hard coding in passwords, forgetting to sanitize your inputs, leaving development code such as back doors in... I think this is a question asking for a list – daniel Jul 18 '17 at 11:46
  • 1
    sounds ominously like a school assignment... have you googled this? – LvB Jul 18 '17 at 12:05
  • Did. With little help. @LvB. And no, this wasn't a school assignment. I was randomly trying some exploits and got the thought. – user148898 Jul 18 '17 at 12:07
  • A useful resource/link: github.com/chifflier/mind-your-languages/blob/master/C.md – Ed Daniel Jul 18 '17 at 15:15

Since C (and C++ which can be technically be considered an addition to C) is close to Assembly, Much of the details of the processor have to be modeled and controlled from within its constructions. The easiest example that shows this is the array index overflow bug. This bug entails the improper use of an array index in such a way you retrieve a piece of memory that was not allocated to said array.

int[2] arrayX;

A proper compiler will complain in the code block above about index out of scope since a static analysis of the code already shows it. You can also use dynamically created arrays that are of unknown since at compile time and there no warning will be given.

Now, when you enter a function you effectively assign a code return address into the stack. as well as locations for the return "object" in same said stack. This stack is called the call stack and should not be manipulated by the program under normal operations.

With both of these mechanics we can 'trick' a program into running our own code. we do this by adding processor instructions on a known memory location, and manipulate the call stack to change the return pointer to my injected code block. (this is called code injection).

This behavior can be triggered by an overflow error or some other mechanic to adjust the call stack, this is dependent on the OS in operation and the Hardware in use, and is the main way exploits work.

There are however exploits that exploit lower level calls than C offers (basically injecting machine code / assembly into the program code).

In C++ there are additional methods of adding code to an application, through utilization (or abusing) of the Class loading mechanics.

If you want to learn about these concepts I would suggest learning about metasploit. Reading up on how C works in detail (the c bible is a good start) and try and read the GCC compiler documents.

  • printf(arrayX[2]); would kill the app aswell :D – Jacob Jul 18 '17 at 12:59
  • yes, but is less clear as an eample ;) – LvB Jul 18 '17 at 13:39

Not the answer you're looking for? Browse other questions tagged or ask your own question.