Jump to content
  • Advertisement
Sign in to follow this  
madRenEGadE

Security of C++ Programs

This topic is 3944 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello, I want to know what I have to take care off when writing C++ programs when it comes to security. So what is insecure and what not? Is it only neccessary to avoid memory leaks to make a program secure or are there other things I have to look at? thx in advance

Share this post


Link to post
Share on other sites
Advertisement
Memory leaks aren't security problems.

Things like buffer overflows are; if someone can overflow a buffer, they can write into memory they shouldn't be writing to, and if the buffer is on the stack, they can do things like overwrite the return address to cause your code to execute any code they want to.

Share this post


Link to post
Share on other sites
C++ is not an interpreted language; there is no way (short of writing your own interpreter) to execute C++ code read from a file. There are no security vulnerabilities in any of the standard c++ functions (except a few C functions that were carried over to c++ -- avoid those).

As such, C++ is a very secure language if written properly.

Like you said, memory leaks and other undefined behavior is possible if code is written poorly without following the standard. But the importance of doing things right is much more than a security issue; it effects portability and repeatability -- if you write undefined code, it may not always work.

Share this post


Link to post
Share on other sites
There are a lot of different aspects of software implementation and design that could be security risks. The big one that almost everyone knows about is buffer overruns, which can potentially allow an attacker to run arbitrary code on a machine. However, there are a large number of other factors to consider when trying to secure an application such as properly validating user input, installing with proper credentials, properly using cryptography, avoiding race conditions such as time of use/time of check (TOUTOC) problems, and so on.

It's really more than one can go on from just a forum post. Consider reading books on the subject like "Building Secure Software" by Viega and McGraw.

Share this post


Link to post
Share on other sites
- Never ever under any circumstances use raw pointers
- Never allocate memory manually
- Use STL containers only
- Never access raw pointers manually
- Never perform any kind of unsafe or improper typecast
- Never use anything that can, under any circumstances, be considered undefined behavior
- Never assume anything. Ever.
- RAII. RAII.

Drastic, yes. But C++ must be treated with respect.

Almost without exception, all security exploits these days come from improper memory management.

Assumptions like char[4096] should be enough for user entering "Y" or "N", or // will never be more than 17 are a very bad thing. In C++, there is no safety net.

All of the above is pretty drastic, once you get comfortable with pitfalls, you'll find that some things can be simplified, but in genereal - in C++ it's up to you to make sure things work. Nobody else will guard you.

Contrary to this, interpreted or VM-based languages offer active safe-guards against many problems during run-time.

Share this post


Link to post
Share on other sites
NEVER trust anything that comes into your application from the outside (be it a file, user input, data sent through a network, etc.). Properly validate everything and do so using a whitelist kind of system where possible.
Also, think about security regardless of what you do and use tools like Purify to detect buffer-overflow vulnerabilities.

Share this post


Link to post
Share on other sites
Quote:
Original post by Antheus
Almost without exception, all security exploits these days come from improper memory management.


That's over stating things by quite a bit. While buffer overruns, double frees and the like account for a large number of security exploits, they hardly add up to "almost without exception." A number of exploits result from bad implementation of algorithms which would result no matter what programming language was used. For example, several of the Microsoft Internet Explorer vulnerabilities resulted from IE not processing content-type MIME headers correctly. Many denial of service vulnerabilities result from bad input processing. For example, the attacker says it's going to send 1000 bytes of data and only sends 8 and the client patiently waits for the rest of the data that never comes. PHP alone has what seems like several million bugs that resulted from not properly urlencoding data. Improper creation of temporary files often result in potential privacy problems. Etc. etc. etc.

Share this post


Link to post
Share on other sites
Quote:
Original post by Antheus
Almost without exception, all security exploits these days come from improper memory management.
I strongly disagree. I concur with SiCrane though that this subject is too much can dealt in one forum post or even many. In fact, there are plenty of books regarding the subject. One can see possible security concerns from the table of context of the book SiCrane, for instance.

Concerning C++, there are books like Secure Coding in C and C++ and the like listed with this book on Amazon.

Quote:
Original post by Antheus
Contrary to this, interpreted or VM-based languages offer active safe-guards against many problems during run-time.
Well, memory will run out in managed string as well as in C++ string if stuffing data in there. [smile]

[EDIT]I concur also with the second post from SiCrance.[/EDIT]

Share this post


Link to post
Share on other sites
Quote:
That's over stating things by quite a bit. While buffer overruns, double frees and the like account for a large number of security exploits,


I made it sound too general. I was referring to language-level type of exploits, not the additional logic exploits.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!