 Hello, I am Sung Joon Kim from NSRI. In his talk, I represent the misdefined open source crash reporter on in-depth secret analysis. First of all, I explain the rationale for the necessary of a crash reporter and each basic operation. Then, how it is applied to the open source crash reporter for Linux. Lastly, I will show several secret flaws found in the project. We often experience software crashes on various applications. Since advanced and enhanced testing techniques are widely adopted in the software development and testing period, the crash has been quite reduced compared to the past. However, with increasing the number of applications, the number of crashes is also increasing. And users may often experience those pop-up window when they meet software crashes. Fixing the crashes can be very time consuming and difficult. The crash occurs only under certain conditions and the program turn it immediately. And it is very difficult to reproduce it. In addition, it is very difficult to gather data about the crash itself and various environmental information to fix it. Fixing crashes is not limited to the developer group. Users may encounter crashes more often than developers do. However, users do not know how to provide this information to developers and there is no way to do this. A crash reporter is an amount automated tool for fixing crashes. The crash reporter collects crash information such as memory snapshots, and CPU registers at the moment the crash occurs and writes a crash reporter to the file. In addition, additional information such as memory map and execution environment information are collected and added to the file. The collected information is transmitted to the developer and they replace using the collected information and the code is prepared and applied to the latest release. The crash reporters have already been applied to various platforms. In Windows, it has been installed since Windows Vista has a service called Windows error reporting. Basically, it collects crash information and allows developers to debug it in the form of postmortem. After that, if a solution can be provided immediately, feedback is also provided. It is Windows error reporter GUI. Next, automatic bug reporting tool is a crash reporter tool running on the reddit linux series. In the same way, when a crash occurs, core dumps or metadata are collected and delivered to the server. Currently, AVRT automatic bug reporting tool covers applications written in C, C++, and Python languages. And cases where kernel loops occur. For instance, since reddit enterpracening 6.3 version, it covers a case where a kernel penny occurs when an additional package is installed. This figure shows the GUI of AVRT. Code stack and instruction pointer and signature are used as a technique to analyze the crashes and solve them. Code stack relies on code stack at the crash point to find unique bugs. And instruction pointer uses the crashes in instruction address to be deep crashes. And signatures adopt the program-specific characteristics to the code stack techniques for more effective trades. So in this talk, we perform a systematic analysis of the open source crash reporter. Most open source reporters, such as reddit, AVRT, or an opened press reporter, work very similarly. Here, we targeted event error tracker and examined its operation and core functions in detail. Later, we want to share the safety flaws we found. We enumerate the security suite and check what safety issues are occurring and through these security streets. Open the error tracker provides a feature for a crash reporter that is similar to the WER, windows error reporter, reporting, and AVRT automatic bug reporting tool. It collects system hands which last 30 seconds and other severe errors to the end users and delivers them to the open server. It also provides the ability to handle tunnel crashes or crashes in Linux containers. This talk focuses on the base operation during the crash. Open to error tracker consists of two parts. A port implemented in Python script and is called when a crash occurs in the corner. It intercepts a port dump including memory snapshot and CPU registers collected by the corner and gathers various metadata. After that, a UI for user consent is also provided that is essential to deliver the collected information to the server. Hoopsie was previously called a report team in the past. And as the name suggests, it is a demo that delivers information collected by a port to the server. This demo is also automatically installed when a desktop or server is installed. And it is sent to the open server base.opt.com. Now I will explain in the order of a port, Hoopsie, and this chain. A port is called immediately after a crash occurs by the corner's core pattern handler. The core pattern handler is specified in track C's corner core pattern and is as follows. The path to the approach script is followed by the pipe and that's the crash program's PID process ID and signal number and core file size are passed as arguments. Thereafter, the approach script handles the core dump received through the pipe and uses the PID to record process execution environment information and voice information. For reference, the crash information generated in the container is delivered to the approach script through socket IPC. This is a step for generating a crash report. The information collected in the previous step is saved in the barcrash directory. At this time, the file name is composed of executable names with absolute path and user ID and it has a crash file extension, that crash file extension. In addition, the approach script can exclude unwanted process crash report through the approach egonor.xml file. That user can define and modify in advance. The crash report basically consists of two parts, approach dump and metadata. Metadata includes waste list information related to the crash and package version and argument passed to the execution environment and the call information located in proc bar system and is retrieved as more advanced information. Actually, in proc bar system, the memory members of the process and the number of running threads and detailed information related to the corner are located. The core dumps are handed over from the corner to the airport including memory snapshots at the moment of crash, CPU register, etc. Post-modern debugging can be performed using that information. In addition, it is also possible to complete a step trace through retracer using the collected information. The Nexus tab is gained consent from users. The file created in the previous step has that crash file extension in barcrash directory and hence the user permissions of the program. After that, if there is a crash report newly created by the update notifier running on the OS, execute the app-apport-gtk program. The app-apport-gtk program is one you often see when it crashes or hangs. If the user approves, it creates a file with that un-modified extension in the barcrash directory. This is the process of executing the basic operation of the app-port. The Nexus tab is the operation of the Hoopsie demo. Hoopsie is a demo and performs the function of delivering crash reports with user consent to the open server. First, make sure you have the internet connection and do the job. If there is no internet connection, the job is inserted into a queue to process later. Once our internet connection is established, the crash report in key-value pairs is parsed and inserted into the Intimate Data Structure G-Hash table. After that, it encoded in binary JSON format for HTTP post-operation. This encoded data is transmitted to the lazy server in Ubuntu. CoreDump is often very large since it contains the contents of the memory snapshot. In order to prevent such data from being frequently transmitted to the server, a few of the first text signatures was introduced. Hoopsie first transfers the data without CoreDump to the Ubuntu server. At this time, the text signature which is generated by a refresher using CoreDump with needed debug symbols is generated and transmitted together. The text signature example is as follows. The server requests a CoreDump if there is no data of the same text signature, then it's compressed and transmitted using HTTP port. On the other hand, if the text signature already exists, the URL including the UUID value for the corresponding information is returned. The server puts the data received from the Hoopsie into the database, and if a CoreDump is requested, the CoreDump is sent from the Hoopsie is recued to the retracer. After retracing, the signature for the text trace is computed and recorded in the DB. The results are displayed on nr.ubuntu.com. So far, we have looked at the operation process in the order of a port, Hoopsie, this chain was focused on the delivery of the crash report. Now, I'll explain the core features and more in a port and Hoopsie. A port is said to prohibit running multiple instances at the same time. The reason is that several applications only crash at the same time, and if a series of crashes occur at once, it puts a lot of bird system burden on the system. So, they are pressed processed in sequence. To do this, it uses a firebase lock. If the lock is acquired, the port is performed mutually. Next, the port drops its privilege during the operation, partially dropping privilege and totally dropping privilege. At first, only the real UID user ID is changed, leaving the effective UID as it is. We call this as partially dropping privilege. The reason for changing only the real UID is that the app or port needs to maintain privileges during the operation, so that it can gather crash information. During the process, it also uses OS access function in Python that's available when the real UID is the same. Therefore, it leaves the effective UID and drops only the real UID. We call this as partially dropping privilege. Later, when writing the crash report to a file, it must be saved with the user permissions of the crashed program. At this time, both effective UID and real UID are finally dropped. We call this as totally dropping privilege. After partially dropping privileges, the app or it collects better data and core dump. After that, the app or it performs totally dropping privileges and then writes out the gathering data to the file in barcrash directory. The core functions of the Hoopsie are shown as follows. First, Hoopsie needs to detect events in the barcrash directory and it needs to detect changes in network connectivity. In addition, because the crash file needs to be transmitted periodically to live an event loop which is framed for the convenience it's used. Second, the data composed of key value pairs in the crash file is converted into an immediate data structure. And this is finally encoded to the binary JSON format. At this time, UTF-8 verification is also being performed for effective binary JSON coding. For example, the library for binary JSON uses the archived MongoDB feed driver that is too old and has not been updated anymore. And thus, some secret issues are found in this code snippet. Finally, we use libcurl and it, the Hoopsie uses libcurl to send data to the daisy server with SSL verified peer option. Thus, it may cannot upload the crash report to different URL than the daisy server. Next, I'd like to share the secret issues, several secret issues I found while looking at the operation process of the airport and Hoopsie. There are four security tricks. First, the sticky bit is set in the barcrash directory. In the directory, there are crash data with that crash file extension and that upload bar extension to trigger Hoopsie and that lap file extension to mutually operate the report. A attacker can easily access the directory barcrash directory and these files can be specially crafted or manipulated to perform a malicious attack. Second, attackers can easily trigger Hoopsie and a port at any time. A port can be called when attackers create a dummy process and send a signal that results in quantum action such as set fault. Hoopsie can be activated by creating an upload file in barcrash as above. Third, separately dropping privileges can cause time attacks by attackers. Finally, a port leads user-defined configuration files with root privileges. The following security issues were all found based on previous tricks. There are three types of issues. The first is it can prevent core dumping by disabling the airport operation. Next, it can prevent the unloading of generated reports to the server. Last, it can dump the pressure port of a previous learning process so that it can be read by the general user. We will look at these issues in detail. There are three ways to prevent core dumping. First is the way to use the word writable lock file. As mentioned earlier, lock is used as a way to make a port to work mutually. The path of the lock file is located in the barcrash directory. If attackers acquire the lock in advance and do not miss it, core dumping can be prevented. The second is the way to send a six-stop signal to the airport. A user cannot send a six-stop signal to a privileged process, but this is possible if the process has been set real UID to users want. As explained earlier, while performing partially dropping privileges for OS access function in Python, it uses the real UID as a lawyer to the same level as the user. At this time, attackers can send a six-stop signal to the airport. Since the process acquires the lock first, sending a six-stop result in disabling core dump. Third, it is a way to prevent core dumping by generating an unhandled exception. Before writing the information dumped in a port to the file, check the contents specified in the apport.ignore.examl file. At this time, if a file type not defined in apport.ignore.examl file is used. Unhandled exception occurs because exceptions are not handled. This process also disables core dumping. Next is the way to prevent HoopSea from sending crash reports to the server. There are two methods to do this. G-HashTable is used as intermediate data structure. When using G-HashTable insert function in G-HashTable library, there is no account measure for collision. When a collision occurs, the current value is replaced with the new one, and the old value remains in memory. To solve this, we need to provide the value distree function when creating a G-HashTable. But HoopSea didn't do that. If the attacker repeated crash keyword pairs with the same key in the crash report, memory inversion occurs. In the following method, a special crafted crash report can trigger an integer overflow and it leads to a heap overflow. The method for triggering integer overflow must satisfy the following conditions. In key value pairs, the length of the value must be greater than 0 and is less than 1KB. The reason the value is less than 1KB is that uploading is possible only when the key value is less than 1KB. If it does not exist in the file list. The length of the key must be greater than the sum of the lengths of the value and 7 in U into 32 max value. Here, 7 is the size inserted for padding as in memory. When tried to try to try to unload the crash report configured in this way, the integer overflow occurs and additional memory needs to be allocated but it cannot. At this time, when the data is memory copied in a small memory area, a heap overflow occurs and HoopSea will be dead by itself. When memory is overturned, the function of all function pointer existing in G main context of GLIP is also overturned but the structure of the memory allocator is already been damaged and making further explosion difficult. Finally, the information related issues. I would like to introduce an issue that causes information leakage by pausing the execution of a port and changing the target of the crash report to be generated. As the crash report generation target is changed from the original program is queued with the user permissions to approve through a privileged process. The reporter of the privileged process can be generated with the general user permissions. The attack plan is as follows. First, the attacker creates an original process and sends a SEG4 signal to it. Since SEG4 contains an action, SEG4 signal contains an action that creates a quarter. The report activated immediately so that the report is activated immediately. After that, it executes the operation of the report and pauses it immediately. Since the PID of the target process to generate the crash report must be the same, that of the original process that has been that. The dummy process is created and killed repeatedly. PID increases monetically and when it exceeds the maximum value PID makes value it newly starts in 300. The repetition is going on until just before the PID of the original process. Next, start or restart the target process. Finally, if you continue the effort, attacker continue the effort that has been paused before a crash report for the target process is generated in the bar crash directory. In the first step, a new way to run a port and post it right away is sent on SEG4's tab signal right after the dropping privilege described earlier. Finally, just before the dropping privilege, it reads prop PID status file to get the UID of the target process. Attackers can use tools such as Inotify to detect changes to the status file. After the above file event, a port can be paused by sending a SEG4's tab signal. In the second step, in order to make the PID of the original process and the PID of the target process the same, the dummy process is created and killed repeatedly until just before showing the same PID. However, it is difficult to match the PID of the target process to the original process exactly because someone can be crafted during the system operation. To solve this, we propose the concept of PID pull. It contains a number of PID of the original process. It increases the chance of showing the same PID between original process and target one. To make a PID pull, we should spawn multiple ports. But as mentioned earlier, spawning multiple ports is prohibited by checked lock function when the port starts up. Fortunately, we can achieve using a previous issue about WorldWriteableLockFile. First, we make a lock file in var crash and activate the port and tab the port. After that, we can remove that lock file in var crash directory. These tabs can spawn multiple ports. Then the repetition is performed until the result is nearly approaching the original one instead just before the same PID comes up. After that, when starting or restarting the target process, it succeeds if the same PID exists in the PID pull. Here, we assume the target process as HoopSea because HoopSea is a privileged process and we can start at any time due to the previous vulnerability. Finally, if the same PID is spawned in the PID pull and the sig continue signal is transmitted to the upward, a report on the running target process is created with the user permissions. Let's check the video. This is POC script. You can see the var crash directory is empty. And you see it is started. You can see the PID pull. There are five items in the PID pull currently a spawning dummy process. Yeah, maybe dummy process is our spawn. And then make a fake crash file, a var crash to kill the HoopSea process, HoopSea demo. The fake crash file is loading to the HoopSea demo. As you can see, HoopSea has been killed. Successfully exploit. Last time, 173 seconds. And let's check the crash report. You can see the HoopSea. HoopSea's crash report. This is metadata. And this is memory map of HoopSea demo. This is query done. Yeah, that's it. This is conclusive. Crash report terms are more popular than popular. But it helps it have some security challenges. As you can see the disabled quarrel dumping or unloading for everyone and read a part of crash dump of previous line courses. In May, we just in dose of tag and information is quoted tag. So we should pay more attention to audit existing design and implementation of the crash reports. Thank you.