Re: Buffer Overflow/Overrun
From: Robert W Hand (rwhand_at_NOSPAMoperamail.com)
Date: 03/15/04
- Next message: Nai Namae: "Re: Java or C++?!!"
- Previous message: Simon Lewis: "Re: why do i inhereit base class as virtual?"
- In reply to: Novice: "Re: Buffer Overflow/Overrun"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sun, 14 Mar 2004 18:52:47 -0500
On Sun, 14 Mar 2004 11:02:12 -0500, "Novice" <6tc1@qlinkDOTqueensu.ca>
wrote:
>First I just want to thank you for taking the time to respond to my
>question - you raise some good points - but you have misunderstood me on two
>counts.
Sorry.
>> The short answer is no. You can always miscount. Buffer overruns are
>> nothing but miscounting.
>
>I agree buffer overruns can be caused by miscounting, but it can also be
>caused by relying on fixed/predefined sized buffers too. Unless you would
>say that predefining a buffer to a particular size and then relying on the
>user of your code not to exceed that is also miscounting.
We are getting off your original topic, but I see that as miscounting,
too. It's a trivial point not worth discussing.
>> Ok, charPtr1 is a small array of two char. Let's assume that the
>> allocation worked. The startPosition is wrong.
>
>The startPosition is intentionally outside the boundaries of the memory I've
>allocated - I was trying to demonstrate by even doing this that a buffer
>overflow/overrun wouldn't result.
I guess I just don't follow this one. If you intentionally overrun a
buffer, it is still overrun, isn't it? The particular, salubrious
behavior of your operating system does not make the construction ok.
You are not allowed to access data outside the array.
>> So you have undefined behavior.
>
>What I was trying to say is that even if I passed in this unknown data
>(outside the boundaries of the memory actually allocated - i.e. potentially
>stack memory) into the constructor it would just result in that data being
>copied into the memory held by the string class. While this is still
>referred to as "undefined behavior" and thus is not desireable - my point
>was that I don't think it would result in the buffer overflow/overrun
>vulnerability. And yes, you should try to prevent more than just buffer
>overflows/overruns - but right now I'm just trying to get a handle on it.
Now we are at the level of how the operating system might handle such
a problem. Since you are accessing the data with a pointer to char,
it probably would handle it in a sensible manner. But if the memory
is mapped to a disk with other critical information, the data copied
might be private financial information, credit card numbers, etc. I
have done this by accident when I miscounted a buffer in such a
situation. I was quite surprised to print out such stuff. :-(
>> Next, m_myCharPointerMemberVariable is an internal buffer
>> that must have a predefined size.
>
>Actually I should have been more clear on this -
>m_myCharPointerMemberVariable is actually of type (char *) - it's memory is
>allocated dynamically and thus its only limitations (on memory) are based on
>the computer's total memory.
Ok, but it's size is determined before the copy operation, yes or no?
So it is possible to copy a larger object into
m_myCharPointerMemberVariable. You would overrun that buffer and
overwrite other data or write into a read only zone.
>> Yet data of unspecified size,
>> perhaps from a larger array, is copied to it. So there is another
>> source of potential buffer overrun.
>
>And thus there is NOT a potential for buffer overrun because the size of
>memory for m_myCharPointerMemberVariable is NOT predefined.
That was not clear from the prior post. If you measure the size of
the object to be copied and allocate enough space to the unnamed array
pointed to by m_myCharPointerMemberVariable, then you should not
overwrite m_myCharPointerMemberVariable's array.
However, you still should avoid reading past the end of buffers.
>> Please use std::string or other standard containers if possible.
>> Avoid buffer overruns all the time.
>
>I agree - you can avoid many problems by using standard classes and I do
>make use of them - but I want to understand the problem so when I construct
>a class that takes pointers into its constructors that I don't create buffer
>overflows/overruns. And while your advice to "not take bare pointers" is
>good - I would still like to understand how to handle those instances when
>(for whatever reason) I need to take bare pointers as parameters.
I program in C quite a bit yet, so I am using bare pointers. My
experience tells me that it is imperative to count properly to avoid
accessing slots that lie outside the array. You are allowed to
increment one slot past the array, but you cannot dereference outside
the array. That is undefined behavior. It is not predictable how the
operating system will handle such a situation. HTH.
-- Best wishes, Bob
- Next message: Nai Namae: "Re: Java or C++?!!"
- Previous message: Simon Lewis: "Re: why do i inhereit base class as virtual?"
- In reply to: Novice: "Re: Buffer Overflow/Overrun"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
