Page 1 of 1

"Use after Free" memory abuse hacking

Posted: Tue Jun 24, 2014 9:29 am
by mike acker
Refer to article on Ars Technica

interesting

supposedly,-- with memory protection properly initiated -- the x86 chip effects memory protection concurrently with access

Thus, if I were to have some pointers, e.g.

Code: Select all

char *point_a, point_b, *save_point;
and i were to code

Code: Select all

strcpy(point_a,point_b);
to copy string b to string a -- memory protection should verify that both pointers are referencing memory that has been allocated to my address space

however -- as i understand it -- the protection model is a bit coarse-- generally tracking memory in 4k pages -- ( although i think you can vary this as you build the memory management tables prior to switching into protected mode..... ( if memory serves ))

too, if memory serves when I allocate the pointers,.....

Code: Select all

#define WK_STRING_LENGTH 128
point_a = (char *) malloc(WK_STRING_LENGTH);
point_b = (char *) malloc(WK_STRING_LENGTH);
the data will be allocated from an existing page if possible....
which means.... if I

Code: Select all

strcpy(point_b,"RATS");
strcpy(point_a,point_b);
i now have RATS in both places....

now: I save pointer to a and release memory allocated at point a :

Code: Select all

save_point=point_a;
free(point_a);
and then print the content:
prints(save_point);

i should get RATS

as I understand it Intel is working on implementing dope vectors to prevent this. to bad those were not added to C++
remember, in PL/1 when you are working with strings or arrays you are working trhough dope vectors which provide
the current and maximum size of these variables. the STRINGRANGE condition is based on this idea

interesting stuff

Re: "Use after Free" memory abuse hacking

Posted: Tue Jun 24, 2014 6:16 pm
by mike acker
sample program to play with

Code: Select all

#include <stdio.h>
#include <malloc.h>
#include <string.h>
#define WK_BUFFER_SIZE 128


void main()
{   

	char *point_a, *point_b, *save_point;


	puts("print rats program");


	/* allocate pointers a, and b */
	point_a = (char *) malloc(WK_BUFFER_SIZE);
	point_b = (char *) malloc(WK_BUFFER_SIZE);

	/* put rats in string indicated at point b */

	strcpy(point_b, "RATS!");
	
	/* copy the rats from point b to point a */

	strcpy (point_a, point_b);

	puts(point_a);   /* prints out RATS! */

	save_point=point_a;    /* save value of point a*/

	free(point_a);  
	
		/* should i set the pointer to null after I free the data
			my feeling is yes: that is the way it was when i got it
			so i should put it back the way it was								*/
			
	point_a=NULL;
	
	puts("rats are free");

	/*	puts(point_a); */    /* result: segmentation fault */
	
	
	/* obviously if i saved a copy of the pointer i can still make an inappropriate
		update to memory: */
		
	strcpy(save_point,point_b); /* pointer still valid */
	puts(save_point); /* prints out RATS! */

	puts("but they ain\'t gone");


	return;

}
there's no substitute for careful programming. it would be my feeling it's best not to leave bad pointers
set to accessible addresses. seems like it's asking for trouble.

too bad I can't code :

Code: Select all

point_a=free(point_a);
but the prototype for free is

Code: Select all

void free(void *ptr)