 Hello, everyone. Welcome to our talk and this is also Zeradex. Can hackers launch a Zeradex attack on populars of wear only with Chromium in this talk? I will introduce how we use Chromium in this pop-up computer in many populars of wear, hoping to draw attention to browser security and applications of wear. This is our first DevCon presentation. Let's introduce ourselves first. We are all security researchers at TASID Security I'm Bo Hanliu, made engaged in browser security. I'm also a Google Chrome bug hunter. And Zhong Wang is our co-speaker. He made engaged in browser security and kernel security. He found several bugs in Apple Safari, Linux kernel, and VirtualBox. Another co-speaker is Guan Zhongli. He is co-founder and former captain of RecaPig CTM team. He previously focused on system and software security. Currently focused on LLM with security. There are six sections in this talk. Let's begin. First is introduction. As a browser security researcher, I researched the Chromium bugs for wear and wrote many end-day exploits. And I can do a little reversing, but I know little about web security. Given those skills, Kevin zeroed the RCE bugs in public software. And if so, what can I do to make this work easier? Now let's take a look at how Chromium has been integrated into public software. Firstly, there is Chromium-based development, which includes default mobile browsers. Second, there are browser component for various programming language. For example, the Electro framework is primarily used for a software development of Node.js, for C++, Java, and Dolphin language. CEF is also a commonly used library. Additionally, the QT web engine plugins is commonly used in QT. And the Chromium may also be present in other popular sublaying chains. So Chromium is an error-variant software. Based on data from CV and Google Project Zero, Chromium may be found around 3,300 vulnerabilities with CV ID each year. Of those, around 10 vulnerabilities each year are from in-the-world attacks. And also many of those vulnerabilities can be transferred into random RSEs through detailed analysis. Those vulnerabilities can also be introduced into popular software through the sublaying chain mentioned above. Google has an old ITU 12 vulnerability explorer. And the bug tail will be made public after being fixed 40 weeks with the bug tail. And you need to test the impact. Attackers can quickly make its private code. Sometimes it's even a zero debug for the stable version of Chrome itself. We strongly oppose the disclosure of vulnerability details before they are fixed. But it has to see, hackers has a lot of prior knowledge for Chromium-based software attacks. Therefore, we conducted the experiment on some popular software to see how long the introduction of those vulnerabilities can have an impact. Let's start with the definition of RCE window period. RCE windows period equals the time the vulnerabilities was fixed in the software. Minus the time the vulnerability was exploitable. This is hard to precisely determine the T exploitable. We use a new calculation method to roughly describe software's RCE windows period. The method is called active gate, which is the time difference between the software's update type and its Chromium component update type. The larger the difference, the higher the likelihood of the software being exploitable during the period. In our experiment, we select some popular software on the market, including Slack, Skype, Discord, and others. The experiment was divided into three styles. The first step, we download the software's old version through mirror state. The second step was to identify the browser component in the software, their version, and the release dates. In the second step, we calculated the active gate to describe the software's RCE windows period. We use our database, which concludes over 200 POCs to assess in testing. Those POCs were used to search for high risk exploitable vulnerabilities during the period. The final results are varied greatly, with difference of software having update gate, ranging from nine to 800 days. Wavebox's Chromium component was relatively independent and updated more frequently on the other hand, Dropbox hardly updated its Chromium component. The rest of the software mainly used the Electron or LabCF component, which most update periods over 90 days. Some software has a longer update period. This code has an average update time of 305 days. The shortest update period is over 70 days. As a result, 90 versions has a long RCE period, which was demonstrated at Black Hat USA in 2022. Other software such as Slack has more frequent updates with a path period of 30 days. However, when it hit a zero-day disclosure, they didn't deal with it in time. For example, Chromium zero-day bug was public disclosed on GitHub on April 2021, and Slack just released its new version the day before that day. However, it wasn't until June that the bug was patched. It has an RCE window period of almost two months. After analyzing updates, we have come to several conclusions. Firstly, RCE window period exists in most software, leaving attackers periods to find the bugs for exploring. Second, a software built on the Electron framework tend to have a shorter RCE window period due to the lower code company, which make updates easier to implement. Finally, we have observed that many companies has increased their update frequency at specific times. However, even with those effect, RCE window period still exists. Let's come to attack surface and vulnerability discovery. For desktop software, developers use browser components to display specific pages and trigger certain glance site behavior in specific scenarios, making glance site development more convenient and universal. However, for hackers, during the RCE window period, it's easy to launch zero-day RCE attacks when they can control the load in the page. This kind of attack has many advantages for hackers, such as having many exploits with end-day vulnerabilities and no domain-specific requirements. Therefore, our hackers need to find is a situation where they can control the loading page. So what's the scenarios that developers tend to overlook? The question is, what is the function of browser components? What code runs in the browser component? Let's start with how they are developed. For Electro, all codes are developed by Node.js. It's divided into main process and the render process, or communicate through IPC. All codes is stored in a resource filter and there are less modification to Electro framework code. So it's easy to locate the source code. If we can press, we can also recover them from the ASAR format. As for debugging, since there are less modification to Electro framework code, most of the time we can just use command blank to open internal development tools like ESPECT or remote debugging ports, just like this flag. Debugtron is a universal Electro framework debugging tools because C here is also competitive in this method. CEF is another popular component. Here we use libcfc++ library as an example. From the perspective of development, the code implanted by developers is divided into two parts. The private API function implanted by in C or C++ is used to impact the client behaviors that can't be implanted by browser components. The other part is the local resource code implanted by the HTML, which is the code running in the browser component and used it to display the interface. In the development logic, it initialized first and then registered a parsing and the processing logic of the privileged domain and then registered the privileged API function to form a jazz object for the local resource code to call. And finally, not the local resource from the perspective of the CEF library is actually a series of calls to exploit the function. For CEF, its feature exists in the form of a dynamic link library. And the use of CEF is more flexible and more check before use. A privileged API is implanted by C or C++ and the local resource code is implanted by HTML. And the location of the local resource file is uncertain and the file may be encrypted. So are there any common debugging method? Yes, you can hook the API in libcf and then get and modify what we want. For example, the developer will use the CEF stream reader create for file, CEF for zip reader create or other function to load the resource. We can get a field location and the encrypted password will hook in the info transfer between API functions as shown here. As for debugging, although developers call CEF initialize with static call pre-mentors, we can still dynamically modify the remote debugging port, a parameter to generate developed capabilities by hook. And we can also build more powerful debug tools as a development mode. Let's take a look at some cases that develops into our look. First is what list of loaded load. Developers are only allowed to use the browser components to open specific pages such as the official homepage. Other pages will be opened by default system browser maybe completed by calling shell is queued open. For example, SCAP has the same logic here. The first way to bypass check is the page directory direction. Here are three main ways. Have link navigation, three OX reduction, a JavaScript navigation. Its principle is that this kind of check is the handling click and then the page was loaded in Chromium component. And the subsequent jump in Chromium will no longer trigger the check logic again. So SSO is a good path to use as shown in the figure on the right. The following is a demo that use page redirection to imply RCE attack and software. For security region, all the software mentioned in this topic will not disclose the product information. Okay, after click, calculator is here. Another point is the check itself. Like incorrect regular expression or incorrect triple tech. This is another real world case. The check user a long regular expression. They ask check GPT and run here. It told me that there are many domain easily requested by hackers can pass the check. For example, ABCD JD.hk. This is the demo mentioned before. It's also an AM software. After bypassing the URL check, we can easily load our HTML code. We can easily pop up the calculator. In addition, another point is the special URL handler. There are two main aspects. One is the scheme adjusted in the system registry and the other is the custom domain adjusted in the browser component. This is the provided domain. It is easy to miss some check while operating in them. To follow is the demo use this method. We can see that AM software is a vulnerable area in this development case. Okay. The next is paid code injection. It's a class key pop, but let's focus on the unique aspects of XSS in Chromium based software. Here are three key differences. Firstly, XSS type. In Web Security, XSS typically includes reflective stored and DOM-based XSS. In Chromium based software, resources are often stored locally, so XSS in this context is typically DOM-based. Secondly, this vulnerability discovery method in Web Security, the code that handle a user input is typically located on the server side. So the bug discovered mainly through black box testing. However, with the code location tools, we previously developed with it. We can, Web Box code review in Chromium based software. Thirdly, the input source. In Web Security input, you really come from URL parameters or the database in Chromium based software. There may be fewer URL parameters, but more unique code input sources, which we will discuss in the next section. Based on those features, as a researcher, no little Web Security, I mainly use the following method to discover access to your local resources. Firstly, I use the tools we developed to decrypt local resources. Then I identified and protected the resources that result CSP. And filter out the input point that can be controlled. Finally, I trace wider, this input can trigger for the injection. This image is a real one case at all. I have abstracted the key code. And you can see that the get URL param function precise the parameters in the URL and put them into the page using inner HTML in two. Finally, leading to XSS. Another thing to notice that XSS vulnerability can also be introduced to the subline chain. For example, the ECU 2959 of TEPRO. A TEPRO can execute the JS code in TEPRO by exploring access to vulnerability in the mermaid library. And then use the provided API to achieve RCE. You can also use the Chrome and the vulnerabilities from two years ago, such as CVE, to 770 file or sellable to achieve RCE too. Here is a demo of the exploit for this case, which shows that a Chromium and a bug can also do the same things as a provided API bug. The app frame feature is often used in not taking all document applications to make a page display more convenient. However, when the scope of the app frame executes the limit, it can also cause security questions. This is more dangerous than in web security because it can be exploited without a provided API or specific domain need. We also find a RCE bug in a popular not taking software using this trick. We would have liked to release it here as an example, but it's being fixed, so we can't disclose it here. For desktop software, it may face much more complex situations than a website, such as no network or speed requirements. This requires some local cache to store this problem. We're reading or writing data. The cache is modified first and then updated with the server through communications. In this logic, the developer usually trusted the cache and don't check it again when updating or loading it. Cache data can exist locally in various format, both, such as database JSON or custom format. So how do we find them? The easy way is to monitor the program's fail read under write operations. The image on the right shows the applications that use SQLite to store cache data. You can see that when the database content is modified, there are no valid checks on the data when it's loaded, allowing any FRIM to be insert. Here is another interesting example. In a certain application, I found that the three-party components were added, the APE insert an FRIM here into the page. But the SRC attribute is strictly displayed here. But in the local cache, I found a custom property called HF. I modified it to access code and reopened the program. The page was modified to any HTML code here, which means that we bypassed the check by modifying the local cache. And another, when I assessed the web version of this APE, I found that the web page also changed to any HTML code here. This means that the server didn't check the update of the local cache and the vulnerabilities become stored XSS. Therefore, by using the code injection, we bypass the validation and achieve the RCE. And further, we polluted the server, which can lead to more remote attacks. Okay, some applications also allow developers to develop plugins and update them to the store. Use providing more convenient extension functions. Software gave plugins developers more functionality, but plugins usually need to be actually reviewed before put on the store. With the browser components, hackers may use it to bypass plugin reviews. For example, where plugin is reviewed, the page in the plugin is a normal page. But when it put on the market, the website is redirected to a page with expired code, thereby realizing a waterhole attack. The following is an example of entirely G IDEA software. The molecularest plugin is loaded and attacker can use the browser component to achieve RCE. So, where a plugin is reviewed is necessary by paying attention to the URL in it. Now in the video, we load the plugin. Okay, some functions may have a arbitrary page loading process such as a pre-rending of crawlers or nodes. For example, the pursuit was found in the RCE bug passive scanning function in 2021. Now our co-speaker, Wang Zhong, will give the other part of this talk. Thank you. Hello, everyone. I'm Wang Zhong, the co-speaker of this topic. I will finish the last part. Given the short duration of RCE window period, it is crucial to develop exploits quickly. When it comes to type vulnerabilities, a common technique is to use optimized functions to create the consistency that actually lead to type confusion. However, for use of free bugs, there doesn't seem to be a publicly universal exploit method. Here, we propose a universal exploit method for V8. 32-bit use that for free bugs, which will be demonstrated in Chromium Warden 91. Let's start by discussing some relevant background knowledge. V8's minimal garbage collection recycles objects from the young generation, which divides memory into two spaces. The newly located objects are put into the front space, and when the first garbage collection is called, it identifies surviving objects and copies them from the front space to the two space, updating object pointers. Then the front space and the two space are swapped and the next round of garbage collection is performed. During scavenging, there is also an additional set of root objects, which are pointers from old space to new space objects. V8 uses red barriers to track these references. When the garbage collection identifies relevant references in the old space, it does not reclaim the objects in the new space. Here is a Chrome issue 1.0.1.3.0, same says 1.0. This was caused by a missing red barrier when generating the last index object for red expression object. When last index act as the SMI range and the red expression is in the old space, well, the last index object is in the new space. The garbage collection mistakenly identifies object as reclaimable due to the lack of reference information, resulting in a used after free vulnerability. In V8, there is a type of a string called one byte internalized string. Its memory layout is as follows. From front to back, they are the objects, myp, hash, string length and the string's content. The core idea we used was to forge a string with an extremely large length and place the target object after the string in memory. Then we can use the search method of the string to find the address of the target object after the mark. Thus, we can construct the address of primitive. Using the same technique, we can place a JS array after the fixed string. By using the string's auto bounce right, we can modify the elements member of the JS array to point to arbitrary address and achieve arbitrary memory read and write. To fix such a string, we need to create a fixed string map. We use this map to identify object types so our core technique is hip-spring. We can hip-spring a large number of array buffer objects to obtain a stable address and then forge the necessary members of the string map at this address. Finally, we place the fixed string in a JS array and allocate a large number of JS array objects to occupy the last index placeholder. The fixed string is placed on the left of the JS array and forge the string object is on the right. Here is a demonstration video of our successful exploration in Chrome Morgan 91. So as for Chromium-based where we found firstly, a little bug or feature can lead to RCE attack. Secondly, there is lack of attention to the attack path of browser vulnerabilities now. So the attack surface is relatively rudimentary and hackers also can bypass mitigation directly using powerful Chromium bugs. This section is about how to achieve RCE attack without sandbox escape bug. The sandbox is a security protection mechanism of Chromium. Even if a hacker gets the render RCE, it still cannot get the full execution permission. This includes mandatory SS controlled environment, isolated process when HTML rendering and JavaScript execution. And finally, the limited resource access and limited IPC or kernel interaction access. The end day of sandbox escape is much less than the end day of render RCE. So how can we achieve RCE in sandbox enabled software without a Chromium sandbox escape bug? First, let's see what's the difference between Chromium-based software and Chrome browser? One is privileged API. It is used to implement some client side behavior in specific cases such as uploading files and downloading files. For renderer, it is a series of JavaScript objects. For browser, it is a series of handler code. Different frameworks have different implementations. The principle is to register some JavaScript objects in the context of the render process. And when the objects are called, we can execute the implemented handler in the browser process through IPC call. Based on this idea, there are usually two implementation logic for the privileged API. The first one checks the URL loaded by the browser components when it is initialized. If it is a specific domain, register the privileged API in the loaded context. At runtime, only the privileged domain can obtain the JavaScript object. So when we calling some function from this API, the browser processes calls it without checking the source domain. The second logic is to register the privileged API object, no matter what domain it is at initialization. And then the developer can check the domain when the privileged API is called. There are some problems with both methods For the first one, whatever LAN privileged web view gets a privileged context. For the second one, how to properly check the IPC access is from privileged domain. The research on elapsed point has become relatively natural. In August 2018, master shared research on context isolation, which is used to isolate the context between the renderer process and preload. If this configuration is disabled, even with sandbox protection enabled, the renderer process can also call privileged functions exported from preload, such as shell.open external function. At Black Hat Asia in 2019, Luca shared his research on preload. He discovered that even with sandbox protection enabled, preload.js may still access certain native node classes and some electron modules. Attackers can use prototype solution to execute arbitrary IPC calls. At Black Hat USA in 2022, a sandbox bypass method was demonstrated when the renderer process could load the preload.js fell in a child frame by overwriting the node integration in subframe members of the web preference of the context. We can also overwrite the context preference context isolation and disable CISO in new renderer process. Then we can send an unauthorized IPC call with prototype solution. We also found some interesting and wide ranging issues with the second model, but since the renderers are working on a fix, we will share the details when it's fixed. We will make some security recommendations for Chromium-based software in two aspects. Firstly, it is necessary to update the latest version of the Chromium. Secondly, for software with high coupling, it's better to use a stable development version and introduce security patches with software updates. Thirdly, we should enable the Chromium sandbox and last, we need to disable and use the software functional realities or enable internal mitigations. For developers, we can add back-end validation and a front-end rendering validation follow the principle of latest privilege, both privileged domain range and privileged API function. We enable universal mitigation such as CSP and be wacky about input from unexpected sources. Here is the conclusion and take a waste of this topic. In this topic, we verify that a large number of Chromium-based software have RCE window period and then we summarize some software attack surfaces that cooperate with the RCE window period which makes the hackers can launch their own attack with Chromium end days and give real-world examples. And we share a general way it's use of a free exploit method in 32-bit which may help make exploit faster. At last, we provide some security recommendations to help strengthen the security of Chromium-based software. At last, thanks to all the partners for their contribution to this topic. Here is the list. Okay, thanks for your listening. Here is the references of this topic. If you have any problem, you can contact us with email or on Twitter.