Blog

Introduction When we examine a third-party library vulnerability in a real environment, we often encounter numerous complex variables that exist within the vulnerability’s context. Exploiting such a vulnerability is not as easy as one might imagine. Here is the information we know: The overflowed variable huffman_tables, has a size of 0x2f28. The heap chunk is allocated in the renderer’s ThreadPool, while most objects are allocated in the main thread. We can write a partially controlled 4-byte integer with an offset that is a multiple of 8 bytes. In Chrome, different-sized heap chunks are stored in separate buckets, isolating objects of different sizes to ensure security. Typically, achieving heap exploitation in Chrome requires identifying objects of the same size for layout purposes and then utilizing Use-After-Free (UAF) or Out-of-Bounds (OOB) techniques to manipulate other objects, leading to information disclosure or control-flow hijacking. In the following, we will share the objects we have discovered, as well as attempting to bypass this mechanism. ...

Vulnerability Localization In the initial phase of vulnerability analysis, due to the absence of readily available PoCs or detailed analysis reports, we first attempted to read and understand the patch code for CVE-2023-4863 in the upstream repository of webmproject/libwebp. However, the WebM Project’s official patch was relatively complex, making it difficult for us to accurately pinpoint the root cause of the vulnerability. Thus, we turned our attention to Apple’s official patch for CVE-2023-41064, and performed a comparison of the ImageIO framework before and after the update using BinDiff. We noticed that Apple’s patch involved fewer code changes and was much easier to understand. ...