Security Code Smells in Android ICC

Android Inter-Component Communication (ICC) is complex, largely unconstrained, and hard for developers to understand. As a consequence, ICC is a common source of security vulnerability in Android apps. To promote secure programming practices, we have reviewed related research, and identified avoidable ICC vulnerabilities in Android-run devices and the security code smells that indicate their presence. We explain the vulnerabilities and their corresponding smells, and we discuss how they can be eliminated or mitigated during development. We present a lightweight static analysis tool on top of Android Lint that analyzes the code under development and provides just-in-time feedback within the IDE about the presence of such smells in the code. Moreover, with the help of this tool we study the prevalence of security code smells in more than 700 open-source apps, and manually inspect around 15% of the apps to assess the extent to which identifying such smells uncovers ICC security vulnerabilities.Comment: Accepted on 28 Nov 2018, Empirical Software Engineering Journal (EMSE), 201

Impact assessment for vulnerabilities in open-source software libraries

Software applications integrate more and more open-source software (OSS) to benefit from code reuse. As a drawback, each vulnerability discovered in bundled OSS potentially affects the application. Upon the disclosure of every new vulnerability, the application vendor has to decide whether it is exploitable in his particular usage context, hence, whether users require an urgent application patch containing a non-vulnerable version of the OSS. Current decision making is mostly based on high-level vulnerability descriptions and expert knowledge, thus, effort intense and error prone. This paper proposes a pragmatic approach to facilitate the impact assessment, describes a proof-of-concept for Java, and examines one example vulnerability as case study. The approach is independent from specific kinds of vulnerabilities or programming languages and can deliver immediate results

Analysis of operating system diversity for intrusion tolerance

One of the key benefits of using intrusion-tolerant systems is the possibility of ensuring correct behavior in the presence of attacks and intrusions. These security gains are directly dependent on the components exhibiting failure diversity. To what extent failure diversity is observed in practical deployment depends on how diverse are the components that constitute the system. In this paper, we present a study with operating system's (OS's) vulnerability data from the NIST National Vulnerability Database (NVD). We have analyzed the vulnerabilities of 11 different OSs over a period of 18 years, to check how many of these vulnerabilities occur in more than one OS. We found this number to be low for several combinations of OSs. Hence, although there are a few caveats on the use of NVD data to support definitive conclusions, our analysis shows that by selecting appropriate OSs, one can preclude (or reduce substantially) common vulnerabilities from occurring in the replicas of the intrusion-tolerant system

Forensically-Sound Analysis of Security Risks of using Local Password Managers

Password managers have been developed to address the human challenges associated with password security, i.e., to solve usability issues in a secure way. They offer, e.g., features to create strong passwords, to manage the increasing number of passwords a typical user has, and to auto-fill passwords, sparing users the hassle of not only remembering but also typing them. Previous studies have focused mainly on the security analysis of cloud-based and browser-based password managers; security of local password managers remains mostly under-explored. This paper takes a forensic approach and reports on a case study of three popular local password managers: KeePass (v2.28), Password Safe (v3.35.1) and RoboForm (v7.9.12). Results revealed that either the master password or the content of the password database could be found unencrypted in Temp folders, Page files or Recycle bin, even after the applications had been closed. Therefore, an attacker or malware with temporary access to the computer on which the password managers were running may be able to steal sensitive information, even though these password managers are meant to keep the databases encrypted and protected at all times

Combining Static and Dynamic Analysis for Vulnerability Detection

In this paper, we present a hybrid approach for buffer overflow detection in C code. The approach makes use of static and dynamic analysis of the application under investigation. The static part consists in calculating taint dependency sequences (TDS) between user controlled inputs and vulnerable statements. This process is akin to program slice of interest to calculate tainted data- and control-flow path which exhibits the dependence between tainted program inputs and vulnerable statements in the code. The dynamic part consists of executing the program along TDSs to trigger the vulnerability by generating suitable inputs. We use genetic algorithm to generate inputs. We propose a fitness function that approximates the program behavior (control flow) based on the frequencies of the statements along TDSs. This runtime aspect makes the approach faster and accurate. We provide experimental results on the Verisec benchmark to validate our approach.Comment: There are 15 pages with 1 figur

The Dilemma of Security Smells and How to Escape It

A single mobile app can now be more complex than entire operating systems ten years ago, thus security becomes a major concern for mobile apps. Unfortunately, previous studies focused rather on particular aspects of mobile application security and did not provide a holistic overview of security issues. Therefore, they could not accurately understand the fundamental flaws to propose effective solutions to common security problems. In order to understand these fundamental flaws, we followed a hybrid strategy, i.e., we collected reported issues from existing work, and we actively identified security-related code patterns that violate best practices in software development. We further introduced the term ``security smell,'' i.e., a security issue that could potentially lead to a vulnerability. As a result, we were able to establish comprehensive security smell catalogues for Android apps and related components, i.e., inter-component communication, web communication, app servers, and HTTP clients. Furthermore, we could identify a dilemma of security smells, because most security smells require unique fixes that increase the code complexity, which in return increases the risk of introducing more security smells. With this knowledge, we investigate the interaction of our security smells with the 192 Mitre CAPEC attack mechanism categories of which the majority could be mitigated with just a few additional security measures. These measures, a String class with behavior and the more thorough use of secure default values and paradigms, would simplify the application logic and at the same time largely increase security if implemented appropriately. We conclude that application security has to focus on the String class, which has not largely changed over the last years, and secure default values and paradigms since they are the smallest common denominator for a strong foundation to build resilient applications. Moreover, we provide an initial implementation for a String class with behavior, however the further exploration remains future work. Finally, the term ``security smell'' is now widely used in academia and eases the communication among security researchers