What is memory security _ memory

Recently engaged in a number of software security aspects of the online public class resources to integrate, this work will be launched in October this year. So far, I've done a buffer overflow, formatted string attack and some other C-language weaknesses in the material collection. After giving these materials, I want to ask, "What do these mistakes have in common?" The answer is that they all violate the principle of memory security. Next I will explain what memory security is defined, and why the above C-language vulnerabilities violate the principle of memory security, and conversely, how memory-safe languages such as Java Guarantee memory security.

Given that memory security is a common term, at first I thought it was not difficult to find the definition. But in fact, it's a lot harder than I thought.

The purpose of this article is to find out the exact definition of memory security in C, which should be semantically explicit and, more importantly, be able to distinguish between memory-safe and unsafe code. The simpler the definition, the better. My final definition is based on two concepts: definition/undefined memory (defined/undefined memory) and capability pointers (pointers as capabilities). If you have a better way, please let me know. Five taboos: The latest article on systematization of Knowledge (SoK), Eternal War in Memory, uses a common way to define memory security. That is, if a program does not have a memory access error (Memory access errors), it says that the program is memory safe. Memory access errors specifically include the following:

Buffer overflow NULL pointer dereference use on memory free (of illegal already-freed ter, or a non-malloced pointer)

The Wikipedia page on memory security gives a similar definition. The list itself is not problematic, but it is biased to use it as a definition of memory security. Strictly speaking, this list should be derived from the definition of memory security, not the essence of memory security. So what exactly is the definition of memory security?
Do not access undefined memory below is memory security a more reasonable definition: Memory security is not access to any undefined memory. Undefined memory is memory that is not assigned to a program, possibly a heap, or a stack, or a static data area. George Necula and his students, in the process of completing the Ccured project, were a project aimed at strengthening the memory security of C programs, proposing a program for memory security that never accesses undefined memory. We can assume that, conceptually, memory is infinitely numerous, and that the allocated memory is not reused even if it is retracted (memory infinity). In this way, the memory after the recall is permanently undefined.

Obviously, this definition contains the contents of sections 2nd and 3rd of the list above, and if the uninitialized memory is also considered undefined, the 4th can be included, and if you assume that the free operation can only operate on the defined memory, the 5th strip can also be included.

Unfortunately, this definition does not include the 1th, the buffer overflow. For example, the following program, according to the above definition, program 1 is memory security, because the memory written in the four is already allocated memory, even write the data type is also right. The problem is that when writing data to buf[5], because of the buffer overflow, the data is actually written to the variable x, which is clearly not memory safe.

/* Program 1 *
/int x;
int buf[4];
BUF[5] = 3; /* Overwrites X * *

Note: The translator in the process of translation found that the above degree of line 2nd and 3rd should exchange positions, this should be the author's clerical error.
Infinite space We can use the extended definition to fix the error that appears above. We assume that when allocating memory, it is not a continuous allocation, but an infinite distance.

With the above program 1, because the memory area of BUF and X is discontinuous, it is clear that, according to the extended definition, access to the buf[5] is not defined, so it is not memory safe. The above example says that the overflow in the stack, the overflow in the heap and the static data area can do similar processing. Note that after adding this extension, you cannot convert data of type int to pointers because the pointer requirements are infinite and the int type data is finite, so it is quite possible that the int you chose does not correspond to a valid memory region. Emery Berger and Ben Zorn, in their diehard memory allocator work, want to make this definition a reality by randomly allocating memory.

Although we are getting closer to the right definition, we have not yet reached the right definition. Look at the 2nd program, which has a slight change in program 1.

/* Program 2 *
/struct foo {
  int buf[4];
  int x;
};
struct Foo *PF = malloc (sizeof (struct foo));
PF->BUF[5] = 3; /* Overwrites Pf->x * *

In program 2, the buffer overflow occurs in the structure body. Of course we can assume that different field is infinitely far apart, so that program 2, like Program 1, is not memory safe. But this assumption is not consistent with the actual situation. The C standard allows the compiler to decide how far apart the different fields are. On the other hand, the C standard also suggests that a record correspond to an object. Many programs convert one struct to another, or assume a certain interval distance, and many compilers support both operations. So the current definition is not good enough because it relies on assumptions that are inconsistent with reality.
Ability pointers now I'm going to say what I think is a better definition, a definition that is inspired by Softbound, softbound by Santosh Nagarakatte and several other collaborators, working to make programs written in C more memory-safe.

In the previous definition, we mentioned the definition of memory and undefined memory, the definition of memory is already allocated memory, undefined memory is not allocated or after the allocation of memory is recycled, after the memory is no longer reused, if a program access to undefined memory, we say it is not memory security. Based on this definition, we add the concept of the ability pointer, which means that there is an area of memory associated with each pointer that can be accessed by this pointer. With this concept, the pointer can be viewed as a ternary group (p,b,e), and p represents the pointer itself, and the area of memory that the pointer can legitimately access is determined by B and E. In a program, the only P,b and e that really operate are conceptually present, and they exist to determine whether an operation is memory safe.

Here's an example of program 3 to illustrate this concept, drawing the following memory graph to make the problem clearer.

/* Program 3 *
/struct FOO {
  int x;
  int y;
  char *pc;
};
struct Foo *PF = malloc (...);
Pf->x = 5;
Pf->y = 256;
PF->PC = "before";
PF->PC + 3;
int *px = &pf->x;

The last two lines of program 3 are key. Adding and subtraction the pointer to create a new pointer is and is legal. In the example above, the P-value of the PC is added, but within the range specified in B and E, the execution * (PF->PC) is legal. If the PF->pc + + 10 is executed first, then executing * (PF->PC) violates the principle of memory security, even if pf->pc points to an already allocated memory, because the range specified by B and E is already exceeded.

The last line of program 3 creates a pointer px to the first field of PF, because the first field of PF is a variable of type int, and px b,e limits the PX-accessible memory area to that field. This avoids the buffer overflow described in program 2. If we copy the PF range directly to PX, we can access the field outside of this field via PX, which is obviously unreasonable.

It is illegal to convert an integer to a pointer, whether it is a direct conversion or an indirect conversion. Direct conversions, such as P = (int *) 5, indirect conversions, such as P = (int * *) PF. By definition, this conversion operation is directly ignored, and only legitimate pointers can be referenced, and the scope of the pointer is determined when it is created. According to our definition, the following procedure is legal.

/* Program 4 *
/int x;
int *p = &x;
int y = (int) p;
int *q = (int *) y
*q = 5;

When P is converted to integers of type int (line 4th), the B and E identified by p at the time of creation are still preserved, so after line 5th, P's B and e are passed to Q. If you add this line to the end of program 3 above, then execute *p = malloc (sizeof (int)), and then execute **p, printf ("%d\n", pf->x) it's all legal. That is, an area of memory that was previously an integer can be modified to include a pointer, which can be referenced, and it is safe to treat the pointer as an integer, but not the other way round.

To some extent, the definition of memory security described above is a form of type safety, with only two types, pointer types and non pointer types. The above definition is nothing more than a description of the following three issues. 1, the pointer is only created in a secure manner, which is the safe way to define the memory area that the pointer can access when the pointer is created, and 2, only to be referenced by the pointer in the area of memory it is allowed to access; 3, this definition takes all five types of errors into account.

What do you think. I can give you a definition of how to write memory security in the C program to help you. If there is an example of how memory security is actually unsafe by definition, or by definition as an example of unsafe memory and actually security, if so, how do we extend the definition in a way that defines simplicity and makes it more adaptable.
Conclusion: You may be thinking that reading this article is an academic exercise. What does it mean to define memory security?
For me, a good definition relates to the development of science. When I read a scientific literature claiming to guarantee memory security, if I knew that the definition of memory security was not the same as what the author understood, then I would never have understood what the author was saying. On the big side, these vague definitions actually hinder the progress of science. For example, there is an article claiming to be a technology that solves memory security, and if you don't know the definition of memory security, the idea of validating or refuting it will be impossible to talk about. Static Error detection using semantic inconsistency inference and large-scale analysis of Format String vulnerabilities I N Debian Linux These two articles have reading value, think about what they say is the meaning of memory security.