Re: false asumption or security flaw? (fwd)

[Lennert Buytenhek <buytenh@gnu.org>]

On Thu, 24 Aug 2000, johan '97 wrote:

> > Hi,
> > 
> > After you free that chunk of memory, the page it is in probably still
> > belongs to that process, so it cannot be 'shared' with other processes.
> > Nothing serious here. However, the glibc memory allocator will probably
>
> so, in other words
> the function malloc gets it's memory from an already allocated memory
> (by the kernel to the process) and hands it to the program to be used.

Yes. Unless the memory allocated to this process is full, in which case
this processes requests a new chunk of memory from the kernel. These
chunks of memory are zeroed before they are handed to processes though.


> once this chunk of memory is freed by the program, it is (probably?)
> still a part of the memory that is allocated to the process by the
> kernel.

Yup.


> The kernel 'knows' that this chunk is still in use by the process,

Yup.


> but the program 'thinks' differently.

Well, no. The program knows it has this memory allocated, but if you free
it it is marked as being free :)


> Hence, the probability of a chaos to happen is limited only in the
> process and not the kernel.

Not if you follow some basic programming rules. Like.. dont use a pointer
after you free it.


> in a nut shell, it's more of the compilers inability to detect these
> sort of situation than a flaw in the kernel security.

It's definitely not a problem with kernel security. And whether this kind
of checking belongs in the compiler is subject of religious wars.

If you really want your language to do these kinds of things for you you
probably should be using perl or something.



greetings,
Lennert


Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/