Vulnerabilities in Git versions earlier than v2.7.1 allow attackers to execute code remotely.

Vulnerabilities in Git versions earlier than v2.7.1 allow attackers to execute code remotely.

It is understood that security researchers found a security vulnerability in all versions of Git before version 2.7.1, which exists on both the server side and the client side. Attackers can exploit this vulnerability to cause the buffer overflow of the target system and execute code remotely on the target host. (Vulnerability information has not been published yet, CVE-2016-2324 and CVE 2016 release 2315)

Previously, security researchers analyzed and described the buffer overflow vulnerability. For details, click here.

On July 6, February 11, 2016, Jeff King wrote the following content in a git Security Email:

"Thursday, February 11, 2016, 02:32:49 P.M., 'La Liga l cellier' writes in Git security: using a long file name or a large number of nested trees, you can push or clone a Git code library, which is the way this vulnerability works.

The problem is that the number of versions affected by this vulnerability is very large. Many versions of Git code branches are still in use, and many of them are stable code branches. Therefore, I think this vulnerability is a very serious vulnerability. It should be certified by CVE, and I also think that details of this vulnerability should be published ."

Yes, as you said, I do think that Git earlier than v2.7.0 has a heap overflow vulnerability. However, I do not think the only cause of this problem is the path_name (), which still exists in the latest version.

The Code released earlier is messy and difficult to read. So I sorted out the relevant code and provided it to you:

char *path_name(const struct name_path *path, const char *name){         const struct name_path *p;         char *n, *m;         int nlen = strlen(name);         int len = nlen + 1;          for (p = path; p; p = p->up) {                 if (p->elem_len)                         len += p->elem_len + 1;         }         n = xmalloc(len);         m = n + len - (nlen + 1);         memcpy(m, name, nlen + 1);         for (p = path; p; p = p->up) {                 if (p->elem_len) {                         m -= p->elem_len + 1;                         memcpy(m, p->elem, p->elem_len);                         m[p->elem_len] = '/';                 }         }         return n;}

According to the vulnerability description, the size of memory space allocated by the system does not match the size of data to be written by the strcpy function. However, to some extent, we can use the memcpy () function to solve this problem, because at least the initial value of "len" matches the number of data bytes that we need to write (maybe the related value is not a real value, but as long as the size of the data we write does not exceed the allocated value of the memory space ).

However, after the system cyclically calculates the data, the value of len changes accordingly. If you have obtained the Sequence Value of the path parameter (each value is less than 2 ^ 31), the system will add these values and obtain a smaller positive value. For example, the data to be processed is A/B/C, and the data length is as follows: A = 2 ^ 31-5, B = 2 ^ 31-5, C = 20. After calculation, the system will eventually get len = 10. Then, the buffer size will become smaller, so that the data of C cannot be stored. As a result, the system will not be able to store the data to be written in the second round of loop.

I have also proposed my own solutions to this problem. I found that you only need to convert all the "int" Integer Variables to "size_t" to properly alleviate this problem. Although this does not perfectly solve all the problems, it also means that in a 64-bit operating system, the user will need to use a value of 2 ^ 64 to trigger this vulnerability, which is impractical. Although this operation can help the 64-bit system to avoid this problem, the 32-bit operating system is no longer available.

There is also a noteworthy point that there is a similar problem in the path_appendnew () function in the tree-diff.c. We need to build a complete path name in strbuf and use the corresponding function parameters to detect memory overflow. However, after we pass the length as an integer parameter to the function, the system will assign a FLEX_ARRAY struct to process the passed parameters. I think this question is more interesting than the one we discussed earlier. Because we can trigger this vulnerability through git-log, and the path_name () function is used only when the system re-encapsulates the code. Therefore, although this problem will always affect you, it will not happen when you first clone the code base.

The solution I proposed for this problem is similar to the previous solution: we need to use size_t. In this way, at least a large value must be assigned to the 64-bit operating system to trigger this vulnerability. Although the 32-bit operating system is not so good, it can at least help you avoid the failure of memory space allocation.

That's why I submitted the vulnerability mitigation solution. I also admit that these solutions cannot solve these problems perfectly. The perfect solution should be: Always use size_t to store the return value of the strlen () function. Before we need to calculate the value of size_t, we must perform overflow detection on the memory space.

Some readers may remember a series of related articles I published last year. Interested readers can take a look at them. Maybe they can discover something new.

In addition, I think we can discard the path_name () function. The only use of this function is to calculate the package name hash value of the data packet object. In fact, we do not need to refactor the data packet in the memory to achieve this.

It is understood that all the issues discussed in this article have been fixed in git 2.7.1, this version removed path_name (), size_t in the tree-diff.c file, and buffer overflow detection mechanism. In fact, Github has previously fixed this issue for its enterprise users. Currently, Bitbucket and GitLab are still affected by this problem. Although this vulnerability has not yet been certified by CVE, I believe that relevant personnel will soon handle this issue.