Python Crypto Misuses in the Wild

Wickert, Anna-Katharina; Baumgärtner, Lars; Breitfelder, Florian; Mezini, Mira

doi:10.1145/3475716.3484195

Cited by 13 publications

(8 citation statements)

References 12 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Although static analysis is not expected to be perfect, our results suggest that false alarms in detecting cryptographic misuse can occur not only due to classic challenges, but also because of ① overly conservative misuse rules, ② imprecise modeling, and ③ implementation bugs in detectors themselves. The false alarm patterns due to ① likely also apply to other papers (e.g., [4], [6], [7], [9]) and industrial tools not considered by this work, as they share similar misuse rules.…”

Section: Introductionmentioning

confidence: 76%

“…On the problem of cryptographic API misuse, a recent work used mutators to investigate the problem of false negatives [8]. Concerning false positives, the most relevant works include the manual investigation [26] done on the alarms from CogniCrypt SAST , as well a small-scale user study presented in [27], where developers reportedly rejected some of the pull requests, citing acceptable usage in nonsecurity-critical context. Comparing to these prior work, this paper presents an in-depth technical investigation that covers more detectors, reveals more false alarm patterns, and provides more concrete improvement directions.…”

Section: Related Workmentioning

confidence: 99%

“…In an attempt to gauge the scale of rule 5-1 false alarms, we modified CryptoGuard to output different alarms for checkClientTrusted() and checkServerTrusted(). During this exercise, we found another implementation bug 6 that makes the checkServerTrusted() method never getting checked. Because CryptoGuard uses a Map to hold the slicing criteria, the rule 5-2 criteria actually overwrites that of rule 5-1 due to a duplicate key, thus the exception check for checkServerTrusted() never happens.…”

Section: Id #5mentioning

confidence: 99%

“…Rule 5-3's model requires the getAcceptedIssuers() method of a custom X509TrustManager implementation to call and return the getAcceptedIssuers() method of a built-in instance of X509TrustManager. However, this captures neither a sufficient nor a necessary condition of the target vulnerability (i.e., accepting all certificates): Case 1: even if the custom getAcceptedIssuers() method returns null or returns an empty array, the custom checkServerTrusted() method, which actually determines the trustworthiness of the server certificate, can 6 https://github.com/CryptoGuardOSS/cryptoguard/blob/92551eeb/src/main/java/rule/ CustomTrustManagerFinder.java#L40 still implement proper certificate validation without calling the custom getAcceptedIssuers(), by either (i) loading trusted CA certificates directly from KeyStore, or (ii) pinning specific issuer certificates directly in its code, or (iii) calling methods (e.g., getAcceptedIssuers() or checkServerTrusted()) of a built-in X509TrustManager. Options (i) and (ii) can also be implemented in the custom getAcceptedIssuers(), but would still violate rule 5-3.…”

Section: Id #5mentioning

confidence: 99%

See 3 more Smart Citations

Towards Precise Reporting of Cryptographic Misuses

Chen,

Liu,

et al. 2024

Proceedings 2024 Network and Distributed System Security Symposium

View full text Add to dashboard Cite

In the last decade, a series of papers were published on using static analysis to detect cryptographic API misuse. In each paper, apps are checked against a set of rules to see if violations exist. A common theme among these papers is that rule violations are plentiful, often at the scale of thousands. Interestingly, while much effort went into tackling false negatives, curiously, not much has been said on (1) whether the misuse alarms are indeed correct and meaningful, and ( 2) what can future work improve upon apart from finding more misuses.In this paper, we take a deep dive into the rule violations reported by various academic papers as well as the rules, models and implementations of their detectors, in an attempt to (1) explain the gap between their misuse alarms and actual vulnerabilities, and (2) shed light on possible directions for improving the precision and usability of misuse detectors. Results of our analysis suggest that the small-scale inspections done by previous work had some unfortunate blind-spots, leaving problems in their rules, models, and implementations unnoticed, which in turn led to unnecessary overestimation of misuses (and vulnerabilities). To facilitate future research on the topic, we distill these avoidable false alarms into high-level patterns that capture their root causes, and discuss design, evaluation and reporting strategies that can improve the precision of misuse findings. Furthermore, to demonstrate the generalizability of these false alarm patterns and improvement directions, we also investigate a popular industry detector and a dynamic detector, and discuss how some of the false alarm patterns do and do not apply to them. Our findings suggest that the problem of precisely reporting cryptographic misuses still has much room for future work to improve upon.

show abstract

Section: Introductionmentioning

confidence: 76%

Section: Related Workmentioning

confidence: 99%

Section: Id #5mentioning

confidence: 99%

Section: Id #5mentioning

confidence: 99%

See 2 more Smart Citations

Towards Precise Reporting of Cryptographic Misuses

Chen,

Liu,

et al. 2024

Proceedings 2024 Network and Distributed System Security Symposium

View full text Add to dashboard Cite

show abstract

“…Concretely, through crypto, everyone can securely use online banking, purchase a book from the local book shop from their computer, and share sensitive information with their co-workers while working remotely without the fear that the software leaks their data. Unfortunately, previous research results show that developers struggle with the secure usage of crypto APIs and often add vulnerabilities to their code [21,28,33,50]. Most of these vulnerabilities are caused by developers who use a crypto API in a way that is considered insecure by experts, e.g., choosing an outdated crypto hash algorithm like SHA-1 [28].…”

Section: Introductionmentioning

confidence: 99%

CamBench -- Cryptographic API Misuse Detection Tool Benchmark Suite

Schlichtig¹,

Wickert²,

Krüger³

et al. 2022

Preprint

Self Cite

View full text Add to dashboard Cite

Context: Cryptographic APIs are often misused in real-world applications. To mitigate that, many cryptographic API misuse detection tools have been introduced. However, there exists no established reference benchmark for a fair and comprehensive comparison and evaluation of these tools. While there are benchmarks, they often only address a subset of the domain or were only used to evaluate a subset of existing misuse detection tools. Objective: To fairly compare cryptographic API misuse detection tools and to drive future development in this domain, we will devise such a benchmark. Openness and transparency in the generation process are key factors to fairly generate and establish the needed benchmark. Method: We propose an approach where we derive the benchmark generation methodology from the literature which consists of general best practices in benchmarking and domainspecific benchmark generation. A part of this methodology is transparency and openness of the generation process, which is achieved by pre-registering this work. Based on our methodology we design CamBench, a fair "Cryptographic API Misuse Detection Tool Benchmark Suite". We will implement the first version of Cam-Bench limiting the domain to Java, the JCA, and static analyses. Finally, we will use CamBench to compare current misuse detection tools and compare CamBench to related benchmarks of its domain. CCS CONCEPTS• Software and its engineering → Software libraries and repositories; Software maintenance tools; Software verification and validation; • Security and privacy → Software security engineering.

show abstract