{"title":"CREPE","authors":"Kiavash Satvat, Maliheh Shirvanian, Mahshid Hosseini, Nitesh Saxena","doi":"10.1145/3374664.3375738","DOIUrl":null,"url":null,"abstract":"Software crashes are nearly impossible to avoid. The reported crashes often contain useful information assisting developers in finding the root cause of the crash. However, crash reports may carry sensitive and private information about the users and their systems, which may be used by an attacker who has compromised the crash reporting system to violate the user's privacy and security. Besides, a single bug may trigger loads of identical reports which excessively consumes system resources and overwhelms application developers. In this paper, we introduce CREPE, a security-concerned crash reporting solution, that effectively reduces the number of submitted crash reports to mitigate the security and privacy risk associated with the current implementation of the crash reporting system. Similar to the currently deployed systems, CREPE aggregates and categorizes the crashes based on their root cause. On top of that, the server marks the crash categories in which sufficient reports have been received as \"saturated\" and informs the clients periodically through software updates. On the client, CREPE engages the reporting application in categorizing each crash to only submit reports belonging to non-saturated categories. We evaluate CREPE using one year of data from Mozilla crash reporting system containing 38,834,383 reports of Firefox crashes. Our analysis suggests that we can significantly reduce the number of submitted reports by bucketing 100 most frequent crash signatures at the client. This helps to preserve the security and the privacy of a significant portion of users whose data has not been shared with the server due to the redundancy of their crash data with previously submitted reports.","PeriodicalId":171521,"journal":{"name":"Proceedings of the Tenth ACM Conference on Data and Application Security and Privacy","volume":"196 1","pages":"0"},"PeriodicalIF":0.0000,"publicationDate":"2020-03-16","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":"2","resultStr":null,"platform":"Semanticscholar","paperid":null,"PeriodicalName":"Proceedings of the Tenth ACM Conference on Data and Application Security and Privacy","FirstCategoryId":"1085","ListUrlMain":"https://doi.org/10.1145/3374664.3375738","RegionNum":0,"RegionCategory":null,"ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":null,"EPubDate":"","PubModel":"","JCR":"","JCRName":"","Score":null,"Total":0}
引用次数: 2
Abstract
Software crashes are nearly impossible to avoid. The reported crashes often contain useful information assisting developers in finding the root cause of the crash. However, crash reports may carry sensitive and private information about the users and their systems, which may be used by an attacker who has compromised the crash reporting system to violate the user's privacy and security. Besides, a single bug may trigger loads of identical reports which excessively consumes system resources and overwhelms application developers. In this paper, we introduce CREPE, a security-concerned crash reporting solution, that effectively reduces the number of submitted crash reports to mitigate the security and privacy risk associated with the current implementation of the crash reporting system. Similar to the currently deployed systems, CREPE aggregates and categorizes the crashes based on their root cause. On top of that, the server marks the crash categories in which sufficient reports have been received as "saturated" and informs the clients periodically through software updates. On the client, CREPE engages the reporting application in categorizing each crash to only submit reports belonging to non-saturated categories. We evaluate CREPE using one year of data from Mozilla crash reporting system containing 38,834,383 reports of Firefox crashes. Our analysis suggests that we can significantly reduce the number of submitted reports by bucketing 100 most frequent crash signatures at the client. This helps to preserve the security and the privacy of a significant portion of users whose data has not been shared with the server due to the redundancy of their crash data with previously submitted reports.