Buffer overflow protection

[Ioannis Vranos]

If we want our programs to be protected against buffer overflows, must we
check the size of the various containers explicitly?

E.g.

#include <iostream>
#include <string>
int main()
{
using namespace std;

string s;

while(cin>>s)
;

// ...
}
should become:
#include <iostream>
#include <string>
#include <cctype>
int main()
{
using namespace std;

string s;

while(cin && s.size()<s.max_ size())
{
char c;

cin>>c;

if(isspace(c))
continue;

s.push_back(c);
}

// ...
}


Ioannis Vranos

[Ioannis Vranos]

"Ioannis Vranos" <iv*@guesswh.at .emails.ru> wrote in message
news:c5******** ***@ulysses.noc .ntua.gr...

If we want our programs to be protected against buffer overflows, must we
check the size of the various containers explicitly?

E.g.

#include <iostream>
#include <string>
int main()
{
using namespace std;
string s, temp;
while(cin>>temp )
s+=temp;
// ...
}
should become:
#include <iostream>
#include <string>
#include <cctype>
int main()
{
using namespace std;

string s;

while(cin && s.size()<s.max_ size())
{
char c;

cin>>c;

if(isspace(c))
continue;

s.push_back(c);
}

// ...
}


Ioannis Vranos

[Howard]

I'm puzzled. Is it even *possible* for s.size() to have a value greater
than s.max_size()? That would seem to violate the concept of "max",
wouldn't it? So, shouldn't the streaming operator prevent s.size() from
ever exceeding s.max_size() in the first place, making any such check on
your part redundant?

I know that checking for buffer overruns is important when filling arrays,
but I would think one of the advantages of using a string class and
streaming operators is to protect against such things.

But for filling arrays, I'd agree on your design, where you add one
character at a time. It's silly to try to see if you've *already* overrun
memory.

-Howard

[David Harmon]

On Tue, 13 Apr 2004 14:59:35 +0300 in comp.lang.c++, "Ioannis Vranos"
<iv*@guesswh.at .emails.ru> wrote,

If we want our programs to be protected against buffer overflows, must we
check the size of the various containers explicitly?
You need to ensure that the sizes are checked.
How explicit it is, is another matter.
string s;

while(cin>>s)

Here std::string and its operator>> do the checking.
So, it does not need to be explicit.

[Kevin Goodsell]

Howard wrote:

I'm puzzled. Is it even *possible* for s.size() to have a value greater
than s.max_size()? That would seem to violate the concept of "max",
wouldn't it?
I believe so. I was unable to find exact details, but I'm fairly sure
that attempting to exceed a container's max_size will fail for one
reason or another. I suspect it will fail due to memory exhaustion
before you get to that point, and if that doesn't occur it will probably
throw an exception. The standard definitely says that an exception will
be thrown in a few cases (like calling reserve() for a vector where the
new capacity is too large, if I recall correctly).
So, shouldn't the streaming operator prevent s.size() from
ever exceeding s.max_size() in the first place, making any such check on
your part redundant?

I think the container (or string) itself will prevent it.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[Kevin Goodsell]

Ioannis Vranos wrote:

"Ioannis Vranos" <iv*@guesswh.at .emails.ru> wrote in message
news:c5******** ***@ulysses.noc .ntua.gr...

If we want our programs to be protected against buffer overflows, must we
check the size of the various containers explicitly?

E.g.

#include <iostream>
#include <string>
int main()
{
using namespace std;

string s, temp;
while(cin>>temp )
s+=temp;

// ...
}

The library is responsible for managing the buffers and preventing their
overflowing. I generally assume memory exhaustion will occur before
anything else. If max_size() is reached first, I'm not 100% sure what
should happen. My guess is that an exception will be thrown, either
length_error or bad_alloc. In effect, exceeding max_size() means
exhausting the memory of the allocator I think, so bad_alloc might be
appropriate, though I suppose I should check the standard and see how
allocators are supposed to handle running out of memory.

From a security standpoint, if we assume that an overflow of this sort
could exist, it seems likely that an attack exploiting such an overflow
would have much less chance of succeeding than a traditional
fixed-buffer-length overflow attack. max_size() is probably up around 2
or 4 billion. That's a hell of a lot of data to dump into the program.
If it were a remote attack, it would take quite a while to transfer all
that (over 3 minutes on a 10 Mbps connection?), and I imagine a IDS
(which I know nothing about) would have a very good chance of detecting
that.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[Ioannis Vranos]

"Kevin Goodsell" <us************ *********@never box.com> wrote in message
news:Oy******** *********@newsr ead2.news.pas.e arthlink.net...

The library is responsible for managing the buffers and preventing their
overflowing. I generally assume memory exhaustion will occur before
anything else.

This can't happen on all modern systems using virtual memory (swap) file. If
one has 10 GB swap file my guess is that max_size() can be reached. I am too
bored to check the standard but if noone provides an answer i shall be
forced to do so, since i can't live for long with such a question.

If max_size() is reached first, I'm not 100% sure what
should happen. My guess is that an exception will be thrown, either
length_error or bad_alloc. In effect, exceeding max_size() means
exhausting the memory of the allocator I think, so bad_alloc might be
appropriate, though I suppose I should check the standard and see how
allocators are supposed to handle running out of memory.

From a security standpoint, if we assume that an overflow of this sort
could exist, it seems likely that an attack exploiting such an overflow
would have much less chance of succeeding than a traditional
fixed-buffer-length overflow attack. max_size() is probably up around 2
or 4 billion. That's a hell of a lot of data to dump into the program.
If it were a remote attack, it would take quite a while to transfer all
that (over 3 minutes on a 10 Mbps connection?), and I imagine a IDS
(which I know nothing about) would have a very good chance of detecting
that.

Buffer overflow attacks happen all the time. However i am not checking about
protection against attacks here. This is a general reliability question. If
there is no such a check implicitly in standard library containers, the
whole scenario will defeat the abstraction mechanism of the standard library
and i do not think this can happen anyway. In 15 minutes or so i 'll check
the standard and drop a message here.


Ioannis Vranos

[Kevin Goodsell]

Ioannis Vranos wrote:

"Kevin Goodsell" <us************ *********@never box.com> wrote in message
news:Oy******** *********@newsr ead2.news.pas.e arthlink.net...

The library is responsible for managing the buffers and preventing their
overflowing . I generally assume memory exhaustion will occur before
anything else.

This can't happen on all modern systems using virtual memory (swap) file. If
one has 10 GB swap file my guess is that max_size() can be reached. I am too
bored to check the standard but if noone provides an answer i shall be
forced to do so, since i can't live for long with such a question.

I found this in the unofficial list of C++2003 changes:

Insert subclause 21.3, paragraph 4a:

4a For any string operation, if as a result of the operation,
size() would exceed max_size() then the operation throws
length_error.
Strangely, I couldn't find anything similar for other containers.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[Kevin Goodsell]

Kevin Goodsell wrote:

Ioannis Vranos wrote:

"Kevin Goodsell" <us************ *********@never box.com> wrote in message
news:Oy******** *********@newsr ead2.news.pas.e arthlink.net...

The library is responsible for managing the buffers and preventing their
overflowing. I generally assume memory exhaustion will occur before
anything else.

This can't happen on all modern systems using virtual memory (swap)
file. If
one has 10 GB swap file my guess is that max_size() can be reached. I
am too
bored to check the standard but if noone provides an answer i shall be
forced to do so, since i can't live for long with such a question.

I found this in the unofficial list of C++2003 changes:

Insert subclause 21.3, paragraph 4a:

4a For any string operation, if as a result of the operation,
size() would exceed max_size() then the operation throws
length_error.
Strangely, I couldn't find anything similar for other containers.

This document, by the way, came from Stroustrup's web page if I recall
correctly. If it's not there, then maybe it was Koenig's page.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[Ioannis Vranos]

"Kevin Goodsell" <us************ *********@never box.com> wrote in message
news:u9******** *********@newsr ead2.news.pas.e arthlink.net...

Ioannis Vranos wrote:

"Kevin Goodsell" <us************ *********@never box.com> wrote in message
news:Oy******** *********@newsr ead2.news.pas.e arthlink.net...

The library is responsible for managing the buffers and preventing their
overflowing . I generally assume memory exhaustion will occur before
anything else.

This can't happen on all modern systems using virtual memory (swap) file. If one has 10 GB swap file my guess is that max_size() can be reached. I am too bored to check the standard but if noone provides an answer i shall be
forced to do so, since i can't live for long with such a question.

I found this in the unofficial list of C++2003 changes:

Insert subclause 21.3, paragraph 4a:

4a For any string operation, if as a result of the operation,
size() would exceed max_size() then the operation throws
length_error.

Can you provide the URL please? And what is C++2003? I assume C++0x as it
had so far?


Regards,

Ioannis Vranos