For C/C++, when people say code is insecure, does it mean the application will crash, or it can be abused to launch cyber attack?

Question

I have seen in many instances when people say codes are "insecure".

• Accessing an array beyond bound is "insecure".
• Malloc without free is insecure.
• Dangling pointer is "insecure".
• No bound checking user input is "insecure".

In the above example, I understand in the fourth instances, under specific context, such as if you are writing your code to check the user input against a password database, your code can be abused to cause a buffer overflow and allow fraudulent user to authenticate. However I don't understand how your code can be abused in the other cases to endanger the user's computer.

Can I know when people say "insecure", is there any chance they really mean either your program can be abused for an attacker's gain, or your program can crash?

Answer 1

Invocation of undefined behavior is always insecure. The first item (array access our of bounds) is automatically in that category. The fourth is just an example of the first, conditional on user interaction (those pesky users). I.e. the potential to overreach an input buffer has the potential to invoke undefined behavior, and therefore insecure.

That leaves the middle two.

Failing to free dynamic memory will eventually lead to operational failure, as the OS will (usually) terminate such a program, under its rules, not yours. When and how this happens isn't the concern; that it can happen at all is a big concern. This is an ingredient of "crappy code", but moreover has the potential for a security issue. Whatever conditions are required to repeat the leak need only be done with extreme prejudice until such time as the OS tears down the application, and with that you have a DoS (denial of service) accomplishment.

Dangling pointers are just UB laying in-wait. They are yet-more ingredients in crappy code. Just sitting there, they don't do anything. However, they present an opportunity for such a problem when they are dereferenced. Once that transpires it joins the first and fourth items in the basket of UB, and is therefore automatically "insecure". It can also become problematic when the value of the pointer itself is treated as a state unto its own, though that is highly situational and rarer than the simple dereference workflow.

The short answer is: all UB is automatically insecure. Two of the four items present instantly fit into that basket. A third potentially fits into that basket under the right usage conditions. The fourth (failing to free memory) is a flat-out bug that will eventually lead to process termination outside the purview of you, the code author, but is enhanced if exploitable to promote a DoS conclusion.

The super short answer: Don't write code that invokes UB, and don't write crappy code in-general.

Answer 2

malloc without free, and dangling pointers, result in memory leaks. If you leak too much memory, it will cause the program to use excessive memory. If it uses too much memory, it might crash, it could cause performance problems on the system because other applications can't get the memory they need, or it could even cause the system to run out of virtual memory.

These types of issues are mostly a concern for long-running applications like servers. Imagine a server that runs constantly, leaking a megabyte every hour. That's a gigabyte every 40 days.