We created detailed profiles of the energy consumed by common operations done on Java List, Map, and Set abstractions. The results show that the alternative data types for these abstractions differ significantly in terms of energy consumption depending on the operations. For example, an ArrayList consumes less energy than a LinkedList if items are inserted at the middle or at the end, but consumes more energy than a LinkedList if items are inserted at the start of the list. To explain the results, we explored the memory usage and the bytecode executed during an operation. Expensive computation tasks in the analyzed bytecode traces appeared to have an energy impact, but memory usage did not contribute. We evaluated our profiles by using them to selectively replace Collections types used in six applications and libraries. We found that choosing the wrong Collections type, as indicated by our profiles, can cost even 300% more energy than the most efficient choice. Our work shows that the usage context of a data structure and our measured energy profiles can be used to decide between alternative Collections implementations.

We performed an empirical study to understand interoperability issues in C and Fortran programs. C/Fortran interoperability is very common and is representative of general language interoperability issues, such as how interfaces between languages are defined and how data types are shared. Fortran presents an additional challenge, since several ad hoc approaches to C/Fortran interoperability were in use long before a standard mechanism was defined. We explored 20 applications, automatically analyzing over 12 million lines of code. We found that only 3% of interoperability instances follow the ISO standard to describe interfaces; the rest follow a combination of compiler-dependent ad hoc approaches. Several parameters in cross-language functions did not have standards-compliant interoperable types, and about one-fourth of the parameters that were passed by reference could be passed by value. We propose that automated refactoring tools may provide a viable way to migrate programs to use the new interoperability features. We present two refactorings to transform code for this purpose and one refactoring to evolve code thereafter; all of these are instances of multiple language refactorings.

We performed an empirical study to understand how different language features are used by JavaScript developers in practice, with the goal of using this information to assist future extensions of JavaScript. We inspected more than one million unique scripts (over 80 million lines of code) from various sources: JavaScript programs in the wild collected by a spider, (supposedly) better JavaScript programs collected from the top 100 URLs from the Alex a list, JavaScript programs with new language features used in Firefox Add-ons, widely used JavaScript libraries, and Node.js applications. Our corpus is larger and more diversified than those in prior studies. We also performed a study on 45 JavaScript developers to understand the reasons behind some of their language feature choices. Our study shows that there is a wide-spread confusion about newly introduced JavaScript features, a continuing misuse of existing problematic features, and a surprising lack of adoption of object-oriented features. Understanding JavaScript programming practices will assist many stakeholders: tool developers can analyze the requirements of better tools and more responsive IDEs and programmers can learn about the used (and the good) parts of JavaScript.

Fixing C buffer overflows at source code level remains a manual activity, at best semi-automated. We present an automated approach to fix buffer overflows by describing two program transformations that automatically introduce two well-known security solutions to C source code. The transformations embrace the difficulties of correctly analyzing and modifying C source code considering pointers and aliasing. They are effective: they fixed all buffer overflows featured in 4,505 programs of NIST's SAMATE reference dataset, making the changes automatically on over 2.3 million lines of code (MLOC). They are also safe: we applied them to make hundreds of changes on four open source programs (1.7 MLOC) without breaking the programs. Automated transformations such as these can be used by developers during coding, and by maintainers to fix problems in legacy code. They can be applied on a case by case basis, or as a batch to fix the root causes behind buffer overflows, thereby improving the dependability of systems.

Context: Reporters of security vulnerabilities possess rich information about the security engineering process. Goal: We performed an empirical study on reporters of buffer overflow vulnerabilities to understand the methods and tools used during the discovery. Method: We ran the study in the form of an email questionnaire with open ended questions. The participants were reporters featured in the SecurityFocus repository during two six-month periods; we collected 58 responses. Results: We found that in spite of many apparent choices, reporters follow similar approaches. Most reporters typically use fuzzing, but their fuzzing tools are created ad hoc; they use a few debugging tools to analyze the crash introduced by a fuzzer; and static analysis tools are rarely used. We also found a serious problem in the vulnerability reporting process. Most reporters, especially the experienced ones, favor full-disclosure and do not collaborate with the vendors of vulnerable software. They think that the public disclosure, sometimes supported by a detailed exploit, will put pressure on vendors to fix the vulnerabilities. But, in practice, the vulnerabilities not reported to vendors are less likely to be fixed. Conclusions: The results are valuable for beginners exploring how to detect and report buffer overflows and for tool vendors and researchers exploring how to automate and fix the process.

To focus the efforts of security experts, the goals of this empirical study are to analyze which security vulnerabilities can be discovered by code review, identify characteristics of vulnerable code changes, and identify characteristics of developers likely to introduce vulnerabilities. Using a three-stage manual and automated process, we analyzed 267,046 code review requests from 10 open source projects and identified 413 Vulnerable Code Changes (VCC). Some key results include: (1) code review can identify common types of vulnerabilities; (2) while more experienced contributors authored the majority of the VCCs, the less experienced contributors' changes were 1.8 to 24 times more likely to be vulnerable; (3) the likelihood of a vulnerability increases with the number of lines changed, and (4) modified files are more likely to contain vulnerabilities than new files. Knowing which code changes are more prone to contain vulnerabilities may allow a security expert to concentrate on a smaller subset of submitted code changes. Moreover, we recommend that projects should: (a) create or adapt secure coding guidelines, (b) create a dedicated security review team, (c) ensure detailed comments during review to help knowledge dissemination, and (d) encourage developers to make small, incremental changes rather than large changes.

This paper establishes the concept of "preprocessor dependences" as a foundation for building automated refactoring tools that transform source code containing lexical macros and conditional compilation directives, such as those provided by the C preprocessor. We define a preprocessor dependence graph (PPDG) that models the relationships among macro definitions, macro invocations, and conditional compilation directives in a file--the relationships that must be maintained for the semantics of the C preprocessor to be preserved. For many refactorings, a tool can construct a PPDG from the code before and after it is transformed, then perform a linear-time comparison of the two graphs to determine whether the refactoring will operate correctly in the presence of macros and conditional compilation directives. The proposed technique was implemented in OpenRefactory/C and tested by applying refactorings to GNU Coreutils version 8.21. Empirical results indicate that the technique is effective; it successfully handled refactoring scenarios in which Eclipse CDT, Visual Assist X, and XRefactory all refactored code incorrectly.

C makes it easy to misuse integer types; even mature programs harbor many badly-written integer code. Traditional approaches at best detect these problems; they cannot guide developers to write correct code. We describe three program transformations that fix integer problems - one explicitly introduces casts to disambiguate type mismatch, another adds runtime checks to arithmetic operations, and the third one changes the type of a wrongly-declared integer. Together, these transformations fixed all variants of integer problems featured in 7,147 programs of NIST's SAMATE reference dataset, making the changes automatically on over 15 million lines of code. We also applied the transformations automatically on 5 open source software. The transformations made hundreds of changes on over 700,000 lines of code, but did not break the programs. Being integrated with source code and development process, these program transformations can fix integer problems, along with developers' misconceptions about integer usage.

Many bugs, even those that are known and documented in bug reports, remain in mature software for a long time due to the lack of the development resources to fix them. We propose a general approach, R2Fix, to automatically generate bug-fixing patches from free-form bug reports. R2Fix combines past fix patterns, machine learning techniques, and semantic patch generation techniques to fix bugs automatically. We evaluate R2Fix on three projects, i.e., the Linux kernel, Mozilla, and Apache, for three important types of bugs: buffer overflows, null pointer bugs, and memory leaks. R2Fix generates 57 patches correctly, 5 of which are new patches for bugs that have not been fixed by developers yet. We reported all 5 new patches to the developers; 4 have already been accepted and committed to the code repositories. The 57 correct patches generated by R2Fix could have shortened and saved up to an average of 63 days of bug diagnosis and patch generation time.

SUMMARY A privacy enhancing technology (PET) is an application or a mechanism that allows users to protect the privacy of their personally identifiable information. Early PETs were about enabling anonymous mailing and anonymous browsing, but lately, there have been active research and development efforts in many other problem domains. This paper describes the first pattern language for developing PETs. Currently, it contains 12 patterns. These privacy patterns are not limited to a specific problem domain; they can be applied to design anonymity systems for various types of online communication, online data sharing, location monitoring, voting, and electronic cash management. The pattern language guides a developer when he or she is designing a PET for an existing problem or innovating a solution for a new problem. Copyright © 2011 John Wiley & Sons, Ltd.

Software patterns have been used to guide developers and to disseminate expert knowledge. But patterns can also be thought of as program transformations. Security patterns are architectural. Therefore, program transformations derived from those patterns transform architecture. This paper describes how we used a catalog of security patterns to produce a catalog of security-oriented program transformations. These transformations can be used to make architectural changes that make systems more secure. This paper is a first example of applying patterns to actively transform architectures.

Fred Brooks' retelling of the biblical story of the Tower of Babel offers many insights into what makes building software difficult. The difficulty, according to common interpretations, comes from the communication and organizational problems in software development. But the story contains one more important lesson that people tend to miss: one cannot accomplish impossible goals, which programmers are often asked to do. Software engineering, as a discipline, can overcome poor communication; but as long as we attempt to live up to impossible expectations, we will always fail.

Abstract As the Internet matured, security became more important and formerly adequate designs became inadequate. One of the victims of the increased need for security wassendmail. This paper shows how its competitors improved on its design in response to the increased need for security. The designers ofqmailandPostfixused well‐known patterns to achieve better security without affecting performance; these patterns can be used by the designers of other systems with an increased need for security. Copyright © 2008 John Wiley & Sons, Ltd.

Design patterns capture software solutions to specific problems that have evolved over time and reflect many iterations of work. Documenting such patterns promotes proven design and software reuse. There has been a growing amount of work documenting design patterns for security, however, little work specific to VoIP security. In 2005 NIST released a report on recommendations and best practices for securing VoIP, however it lacks the structure, terminology, and ease-of-understanding needed for both technical and non-technical audiences that is an inherent feature of design patterns. In this paper, we document three design patterns for VoIP implementations related to specific security problems: (1) secure traversal of firewalls and NATs; (2) detecting and mitigating DDoS attacks; and (3) securing against eavesdropping. With many VoIP vendors rushing products to market with overlapping functionality and requirements for interoperability, documenting design patterns is poised to become an important part of secure programming processes for VoIP