Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
Consider the following function that is supposed to validate passwords:
char *systemkey = ...... ;
int validate(char* key) {
char* k = malloc(16);
char* sk = malloc(16);
strcpy(sk,systemkey);
strcpy(k,key);
return (strncmp(k,sk,16) ==0);
}
If k and sk are allocated consecutively, that it's easy to break the function by supplying 2 identical blocks of 16 bytes each.
If I'm the one writing the compiler/malloc/free/OS, is there any way I can identify MOST of these type of hacks and prevent them?
EDIT
One possible solution is to put some sort of canary word between each two different allocations. Is there another way?
The best you can hope in use by and operating system is an implementation of malloc that randomizes the memory it returns. It doesn't prevent overflows, but makes exploiting them much harder. For large allocations a technique being used is to return the allocation aligned to the end of the page and leaving the next page explicitly unmapped as a guard page.
You can read a little bit on this page and a the links from it to see how OpenBSD implements malloc protection. As far as I'm aware this is the best you can get from a malloc in an operating system in wide use.
If I'm the one writing the compiler/malloc/free/OS, is there any way I can identify MOST of these type of hacks and prevent them?
One possibility is to use a “sound” static analyzer that, if used properly, can guarantee that your program does not access any invalid pointer for any execution. Here is one.
Another is to use dynamic instrumentation. Valgrind is an example of this approach.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 1 year ago.
Improve this question
I am using memset in an embedded application to delete one data. here is the function:
uint8_t Delete()
{
memset(cure.name, 0x0, 32);
cure.volume = 0;
cure.valid=0;
printf("[*] Cure DELETED\n");
return 1;
}
and I am trying to evaluate it against fault injection attack (clock glitching). As I saw in my experiments after clock glitching memset overwrites the neighbor's memory blocks as well. (they have been filled by zeros). is there any safer (more secure) alternative function for memset that I could use? maybe an instruction which validates the destination block at all the copying step.
Thank you in advance for your help;
memset is a standard library function; it is unlikely to take into consideration intentionally generated hardware glitches.
Firmware protection against these glitches appears to depend on:
making the execution timing unpredictable
adding self-verification code.
I suspect you will have to write your own function to do this; you could add random delays within the loop for zeroing the memory, for example.
I do not know if this is sufficient. You may need more details about what in your system is vulnerable; what instruction is targeted, in order to also add verification code
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 2 years ago.
Improve this question
I have an assignment on memory blocks. We have a struct Record that I need to save in these memory blocks. Each block holds 5 Records, which i memcpy one after another in a list of blocks and an int CountOfRecords.
We also have a DeleteRecord function that deletes (duh) a particular record from the memory block. Now, other than reducing the Count and shifting all next Records forward as to practically delete that Record, is there any way to ACTUALLY delete what is written with memcpy? Like writing something like a NULL as a struct instance? Memmove does not seem to offer such an application.
EDIT: I write the records as such
//block is the pointer to block,int is for the Count, and record is placed
memcpy(block+sizeof(int)+sizeof(Record),&record,sizeof(Record));
You basically don't want to move data around but instead set the memory to zero, how about memset?
memset(block+sizeof(int)+sizeof(Record), 0, sizeof(Record));
But you somehow have to remember, that the record at this point is zeroed out (not used), best by some property.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 5 years ago.
Improve this question
I'm looking for a reliable way to find unused memory in a C program's process since I need to "inject" some data into somewhere without it corrupting anything.
Whenever I find an area with only zeros in it, that's a good sign. However, no guarantees: It can still crash. All the non-zero memory is most likely being used for sure so it cannot be overwritten reliably (most memory has some kind of data in it).
I understand that you can't really know (without having the application's source code for instance) but are there any heuristics that make sense such as choosing certain segments or memory looking a certain way? Since the data can be 200KB this is rather large and finding an appropriate address range can be difficult/tedious.
Allocating memory via OS functions doesn't work in this context.
Without deep knowledge of a remote process you cannot know that any memory that is actually allocated to that process is 'unused'.
Just finding writable memory (regardless of current contents) is asking to crash the process or worse.
Asking the OS to allocate some more memory in the other process is the way to go, that way you know the memory is not used by the process and the process won't receive that address through an allocation of its own.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 5 years ago.
Improve this question
The syntax of malloc is malloc(num*sizeof(data_type))
I wonder why you need to specify a size at all. You could just specify a "large enough" number and everything will run fine.
The syntax is malloc(size). The only reason you're writing it as, for instance malloc(10*sizeof(int)) is because you're very rarely interested in the exact amount of bytes, but rather the amounts of elements. This also makes it portable and easier to change.
If you know that the size of int is 4 bytes (can vary from system to system) it is perfectly valid to write malloc(40) instead of malloc(10*sizeof(int)) but this can cause bugs if you recompile for a different system, or later decides that you need a long instead of an int.
And you need to specify a size. When you're invoking malloc(20) you will get a pointer that points to a chunk of memory that's 20 bytes. If you later realize this is not enough, you can use realloc to change the size. But you do need to specify a size, cause otherwise the OS will simply not know how much memory to give to you. Also, if malloc fails, it will give you a NULL pointer. One reason to fail is that you ask for more memory than currently available.
You CAN ask for more memory than you need. But what's the reason? The consequence will be that your program will demand more memory. That's not a good thing.
Sidenote:
You MAY get more memory than you request. malloc guarantees that you get at least the amount you ask for, unless the allocation fails. However, you should - for obvious reasons - never count on it.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I don't know if the question makes any sense but I'm new to C and concepts like the Heap so its a bit overwhelming for me right now. I've been reading a few articles about memory allocation using malloc() vs declaring variables That I need to know the amount of data I need in advance when I want to work with variables while with malloc() I don't.
I can allocate data at runtime as much as I need with malloc but how? Lets say I want to input temperature records of 100 consecutive days so I did something
like
int* temps=malloc(100*sizeof(int)).
Now while I was inputting data I realise that I needed to enter 110 days of records. How do I go about adding the additional data at runtime? Since I just allocated space for 100 ints. What difference would it have made if had I done int temps[100], I know I had to initialize the array again changing the int temps[100] to int temps[110] and then recompile the program again and starting the input all over again.
Now while I was inputting data I realise that I needed to enter 110
days of records. How do I go about adding the additional data at
runtime?
Use realloc.
What difference would it have made if had I done int temps[100]
You can't change this size anymore, it is fixed. You have allocated array of 100 integers, and you are done. While with above approach, you still can "resize" the array during run time.
Though note sometimes doing something like int x[100] can be fine depending on your situation, plus it saves you from memory management related issues. That said, use dynamic memory such as malloc, only when it is necessary (exactly because to avoid complications related to memory management).