Zhou Aiting(@zhouat1) of Qihoo 360 Vulcan Team
Affected versions：Chrome Version < 66.0.3359.170
Run poc file, get the ASAN crash dump：
1) The code corresponding to the crash point is shown in Figure 2:
Figure 2 crash point code
Since the value of m_nOrigOutputs is outside the scope of the array request space, an out-of-bounds write will occur at line #55 of Figure 2.
2) Array declaration and the size of the allocation:
The source code corresponding to the ASAN crash dump stack:
Figure 3 The source code around ASAN crash dump
With the help of the ASAN crash dump, we can locate the following source code: The size of the array is determined by the return value of the following function.
Figure 4 Calculation of the required space of the array
In Figure 4, set breakpoint at code line #100, after running multiple times, we can see that the value of
total overflows when parsing the poc file.
Since the variables (m_nOrigOutputs, m_Exponent) can be precisely controlled in the pdf file by controlling the corresponding fields, we can simplify the assignment action . Control m_Exponent = 0, then FXSYS_pow(input [i],m_Exponent) will always be 1.
The contents of m_pEndValues array come from the pdf file and are fully controllable, so it’s very simple to exploit this vulnerability.
Figure 6 The contents of the overflow array are fully controllable
Figure 7 hijacking instruction register
The Chrome team fixed the vulnerability quickly:
Figure 8 Google Fixed the vulnerability
Figure 9 Fixing code _1
Using FX_SAFE_UINT32 replace previous uint32_t, the representation in memory : the upper four bytes are the value of unsigned int, and the lower four bytes hold the data overflow identifier.
Since the operator is overloaded, the overflow is automatically checked when doing a numerical calculation of this type, ensuring that overflow and underflow do not occur. The specific check method is to use the compiler’s built-in overflow detection function __builtin_add_overflow. After the overflow occurs, the function where the result_array is located returns directly. (See Figure 10)
Figure 11 Fixing code _2
Affected versions: Chrome Version < 67.0.3396.99
After the official fix of CVE-2018-6120 was out, we noticed such data type:
CFX_FixedBufGrow<float, 16>, its constructor is shown in Figure 12:
Figure 12. Constructor for CFX_FixedBufGrow
CFX_FixedBufGrow<float, 16> result_array(total_results) meaning :
(1) When the required space is not greater than 16, the stack space of 16 float types is returned;
(2) Otherwise use the parameter (total_results) to request a piece of memory on the heap.
The problem is that the argument passed in here is unsigned int, while the formal parameter is int.
CVE-2018-6120 out of bound write vulnerability can be triggered again :)
For the latest stable version, the new vulnerability described in this section is no longer exploitable, so we decided to disclose the details here.
More than three years of functional discussion once again accidentally killed the bug.
A non-security update from Chrome last month unexpectedly fixed this vulnerability in section #6. The reason is:
after a series of performance tests passed, Chrome removed the CFX_FixedBufGrow type and replaced it with std::vector
nice work, Google Chrome Team :)
2018-04-17 submit bug issue
2018-04-18 issue fixed
2018-04-19 issue closed
2018-05-10 Google credited to Qihoo 360 Vulcan Team