Question on buffer overflows

maxhavoc · 11-25-2004, 02:56 PM

I know how buffer overflows work in theory. Dynamic memory areas are given user access for input reasons and bounds checking is not used so excess data goes to the stack which is executed by the OS with system level access and bad stuff happens. My questions is: what kind of code actually leads to buffer overflows being possible? I will give two examples of code, one of which I believe could lead to a buffer overflow, the other one I think will not, am I right?

SHOULD lead to buffer overflow

Code:

char* pString = new char[10];
cin >> p;

SHOULD NOT lead to buffer overflow

Code:

char* pString = new char[10];
cin.getline(p, 10);

**CornedBee** · 11-25-2004, 03:18 PM

Correct, except that the memory area needs not be dynamic. A global or stack-local array can have the same effect. And except that your pointer names don't match.
However, the second example is very prone to future buffer overflow:

Code:

char *pString = new char[10];
// Lots of code
// And I mean really lots.
// This protects against the overflow when using >>
cin >> setw(9) >> pString;

Great. Later someone comes along and decides that he needs 12 characters read. This is where the "magic numbers" game comes in.

Code:

char *pString = new char[10];
// Lots of code
// And I mean really lots.
// This protects against the overflow when using >>
cin >> setw(12) >> pString; // Ouch! Reading too much, other number not changed.

So you see, overflowing a buffer is very easy. The best solution, usually, is to avoid doing your own memory management.

Code:

std::string str;
cin >> str; // Cannot overflow

maxhavoc · 11-25-2004, 03:43 PM

I'm not sure I understand your reply. What does setw do? I forgot. And what did you mean by does not protect against future overflows? You mean if the memory area allows for input again? Aren't you just saying that you need to use cin.getline() whenever you want to protect against buffer overflows?

**CornedBee** · 11-25-2004, 03:48 PM

setw in this case limits the number of characters the >> operator will read at most, the same way as the second parameter of getline does.

By "protecting against future buffer overflows" I'm merely pointing out that any fixed-size buffer is potentially exposed. It may not be now, but it might be after code maintenance. Especially if you don't use proper named constants, the risk that the read bound will be changed to a value greater than the buffer size is high.
That's why I prefer self-managing dynamic buffers, such as a std::string in this case.

11-25-2004, 02:56 PM	#1
maxhavoc Registered User Join Date: Jun 2004 Posts: 124	Question on buffer overflows I know how buffer overflows work in theory. Dynamic memory areas are given user access for input reasons and bounds checking is not used so excess data goes to the stack which is executed by the OS with system level access and bad stuff happens. My questions is: what kind of code actually leads to buffer overflows being possible? I will give two examples of code, one of which I believe could lead to a buffer overflow, the other one I think will not, am I right? SHOULD lead to buffer overflow Code: char* pString = new char[10]; cin >> p; SHOULD NOT lead to buffer overflow Code: char* pString = new char[10]; cin.getline(p, 10);
maxhavoc is offline

11-25-2004, 03:18 PM	#2
CornedBee Cat without Hat Join Date: Apr 2003 Posts: 8,492	Correct, except that the memory area needs not be dynamic. A global or stack-local array can have the same effect. And except that your pointer names don't match. However, the second example is very prone to future buffer overflow: Code: char pString = new char[10]; // Lots of code // And I mean really lots. // This protects against the overflow when using >> cin >> setw(9) >> pString; Great. Later someone comes along and decides that he needs 12 characters read. This is where the "magic numbers" game comes in. Code: char pString = new char[10]; // Lots of code // And I mean really lots. // This protects against the overflow when using >> cin >> setw(12) >> pString; // Ouch! Reading too much, other number not changed. So you see, overflowing a buffer is very easy. The best solution, usually, is to avoid doing your own memory management. Code: std::string str; cin >> str; // Cannot overflow __________________ All the buzzt! CornedBee "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code." - Flon's Law
CornedBee is offline

11-25-2004, 03:43 PM	#3
maxhavoc Registered User Join Date: Jun 2004 Posts: 124	I'm not sure I understand your reply. What does setw do? I forgot. And what did you mean by does not protect against future overflows? You mean if the memory area allows for input again? Aren't you just saying that you need to use cin.getline() whenever you want to protect against buffer overflows?
maxhavoc is offline

11-25-2004, 03:48 PM	#4
CornedBee Cat without Hat Join Date: Apr 2003 Posts: 8,492	setw in this case limits the number of characters the >> operator will read at most, the same way as the second parameter of getline does. By "protecting against future buffer overflows" I'm merely pointing out that any fixed-size buffer is potentially exposed. It may not be now, but it might be after code maintenance. Especially if you don't use proper named constants, the risk that the read bound will be changed to a value greater than the buffer size is high. That's why I prefer self-managing dynamic buffers, such as a std::string in this case. __________________ All the buzzt! CornedBee "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code." - Flon's Law
CornedBee is offline

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Converting a circulating mouse pointer to use a Potentionmeter	phoenix23	C Programming	16	10-29-2006 05:04 AM
Print out a buffer	SwarfEye	C Programming	4	09-08-2006 09:32 AM
writing a pack-style function, any advices?	isaac_s	C Programming	10	07-08-2006 08:09 PM
Simple pointer question	jayznz	C Programming	2	04-04-2006 11:36 PM
Having Buffer Problems With Overlapped I/O --	Sargera	C++ Programming	0	02-07-2006 04:46 PM