double free

[edware]

I read a document about c++ programming and memory allocation, and
I came across a new term I've never heard before, double free.
I tried googling for it but I found no explanation, can someone
tell me what it is? Is it a vulnerability that can be exploited by
malicious code?

[Victor Bazarov]

edware wrote:

I read a document about c++ programming and memory allocation, and
I came across a new term I've never heard before, double free.
I tried googling for it but I found no explanation, can someone
tell me what it is? Is it a vulnerability that can be exploited by
malicious code?

I think what is referred here is the situation like the following:

void *p = malloc(100); // get me 100 bytes, just for fun...
free(p); // throw them out, everything's fine
free(p); // AGAIN???? NO-O-O-O-O-O-O-O-O-O (undefined behaviour)

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Phlip]

edware wrote:

I read a document about c++ programming and memory allocation, and
I came across a new term I've never heard before, double free.
I tried googling for it but I found no explanation, can someone
tell me what it is? Is it a vulnerability that can be exploited by
malicious code?

Can you quote the context in the document?

The only guess possible is it means calling free() twice on the same
pointer, which is a no-no.

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!

[edware]

Phlip wrote:

edware wrote:

I read a document about c++ programming and memory allocation, and
I came across a new term I've never heard before, double free.
I tried googling for it but I found no explanation, can someone
tell me what it is? Is it a vulnerability that can be exploited by
malicious code?

Can you quote the context in the document?

The only guess possible is it means calling free() twice on the same
pointer, which is a no-no.

http://cprogramming.com/tutorial/secure.html
Its under Double Free Attack.

Maybe should have posted to comp.lang.c instead since
its malloc and free, but I didn't think of that
since I was reading the C++ tutorial.

[Victor Bazarov]

edware wrote:

[..]
Maybe should have posted to comp.lang.c instead since
its malloc and free, but I didn't think of that
since I was reading the C++ tutorial.

It's fine. C Standard Library (at least as defined in the C
Language Standard circa 1990) is part of C++ Standard Library.
You may ask questions about it here as well.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Phlip]

edware wrote:

http://cprogramming.com/tutorial/secure.html
Its under Double Free Attack.

Maybe should have posted to comp.lang.c instead since
its malloc and free, but I didn't think of that
since I was reading the C++ tutorial.

That newsgroup might have more experience with undefined behavior after a
bad free().

In general, the "double free" they describe is simply undefined behavior.
Any undefined behavior could cause anything to happen; anything from the
program appearing to work correctly, to the nearest toilet exploding, to a
program becoming vulnerable to attack.

At the second free(), the heap manager will not notice the block it's
freeing is already free. (That's a serious optimization, because it prevents
the heap manager from walking the entire free list.) The manager will read
and write the variables in the block that indicate its size and status, and
will attempt to join the block with the ones around it.

If a specific program had this bug, an attacker could conceivably submit
program code inside a string (the standard attack route). Then at double
free time the heap manager might jump into this string instead of its own
code.

The C++ fix is a style called RAII. Look that up.

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!

[Rolf Magnus]

Victor Bazarov wrote:

edware wrote:

[..]
Maybe should have posted to comp.lang.c instead since
its malloc and free, but I didn't think of that
since I was reading the C++ tutorial.

It's fine. C Standard Library (at least as defined in the C
Language Standard circa 1990) is part of C++ Standard Library.
You may ask questions about it here as well.

And you also get the same problems with delete (but then of corurse
called "double deletion").

[peter koch]

Victor Bazarov skrev:

edware wrote:

[..]
Maybe should have posted to comp.lang.c instead since
its malloc and free, but I didn't think of that
since I was reading the C++ tutorial.
It's fine. C Standard Library (at least as defined in the C
Language Standard circa 1990) is part of C++ Standard Library.
You may ask questions about it here as well.

I disagree. Questions about code that is C should normally be asked in
comp.lang.c. Still - it is not the greatest of sins. And once asked it
is okay to answer.

/Peter
V

[Victor Bazarov]

peter koch wrote:

Victor Bazarov skrev:

edware wrote:

[..]
Maybe should have posted to comp.lang.c instead since
its malloc and free, but I didn't think of that
since I was reading the C++ tutorial.
It's fine. C Standard Library (at least as defined in the C
Language Standard circa 1990) is part of C++ Standard Library.
You may ask questions about it here as well.

I disagree. Questions about code that is C

Who can tell that the code is C if it's in a C++ tutorial? Can you
tell whether

int main(void) { return 0; }

is C or C++? And what do you disagree with, actually?
should normally be asked in
comp.lang.c. Still - it is not the greatest of sins. And once asked it
is okay to answer.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Phlip]

peter koch wrote:

I disagree. Questions about code that is C should normally be asked in
comp.lang.c. Still - it is not the greatest of sins. And once asked it
is okay to answer.

I don't know if anyone has pointed this out recently, but the most useful
recourse here is enlightened self-interest.

If a poster will get a better answer on another newsgroup, even if an
Authority says their question is On Topic here, bounce them. It's for their
own good.

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!