A vulnerability stemming from floating-point arithmetic precision errors exists in the QuickJS engines implementation of TypedArray.prototype.indexOf() when a negative fromIndex argument is supplied.
-
The fromIndex argument (read as a double variable, $d$) is used to calculate the starting position for the search.
-
If d is negative, the index is calculated relative to the end of the array by adding the arrays length (len) to d:
$$d_{new} = d + text{len}$$
-
Due to the inherent limitations of floating-point arithmetic, if the negative value $d$ is extremely small (e.g., $-1 times 10^{-20}$), the addition $d + text{len}$ can result in a loss of precision, yielding an outcome that is exactly equal to $text{len}$.
-
The result is then converted to an integer index $k$: $k = text{len}$.
-
The search function proceeds to read array elements starting from index $k$. Since valid indices are $0$ to $text{len}-1$, starting the read at index $text{len}$ is one element past the end of the array.
This allows an attacker to cause an Out-of-Bounds Read of one element immediately following the buffer. While the scope of this read is small (one element), it can potentially lead to Information Disclosure of adjacent memory contents, depending on the execution environment.
Weakness
The product reads data past the end, or before the beginning, of the intended buffer.
Potential Mitigations
- Assume all input is malicious. Use an “accept known good” input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
- When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, “boat” may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as “red” or “blue.”
- Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code’s environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
- To reduce the likelihood of introducing an out-of-bounds read, ensure that you validate and ensure correct calculations for any length argument, buffer size calculation, or offset. Be especially careful of relying on a sentinel (i.e. special character such as NUL) in untrusted inputs.
References