Memory safety is traditionally characterized in terms of bad things that cannot happen. This approach is currently embraced in the literature on formal methods for memory safety. However, a general semantic principle for memory safety, that implies the negative items, remains elusive. This paper focuses on the allocator-specific aspects of memory safety, such as null-pointer dereference, use after free, double free, and heap overflow. To that extent, we propose a notion of gradual allocator independence that accurately captures the allocator-dependent aspects of memory safety. Our approach is inspired by the previously suggested connection between memory safety and noninterference, but extends that connection in a fundamentally important direction towards downgrading. We consider a low-level language with access to an allocator that provides malloc and free primitives in a flat memory model. Pointers are just integers, and as such it is trivial to write memory-unsafe programs. The basic intuition of gradual allocator independence is that of noninterference, namely that allocators must not influence program execution. This intuition is refined in two important ways that account for the allocators running out-of-memory and for programs to have pointer-to-integer casts. The key insight of the definition is to treat these extensions as forms of downgrading and give them satisfactory technical treatment using the state-of-the-art information flow machinery.

Network traffic that is not preceded by any Domain Name System (DNS) resolutions is referred to as unnamed traffic. Any DNS-based security system is ineffective against malicious content distributed through this traffic. In this paper, we introduce a novel method for identifying unnamed traffic based on the correlation of flows and DNS responses extracted from raw network traces. We describe two challenges that affect the validity of our method, and how to handle them. By applying our method to a one-week trace of network traffic, we illustrate that unnamed traffic is ubiquitous in a university network across nearly all client systems, destination IP addresses, and destination services. We conclude by presenting several open problems that prevent us from blocking unnamed traffic for security reasons.

Whilst participatory practice is increasingly adopted in end user studies, there has been far less use of a participatory approach when designing lower down the software stack. As a result, end users are often presented with security controls over which they have no control but for which they retain the responsibility. Conversely, hardware and software engineers struggle to innovate new security control designs that are resilient to new and emerging threats. In a study utilising ethnographic research and stakeholder interviews, we show that there is a siloing of communities of practice between hardware security engineers, software engineers and coders, manufacturers in the technology supply chain and end users. Our findings indicate that this siloing and a lack of participatory practice impedes the development of a more cohesive digital security design that integrates security through the stack from the hardware layer upwards to the OS and application layers. These barriers make difficult the negotiation between what is possible lower down the stack with what is needed and wanted higher up the stack. Our findings suggest that a more holistic and comprehensive participatory design approach is required to negotiate a digital security by design paradigm that more evenly distributes power over and responsibility for security controls throughout the stack. Working with the HCI literature on co-production in design, this paper will suggest that a pathway for breaking through this impasse is to utilise objects in the design process of the hardware secure instruction set architecture as a feedback mechanism to incorporate other sets of designers and users in the design process to create a more workable stack.

This paper investigates the potential of using digital certificates for the detection of phishing domains. This i motivated by phishing domains that have started to abuse the (erroneous) trust of the public in browser padloc symbols, and by the large-scale adoption of the Certificate Transparency (CT) framework. This publicl accessible evidence trail of Transport Layer Security (TLS) certificates has made the TLS landscape mor transparent than ever. By comparing samples of phishing, popular benign, and non-popular benign domains we provide insight into the TLS certificates issuance behavior for phishing domains, focusing on the selectio of the certificate authority, the validation level of the certificates, and the phenomenon of certificate sharin among phishing domains. Our results show that phishing domains gravitate to a relatively small selection o certificate authorities, and disproportionally to cPanel, and tend to rely on certificates with a low, and cheap validation level. Additionally, we demonstrate that the vast majority of certificates issued for phishing domain cover more than only phishing domains. These results suggest that a more pro-active role of CAs and puttin more emphasis on certificate revocation can have a crucial impact in the defense against phishing attacks.

Education of IT security can include a tedious and frustrating experience for novice students and organizers. We have sought out to create an education platform that improves upon this experience, through automation, and individualized learning labs. These learning labs hosts are isolated clusters of virtual computer instances, representing real and insecure computer networks. The platform, named Haaukins, improves upon typical accessibility issues of students and cumbersome configuration management for organizers. In order make the platform accessible for other organizations, it has been open sourced.

Summary This paper presents the motivation for and outcomes of an engineering research project on certifiable Java for embedded systems. The project supports the upcoming standard for safety‐critical Java, which defines a subset of Java and libraries aiming for development of high criticality systems. The outcome of this project include prototype safety‐critical Java implementations, a time‐predictable Java processor, analysis tools for memory safety, and example applications to explore the usability of safety‐critical Java for this application area. The text summarizes developments and key contributions and concludes with the lessons learned. Copyright © 2016 John Wiley & Sons, Ltd.

Software Defined Radio (SDR) devices are becoming increasingly popular due to their support for mode-, standard- and application-flexibility. At the same time however, the energy consumption of such devices typically suffers from the use of reconfigurable real-time platforms which are known to be severely power hungry. In this work we therefore show how to use tools and techniques developed by the formal methods community to minimize the energy consumption of Finite Impulse Response (FIR) filters which are extensively used in SDR front-ends. We conduct experiments with four different FIR filter structures where we initially derive data flow graphs and precedence graphs using the Synchronous Data Flow (SDF) notation. Based on actual measurements on the Altera Cyclone IV FPGA, we derive power and timing estimates for addition and multiplication, including idling power consumption. We next model the FIR structures in UPPAAL CORA and employ model checking to find energy-optimal solutions in linearly priced timed automata. In conclusion we state that there are significant energy-versus-time differences between the four structures when we experiment with varying numbers of adders and multipliers. Similarly, we find that idle power becomes an important parameter when a high number of functional units are allocated.

SUMMARY Bug‐finding tools rely on specifications of what is correct or incorrect code. As it is difficult for a tool developer or user to anticipate all possible specifications, strategies for inferring specifications have been proposed. These strategies obtain probable specifications by observing common characteristics of code or execution traces, typically focusing on sequences of function calls. To counter the observed high rate of false positives, heuristics have been proposed for ranking or pruning the results. These heuristics, however, can result in false negatives, especially for rarely used functions. In this paper, we propose an alternate approach to specification inference, in which the user guides the inference process using patterns of code that reflect the user's understanding of the conventions and design of the targeted software project. We focus on specifications describing the correct usage of API functions, which we refer to as API protocols. Our approach builds on the Coccinelle program matching and transformation tool, which allows a user to construct patterns that reflect the structure of the code to be matched. We evaluate our approach on the source code of the Linux kernel, which defines a very large number of API functions with varying properties. Linux is also critical software, implying that fixing even bugs involving rarely used protocols is essential. In our experiments, we use our approach to find over 3000 potential API protocols, with an estimated false positive rate of under 15% and use these protocols to find over 360 bugs in the use of API functions. Copyright © 2012 John Wiley & Sons, Ltd.

Just like other software, Java profiles benefits from refactoring when they have been used and have evolved for some time. This paper presents a refactoring of the Real-Time Specification for Java (RTSJ) and the Safety Critical Java (SCJ) profile (JSR-302). It highlights core concepts and makes it a suitable foundation for the proposed levels of SCJ. The ongoing work of specifying the SCJ profile builds on sub classing of RTSJ. This spurred our interest in a refactoring approach. It starts by extracting the common kernel of the specifications in a core package, which defines interfaces only. It is then possible to refactor SCJ with its three levels and RTSJ in such a way that each profile is in a separate package. This refactoring results in cleaner class hierarchies with no superfluous methods, well defined SCJ levels, elimination of SCJ annotations like @SCJAllowed, thus making the profiles easier to comprehend and use for application developers and students.

Eliminating OS bugs is essential to ensuring the reliability of infrastructures ranging from embedded systems to servers. Several tools based on static analysis have been proposed for finding bugs in OS code. They have, however, emphasized scalability over usability, making it difficult to focus the tools on specific kinds of bugs and to relate the results to patterns in the source code. We propose a declarative approach to bug finding in Linux OS code using a control-flow based program search engine. Our approach is WYSIWIB (What You See Is Where It Bugs), since the programmer expresses specifications for bug finding using a syntax close to that of ordinary C code. The key advantage of our approach is that search specifications can be easily tailored, to eliminate false positives or catch more bugs. We present three case studies that have allowed us to find hundreds of potential bugs.

Networked communication systems and the data they make available have, over the last decades, made their way to the very core of both society and business. Not only do they support everyday life and day-to-day operations, in many cases they enable them in the first place, and often are among the most valuable assets. The flexibility that makes them so valuable in the first place, is also their primary vulnerability: via the network, an entity's data is accessible from almost everywhere, often without the need of physical presence in the entity's perimeter. In this work we propose a new security paradigm, that aims at using the network's flexibility to move data and applications away from potential attackers. We also present a possible realization of the proposed paradigm, based on recent advances in language-based security and static analysis, where data and applications are partitioned ahead-of-time and can be moved automatically based on activity both in the network as well as the real world.

Reasoning about program control-flow paths is an important functionality of a number of recent program matching languages and associated searching and transformation tools. Temporal logic provides a well-defined means of expressing properties of control-flow paths in programs, and indeed an extension of the temporal logic CTL has been applied to the problem of specifying and verifying the transformations commonly performed by optimizing compilers. Nevertheless, in developing the Coccinelle program transformation tool for performing Linux collateral evolutions in systems code, we have found that existing variants of CTL do not adequately support rules that transform subterms other than the ones matching an entire formula. Being able to transform any of the subterms of a matched term seems essential in the domain targeted by Coccinelle.

Policy conformance is a security property gaining importance due to commercial interest like Digital Rights Management. It is well known that static analysis can be used to validate a number of more classical security policies, such as discretionary and mandatory access control policies, as well as communication protocols using symmetric and asymmetric cryptography. In this work we show how to develop a Flow Logic for validating the conformance of client software with respect to a licence conformance policy. Our approach is sufficiently flexible that it extends to fully open systems that can admit new services on the fly.

The internal libraries of Linux are evolving rapidly, to address new requirements and improve performance. These evolutions, however, entail a massive problem of collateral evolution in Linux device drivers: for every change that affects an API, all dependent drivers must be updated accordingly. Manually performing such collateral evolutions is time-consuming and unreliable, and has lead to errors when modifications have not been done consistently.

The rapid detection and treatment of bugs in operating systems code is essential to maintain the overall security and dependability of a computing system. A number of techniques have been proposed for detecting bugs, but little has been done to help developers analyze and treat them. In this paper we propose to combine bug-finding rules with transformations that automatically introduce bug-fixes or workarounds when a possible bug is detected. This work builds on our previous work on the Coccinelle tool, which targets device driver evolution.

The /spl mu/Klaim calculus is a process algebra designed to study the programming of distributed systems consisting of a number of locations each having their own tuple space and collection of mobile processes. Previous work has explored how to incorporate a notion of capabilities to be enforced dynamically by means of a reference monitor. Our first contribution is to describe a sandboxing semantics for the remote evaluation of mobile code; we then develop a succinct flow logic for statically guaranteeing the properties enforced by the reference monitor and hence for dispensing with the overhead of a dynamic reference monitor. Our second contribution is an extension of the calculus to interact with an environment; processes enter the system from the environment and we develop an entry-condition that is sufficient for ensuring that the resulting system continues to guarantee the properties that would otherwise need to be dynamically enforced by the reference monitor. We call the resulting calculus myKlaim.

Developing and maintaining drivers is known to be one of the major challenges in creating a general-purpose, practically-useful operating system [1, 3]. In the case of Linux, device drivers make up, by far, the largest part of the kernel source code, and many more drivers are available outside the standard kernel source tree. New drivers are needed all the time, to give access to the latest devices. To ease driver development, Linux provides a set of driver support libraries, each devoted to a particular bus or device type. These libraries encapsulate much of the complexity of interacting with the device and the Linux kernel, and impose a uniform structure on device-specific code within a given bus or device type.