Board index » cppbuilder » Re: buffer-overruns

Re: buffer-overruns


2005-02-24 11:32:27 AM
cppbuilder78
Quote
LOL! If someone causes a buffer overrun on
/any/ process on your machine, you're doomed.
Whoever does this, can execute whatever code
they like on your machine. It simply doesn't
matter whether this was started in your main
app or some auxiliary process.
That is what I thought. It make programming internet apps interesting,
don't you think ?
 
 

Re:Re: buffer-overruns

Jonathan Benedicto wrote:
Quote
So we have met. It is very interesting meeting up with you here.

Likewise.
Quote
Are you still working on your image codec app ?


Well, after doing some research with different codecs, we are going to
use our own compression format and provide a decoder DMO, so media
player will be happy :) Reasons are many, including better looking
image, flixibility in input formats, lower CPU utilization.
.a
 

Re:Re: buffer-overruns

"Remy Lebeau (TeamB)" < XXXX@XXXXX.COM >schrieb im Newsbeitrag news:421c518b$ XXXX@XXXXX.COM ...
Quote

"Jonathan Benedicto" < XXXX@XXXXX.COM >wrote in message
news:421c04b8$ XXXX@XXXXX.COM ...

>UdpClient->ReceiveBuffer(&Buffer, sizeof(Buffer), 1000),
>
>what are the risks of buffer-overruns

There aren't any.
Donīt assume that ;-)
Except that this function should better use an unsigned integer for the
buffer size, though that might not be an internal problem of the function.
And even if unsigned integers are used there might be a risk of an
integer overflow attack.
E.g.:
unsigned int a;
unsigned int b;
.....
if ((a + b)>maxBufferSize) return Error(".....");
Read(buffer, a+b)......
is unsafe too.
Quote
ReceiveBuffer() does not read more than you specify.
And this is commonly the problem. That the specified size may be greater,
e.g. by using an integer overflow attack, than the buffer and then the
ReceiveBuffer function will lead to a buffer overflow.
Quote
Since you do not specify more than your buffer can actually hold, there is
no risk of overflowing the buffer. ReceiveBuffer() may read less then you
specify, but never more.


Gambit


Andre
 

{smallsort}

Re:Re: buffer-overruns

"Andre Kaufmann" < XXXX@XXXXX.COM >schrieb im Newsbeitrag news: XXXX@XXXXX.COM ...
Quote
"Remy Lebeau (TeamB)" < XXXX@XXXXX.COM >schrieb im Newsbeitrag news:421c518b$ XXXX@XXXXX.COM ...
>
>"Jonathan Benedicto" < XXXX@XXXXX.COM >wrote in message
>news:421c04b8$ XXXX@XXXXX.COM ...
>
>>UdpClient->ReceiveBuffer(&Buffer, sizeof(Buffer), 1000),
>>
>>what are the risks of buffer-overruns
>
>There aren't any.

Donīt assume that ;-)
Except that this function should better use an unsigned integer for the
buffer size, though that might not be an internal problem of the function.
And even if unsigned integers are used there might be a risk of an
integer overflow attack.
E.g.:

unsigned int a;
unsigned int b;
.....

if ((a + b)>maxBufferSize) return Error(".....");
Read(buffer, a+b)......
Sorry, was a typo.
Must read:
if ((a + b)>maxBufferSize) return Error(".....");
Read(buffer, a) .....
Quote

is unsafe too.


>ReceiveBuffer() does not read more than you specify.

And this is commonly the problem. That the specified size may be greater,
e.g. by using an integer overflow attack, than the buffer and then the
ReceiveBuffer function will lead to a buffer overflow.


>Since you do not specify more than your buffer can actually hold, there is
>no risk of overflowing the buffer. ReceiveBuffer() may read less then you
>specify, but never more.
>
>
>Gambit
>
>

Andre

 

Re:Re: buffer-overruns

Hendrik Schober wrote:
Quote
LOL! If someone causes a buffer overrun on
any process on your machine, you're doomed.
Whoever does this, can execute whatever code
they like on your machine.
That's true but gaining control of a proxy process doesn't (I don't
think) guarantee control over the primary process. Any attack on the
primary process would have to be through subversion of the
inter-process protocol by spoofing the returned data or by capturing
outgoing data (or by attacking the OS protection).
If the data format is encrypted and/or highly complex then it becomes
quite a difficult task. Given that all you'd need for the proxy process
is a simple command dispatch function it seems like very little
additional development effort for a quite large security/stability gain.
--
Andrue Cope [TeamB]
[Bicester, Uk]
info.borland.com/newsgroups/guide.html
 

Re:Re: buffer-overruns

Quote
>Donīt assume that ;-)
>Except that this function should better use an unsigned integer for
>the
>buffer size, though that might not be an internal problem of the
>function.
>And even if unsigned integers are used there might be a risk of an
>integer overflow attack.
When I checked how the Indy set implements the ReceiveBuffer method,
it calls the MS recvfrom (I think) method using the params I passed to
it in the beginning. So, I need to verify that my code won't pass a
larger size for the buffer than it actually is, and I also need to
tell my clients that they need to keep Windows patched. <g>
Quote
>And this is commonly the problem. That the specified size may be
>greater,
>e.g. by using an integer overflow attack, than the buffer and then
>the
>ReceiveBuffer function will lead to a buffer overflow.
I've simplified the code so that it uses a struct and calls
receivebuffer with a &buffer and a sizeof(buffer).
Hackers are at least enhancing our apps reliability. <g>
 

Re:Re: buffer-overruns

Can't the OS throw a exception when a app steps on memory it does not
have write-access to ?
 

Re:Re: buffer-overruns

Jonathan Benedicto wrote:
Quote
Can't the OS throw a exception when a app steps on memory it does not
have write-access to ?
Yes but I think you can only designate an entire page as read-only.
This is why I thought bringing the discussion here would be worthwhile.
It's kind of a hot topic and one that I don't have any experience in.
I'm used to avoiding AVs but that's a more passive defense and doesn't
help much against a determined attack.
--
Andrue Cope [TeamB]
[Bicester, Uk]
info.borland.com/newsgroups/guide.html
 

Re:Re: buffer-overruns

Because my idea was to design either the "safety" or main process so
that it would lock a chunk of memory behind the memory that is being
used for reading, so that a av would be thrown on a over-run.
 

Re:Re: buffer-overruns

Jonathan Benedicto wrote:
Quote
Can't the OS throw a exception when a app steps on memory it does not
have write-access to ?


That's what the new AMD (and now Intel) CPUs allow you to do - set the
'non-exectable' bit for the stack memory. Details on this should be
available on amd.com.
.a
 

Re:Re: buffer-overruns

Quote
That's what the new AMD (and now Intel) CPUs allow you to do - set
the 'non-exectable' bit for the stack memory. Details on this should
be available on amd.com.
This will hopefully stop buffer-overuns from being a problem. But, we
still have to contend with the chips still out there.
 

Re:Re: buffer-overruns

Andrue Cope [TeamB] < XXXX@XXXXX.COM >wrote:
Quote
[...]
That's true but gaining control of a proxy process doesn't (I don't
think) guarantee control over the primary process. [...]
It gives you control over the machine. FWIW, if
you want, you can start a de{*word*81} process and
patch the kernel.
I'm by no means a security expert, but from what
I learned, the only thing between a hacker who
got code executed through a buffer overrun and
the machine is the access rights of the user who
runs the process that got hacked. -- And this
assumes that there are no security holes in the
access right system.
Schobi
--
XXXX@XXXXX.COM is never read
I'm Schobi at suespammers dot org
"The presence of those seeking the truth is infinitely
to be prefered to those thinking they've found it."
Terry Pratchett
 

Re:Re: buffer-overruns

Jonathan Benedicto wrote:
Quote
Because my idea was to design either the "safety" or main process so
that it would lock a chunk of memory behind the memory that is being
used for reading, so that a av would be thrown on a over-run.
I don't think the current generation of CPUs let you do that. I could
be wrong but I thought they all worked on page accesses. There's
probably a way you could allocate a collection of 4kB pages solely for
the buffer though. That way any overrun /will/ trigger an exception.
--
Andrue Cope [TeamB]
[Bicester, Uk]
info.borland.com/newsgroups/guide.html
 

Re:Re: buffer-overruns

Hendrik Schober wrote:
Quote
It gives you control over the machine. FWIW, if
you want, you can start a de{*word*81} process and
patch the kernel.
Ah. Well that's a problem with the OS then ain't it?
:)
..but a valid point of course.
--
Andrue Cope [TeamB]
[Bicester, Uk]
info.borland.com/newsgroups/guide.html
 

Re:Re: buffer-overruns

Andrue Cope [TeamB] wrote:
Quote

I don't think the current generation of CPUs let you do that. I could
be wrong but I thought they all worked on page accesses. There's
probably a way you could allocate a collection of 4kB pages solely for
the buffer though. That way any overrun /will/ trigger an exception.

Windows allocates initially in regions (64kB blocks). You could
possibly allocate 3 regions, 1 either side set to no-access and the
middle one for read/write access (I'm not completely up on this
conversation so I may be off the mark completely here)
Cheers
Russell