v2. 7. 1 The following version of the Git in the presence of vulnerabilities, or may lead to remote code execution-vulnerability warning-the black bar safety net

ID MYHACK58:62201672660
Type myhack58
Reporter 佚名
Modified 2016-03-17T00:00:00


It is understood that the security researchers in 2. 7. 1 version before all versions of the Git found a security vulnerability in its server and client are the presence of this vulnerability. An attacker can exploit this vulnerability to cause the target system to a buffer overflow, resulting in the target host achieve remote code execution. (Vulnerability information currently has not been released, CVE-2 0 1 6-2 3 2 4 and CVE 2016-2315)

Prior to this, security researchers have worked on this buffer overflow vulnerability analysed and described, the specific content please click here for viewing.

2 0 1 6 years 2 Month 1 1 May, Jeff King in the git security of the mail, wrote down the following content:

“2 0 1 6 years 2 Month 1 1 day, Thursday, 2 p.m. to 3 2 minutes 4 9 seconds,‘Laël Cellier’in the Git security wrote: use a longer file name, or a large number of nested tree, you can push or clone a Git repository, that's what this vulnerability works.

And now the problem is that, affected by this vulnerability and the version number is very many, a large number of versions of Git Code Branch is still in the use state, and wherein there are a lot of stable Code Branch. So I think this vulnerability is a very serious vulnerability, which should get a CVE certified, and I also think it should be the vulnerability of the detailed information published out.”

Yes, as you said, I also do think that less than v2. 7. 0 version of the Git in the presence of a heap overflow vulnerability. But I do not believe that the cause of this issue appears the only reason is one of the path_name (), and the current latest version still exist to this problem.

Since before the release of the code is relatively messy, read up very difficult. So my relevant code were consolidated, and available to everyone:

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 system of the allocated memory space size and the strcpy function needs to write the data size does not match. But in a way, we can use the memcpy()function to solve this problem, because at least“len”of the initial value and we need the data to be written number of bytes is matched, perhaps related to the value not real value, but as long as we write the data size does not exceed the memory space of the assigned value.

But in the system the data cycle after the calculation, the“len”value will be changed accordingly. If you have access to the path parameter of the sequence of values for each of the values are less than 2^3 1, and the system will put these values are summed, and drawn to a smaller positive value. For example, we need to process the data for A/B/C, in which each data length is as follows: A=2^31-5, B=2^31-5, C=2 0, the system after the calculation of the final will get len=1 to 0. Then, the size of the buffer will be smaller, so that not to store C data, as a result, the system will not be stored in the second cycle the desired data to be written.

For this problem, I also put forward my own solution. I have found that just need all the“int”integer variable converted to“size_t”may be appropriate to alleviate this problem. Although doing so is not a perfect solution to all problems, but it also means that in a 6 4-bit architecture of theoperating system, the user will need to use a length of 2^6 value of 4 to trigger this vulnerability, which is very impractical. Although this mode of operation can help to 6 4-bit system to avoid this problem, but the 3 2-bitoperating systemthere is no way.

There is also a noteworthy place in the tree-diff. c path_appendnew()function also exists a similar problem. We need in the strbuf to build a complete path name, and using the corresponding function parameter to memory space overflow is detected. But when we the length length as an integer parameter passed to the function, the system will assign a FLEX_ARRAY structure of the body of the incoming parameters for processing. I think this issue than we previously discussed issues are to have meaning. Because we can use git-log to trigger this vulnerability, but only when the system code to re-package the process it will use to path_name()function. So, while this problem always will for you have an impact, but will not in you just start to clone the code repository when a problem occurs.

While I'm on this issue, the proposed solution and the prior solution is similar: we need to use size_t for. As a result, at least can guarantee in 6 4 bitoperating system, must be assigned a larger value in order to trigger this vulnerability. Although in the 3 2-bitoperating systemthe effect is not so good, but at least can also help you avoid memory space allocation failure.

So this is why I want to be this vulnerability mitigation scheme submitted reasons. I also acknowledge that these solutions are indeed not the perfect solution to these problems. The perfect solution should be: always use size_t to store the strlen()function returns a value, and when we need the size_t value is calculated prior to processing, must be the memory space to do overflow detection.

Maybe some readers remember my last year in the publication of a series of related articles, interested readers can take a look, maybe we can find something new.

In addition, I think that actually we can be completely deprecated path_name()function. The function's only use is to calculate the data package object of the package name hash value, in fact we do not need to pass in memory to reconstruct the data package to achieve this.

It is understood that herein all of the issues discussed are already in the git 2.7.1 version got the fix, this version removed path_name(),tree-diff. c file in a size_t, and buffer overflow detection mechanisms. In fact, prior to this, Github has for its enterprise users to fix the problem. Currently, Bitbucket and GitLab will still be subject to this problem. Although at present this vulnerability has not been CVE certified, but I believe that the relevant personnel will soon to this issue for processing.