Re: false asumption or security flaw? (fwd)

["johan '97" <joe197@puspa.cs.ui.ac.id>]

On Thu, 24 Aug 2000, Lennert Buytenhek 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.
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.
The kernel 'knows' that this chunk is still in use by the process,
but the program 'thinks' differently. Hence, the probability of a chaos
to happen is limited only in the process and not the kernel.

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

is this correct?

> I think you need to read a good book on operating system internals.
> greetings,
> Lennert
> On Thu, 24 Aug 2000, johan '97 wrote:
> 
> > > You're creating a reference of type int (int &) with the value of 8 in a
> > > roundabout kind of way. Yuck. That shouldn't dump core because it does
> > > nothing wrong, but whatever you're trying to do I'll bet that isn't the
> > > right way to do it :)
> > 
> > the fact that i have freed the memory pointed by 'x', but still "legally" 
> > can be accessed by the reference variable 'a' (shown by the no dumping
> > off the program)  should imply that this piece of memory can be allocated
> > not only to one user/process but also many user/process which can be
> > devestating in effect!
> > 
> > i don't know much about how the kernel manages the memory areas to the
> > users/processes, so may be a knowledge about how the kernel does things
> > in the memory would be helpful here. hints from the experts, please :)
> > 
> > fyi: if i added this code here
> > > On Thu, 24 Aug 2000, johan '97 wrote:
> > > > #include <stdio.h>
> > > > #include <stdlib.h>
> > > > main()
> > > > {
> > > > 	int *x=(int*)malloc(sizeof(int));
> > > > 	*x=8;
> > > > 
> > > > 	int &a=(*x);
> > > > 
> > > > 	printf("\na dan x : %d %d", a, *x);
> > > > 
> > > > 	a = 9;
> > > > 
> > > > 	printf("\na dan x : %d %d", a, *x);
> > > > 
> > > > 	free(x);
> > > > 
> > > > 	a=5;
> > /*additional code here*/
> > 	free(x);
> > > > 
> > > > 	return 0;
> > > > }
> > the program would dump!
> > i guess this means that the memmory manager consider the memory pointed by
> > 'x' does no longer exist, hence the act of changing it's content is
> > "illegal" , BUT this was proved wrong by the piece of code:
> > 'a=5;' 
> > 
> > i think this is serious!
> 

johan
surrendered, i have


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