|
-
July 6th, 2005, 03:35 AM
#1
Junior Member
Preventing Buffer Overflows in C++
I've seen numerous articles on buffer overflows and how they occur and I've even see code examples of how they are done and what they look like. What many of these articles leave it is how to fix them?! I know that in C++ the string data type prevents this, but many, many functions require char arrays and pointers to be passed to them and once you convert a string to a char, your back to your security risk.
So how can I prevent buffer overflows in C/C++? (code examples would be appreciated)
Are the 'cin' functions in C++ safe?
Is there a list of what string/char functions are immune/vulnerable anywhere?
Thanks again.
-
July 6th, 2005, 04:47 AM
#2
It's not so much the cin functions that are safe rather than the string class that is. You could still overflow a char buffer with cin, but the string class is self redimensioning...
Ammo
Credit travels up, blame travels down -- The Boss
-
July 6th, 2005, 05:15 AM
#3
Junior Member
Thanks for resolving that question about cin. If I may make a hypothesis on my other questions I think I know how I can prevent it, but confirmation from others would be nice.
Am I correct in assuming that the only way buffer overflow can be achieved is through user input of some kind? I know about the heap and stack, but from what I've seen it still requires user input atleast in the examples given both on these forums and on various websites. Is it safe to use a string to get all my input and then convert to char where nessisary for my functions and what not or is this still a security risk? (for example...)
string x;
cout << "Enter Your First Name: ";
cin >> x;
char y[12];
strncpy(y, x, 12);
// use 'y' as a parameter for functions that require chars
I couldn't think of any functions off hand that only requires char, but I run into them every so often and I always get errors when I try to pass a string instead. Like I said, this is all just a wild guess from what knowledge I do know. Is this the safest way to do it or are there any other input functions or other methods that would work better?
-
July 6th, 2005, 05:43 AM
#4
You should use the c_str methode to get a null terminated string (char buffer) from a string object, that way you avoid all the dangers of buffer size copy mismatch.
The issue, however still remains; any time you have fixed sized buffer, you have to be careful in every resulting line of code that will be using/manipulating it.
Am I correct in assuming that the only way buffer overflow can be achieved is through user input of some kind?
More or less: buffer overflows usually result from inproperly manipulated input of some kind, yes. That said, inputs can come from a plethora of places, be it UI input, network, IPC, etc.
That said they can also result indirectly from logic/algorithm errors, which might be exploited in more or less obscure ways... Let's say you trust the input to be honest all the time, like prompt the user for the lenght of a string he's gonna enter, then prompt for the string, and use the first value to alloc your buffer... this sounds silly, but might not be uncommon in badly coded binary network application (eg: packet length in the header, then copy a caracter delimited payload based into a buffer allocated based on the length claimed in header, for example).
Ammo
Credit travels up, blame travels down -- The Boss
-
August 30th, 2005, 05:29 AM
#5
Member
In a lot of places a simple sizeof() check could be useful.
-
August 30th, 2005, 05:56 AM
#6
Why do you people signup here and post in threads that are about a year old or more?
-
August 30th, 2005, 06:04 AM
#7
Member
To get to 10 posts.
-
August 30th, 2005, 06:32 AM
#8
Yeah but still
all that work for an avatar... why look for old threads to post in when you can lighten up a current topic just by posting the phrase "poop" seven times in GCC.
-
August 30th, 2005, 06:40 AM
#9
Member
Actually I didn't look at the date, I only knew I was on the top of the second page.
Apparently things move a little slow in the Programming Security forum.
-
August 30th, 2005, 04:36 PM
#10
too slow, let's speed them up.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
|