In May 2023, we received a vulnerability report from an anonymous researcher regarding a vulnerability in Apple Safari. It turned out to be an interesting classic integer underflow vulnerability. Apple assigned CVE-2023-38600 to this issue and fixed it in the following security advisories:
—
—
— object of size 0x1000 is created. Note that it is typed array.
3 - A function is defined which method is called, which copies part of typed array to another location in the same typed array without modifying its length. It takes 3 arguments:
a - insert (“target”) position: The value provided here is 0x20.
b - start position: The value provided is an object having a Let’s go step by step inside this function and see what is going on.
Here is the code of the unpatched version of the function:
The function first gets the length of ArrayBuffer at (1) and saves it into the length variable. This is 0x1000 based on the PoC. Then, at (2), (3) and (4), it parses the arguments we passed in our call to copyWithin method by calling argumentClampedIndexFromStartOrEnd function for each argument, assigning the results to the to, from and final variables respectively. The code of argumentClampedIndexFromStartOrEnd is as follows:
The main goal of this function is to perform a sanity check (e.g., to check that the value is not more than the length). Let’s see what happens when each argument is parsed:
• First argument: The provided value is the integer 0x20. Thus the argumentClampedIndexFromStartOrEnd function will reach (2) and return 0x20 after checking that it does not exceed length (0x1000). So the to variable will be 0x20.
• Second argument: The provided value is an object having a valueOf callback. Thus execution reaches (3), where a call to toIntegerOrInfinity method is made. This will invoke the valueOf callback function. Inside the callback, the PoC changes the ArrayBuffer length to zero and then returns a value of 0. Thus, the from variable will be 0. Note that the length variable remains set to 0x1000, which is now out-of-date and incorrect.
• Third argument: The PoC did not specify a third argument, so it is undefined. Therefore the condition at (1) is true, and argumentClampedIndexFromStartOrEnd returns the length value of 0x1000. This becomes the value of final.
Now that it is done with parsing arguments, genericTypedArrayViewProtoFuncCopyWithin function reaches (5) to compute count (the number of array elements that need to be copied):
size_t count = std::min(length [0x1000] - std::max(to [0x20], from [0]), final [0x1000] – from [0]);Therefore, the count variable will be 0xfe0.
We now reach the final part of the function, where it performs the actual copy. Here, things get interesting. The developers were aware that it is possible that the ArrayBuffer object has been resized, and mentioned that in the comment:
At (6) the code fetches the updated length, which is zero. As it is not equal to the previously extracted length (0x1000), a further check is done to make sure the count is within bounds:
At (7), the length variable will be adjusted to the updated length, which is 0. The code also attempts to adjust count accordingly. However, this doesn’t go properly. to is already 0x20, so an integer underflow occurs, causing count to get the value 0xffffffffffffffe0. This huge value is then used as the count argument in a call to the memmove function where the crash occurs.
The Patch
The issue was and follow the team on , for the latest in exploit techniques and security patches.
SOCIAL SHARE CARD GENERATOR