How MASC Mutation Operators Bridge Security Gaps in Crypto-API Usage

cover
5 Jun 2024

Authors:

(1) Amit Seal Ami, Computer Science Department, William & Mary Williamsburg, Virginia, USA, and this author contributed equally to this paper ([email protected]);

(2) Syed Yusuf Ahmed, Institute for Information Technology, University of Dhaka Dhaka, Bangladesh, and this author contributed equally to this paper ([email protected]);

(3) Radowan Mahmud Redoy, Institute for Information Technology, University of Dhaka Dhaka, Bangladesh, and this author contributed equally to this paper ([email protected]);

(4) Nathan Cooper, Computer Science Department, William & Mary Williamsburg, Virginia, USA ([email protected]);

(5) Kaushal Kafle, Computer Science Department, William & Mary Williamsburg, Virginia, USA ([email protected]);

(6) Kevin Moran, Department of Computer Science, University of Central Florida Orlando, Florida, USA ([email protected]);

(7) Denys Poshyvanyk, Computer Science Department, William & Mary Williamsburg, Virginia, USA ([email protected]);

(8) Adwait Nadkarni, Computer Science Department, William & Mary Williamsburg, Virginia, USA ([email protected]).

Abstract and 1 Introduction

2 Overview of MASC

3 Design Goals

4 Implementation of MASC

4.1 Mutation Operators

4.2 Mutation Scopes

5 Using MASC

6 Future Work and Conclusion, Acknowledgments, and References

4.1 Mutation Operators

We designed generalizable mutation operators by examining the Java Cryptographic Architecture (JCA) documentation. We identified two common patterns of crypto-API invocation as follows: (𝑖) restrictive, where a developer is expected to only instantiate certain crypto-API objects by providing values from a pre-defined set, e.g., Cipher, and (𝑖𝑖) flexible, where the developers implement the behavior, e.g.,HostnameVerifier. While defining mutation operators of these two distinct patterns, we assumed a threat model consisting of the following types of adversaries:

Benign developer, accidental misuse (T1): A benign developer who accidentally misuses crypto-API, but attempts to address such vulnerabilities using a crypto-detector.

Listing 3: Flexible crypto-API based misuse mutation by MASC

Listing 4: Running MASC CLI with a configuration file

Benign developer, harmful fix (T2): A benign developer who is trying to address a vulnerability identified by a crypto-detector in good faith, but ends up introducing a new vulnerability instead.

Evasive developer, harmful fix (T3): A developer who aims to finish a task as quickly or with low effort (e.g., a contractor), and is hence attempting to purposefully evade a crypto-detector.

The restrictive operators mutate the restrictive values that abstracts away the crypto-API misuse. For example, the abstraction can be based on method chaining, changing letter case (JCA is case insensitive), and introducing alias variables, as shown in Listing 1. We implemented 6 mutation operators for restrictive crypto-APIs. Similarly, for the flexible APIs, we implemented mutation operators based on object-oriented programming concepts:

• Method overriding is used to create mutations that contain ineffective security exception statements, irrelevant loops, and/or ineffective security sensitive return value,

• Class extension is used for implementing or inheriting parent crypto-API interface or abstract classes respectively, and

• Object Instantiation is for creating anonymous inner class object from the implemented or inherited classes of crypto-APIs.

We created 6 more conceptual mutation operators based on flexible crypto-APIs. An example of flexible mutant is shown in Listing 3.

This paper is available on arxiv under CC BY-NC-SA 4.0 DEED license.