WOOT '20 Workshop Program

Nowadays it's difficult to find any hardware vendor who develops all the components present in their platform. The big piece of it outsourced to OEM's includes firmware too. That creates additional complexity and limits hardware vendor control under the platform. That creates not only supply chain security risks but also produces security gaps in the threat modeling process by design.

In most cases, hardware vendors separate threat model and security boundaries for each hardware component present on the platform but in reality, it misses a lot of details which is directly reflected on platform security. This talk will look through the prism security problems and vulnerabilities created over those architecture design mistakes.

Information leaks are the most prevalent type of vulnerabilities among all known vulnerabilities in Linux kernel. Many of them are caused by the use of uninitialized variables or data structures. It is generally believed that the majority of information leaks in Linux kernel are low-risk and do not have severe impact due to the difficulty (or even the impossibility) of exploitation. As a result, developers and security analysts do not pay enough attention to mitigating these vulnerabilities. Because of this, these vulnerabilities are usually assigned low CVSS scores or without any CVEs assigned. Moreover, many patches that address uninitialized data use bugs in Linux kernel are not accepted, leaving billions of Linux systems vulnerable.

Nonetheless, information leak vulnerabilities in Linux kernel are not as low-risk as people believe. In this paper, we present a generic approach that converts stack-based information leaks in Linux kernel into kernel pointer leak vulnerabilities, which can be used to defeat modern security defenses such as KASLR. Taking an exploit that triggers an information leak in Linux kernel, our approach automatically converts it into a highly impactful exploit that leaks pointers to either kernel functions or the kernel stack.We evaluate our approach on four known CVEs and one security patch in Linux kernel and demonstrate its effectiveness. Our findings provide solid evidence for Linux kernel developers and security analysts to treat information leaks in Linux kernel more seriously.

Enclave platforms like Intel SGX, Sanctum and Keystone promise attractive security guarantees but have not always lived up to their billing, mostly due to side-channel leaks in platform implementations. A particularly important side-channel in these platforms has been the page fault side-channel. This side channel has proven to be particularly problematic because it is deterministic and controllable by a malicious operating system. This paper presents a new attack on the page fault channel that works on the state-of-art proposal for secure demand paging in enclaves (InvisiPage, ISCA'19). The insight behind the attack is that even if the exact page fault addresses are hidden, the adversary may be able to infer the interval between when a page is evicted from an enclave and when it is fetched back into the enclave. Our evaluation shows this leak is sufficient to: (i) identify which application is being executed in an enclave, (ii) infer confidential details about the inputs to the application, and (iii) function as a covert channel between an untrusted enclave application and a malicious operating system.

Near Field Communication (NFC) is being used in a variety of security-critical applications, from access control to payment systems. However, NFC protocol analysis typically requires expensive or conspicuous dedicated hardware, or is severely limited on smartphones. In 2015, the NFCGate proof of concept aimed at solving this issue by providing capabilities for NFC analysis employing off-the-shelf Android smartphones. In this paper, we present an extended and improved NFC toolkit based on the functionally limited original open-source codebase. With in-flight traffic analysis and modification, relay, and replay features this toolkit turns an off-the-shelf smartphone into a powerful NFC research tool. To support the development of countermeasures against relay attacks, we investigate the latency incurred by NFCGate in different configurations. Our newly implemented features and improvements enable the case study of an award-winning, enterprise-level NFC lock from a well-known European lock vendor, which would otherwise require dedicated hardware. The analysis of the lock reveals several security issues, which were disclosed to the vendor.

The last couple of years have brought exciting hardware and software security features in the top operating systems—Windows, macOS, and Linux, which have all moved toward greater integration with hypervisor, TPM, and chipset/CPU security mitigations and capabilities, while taking advantage of the compiler as well. Additionally, security teams embedded in various companies are now involved (or claim to be) in the design, implementation, and testing of such features.

Over a year ago, I presented a number of vulnerabilities in recent Windows code at a keynote in France and later in Israel, vulnerabilities which were of such simplicity that it became unclear why they had not been found through code review, fuzzing, or other tooling (because all developers write bugs). I posited that such tooling is insufficient to build truly secure systems, and that the added complexity, and reduction on the quality of training & education of developers, is leading us toward a world with more bugs, not less.

At the time, arguments were made that these were one-offs, and not all processes meant to find these types of bugs had activated yet. Multiple presentations were made on how new processes were added to fix and address future similar issues, especially when related to system calls. In this keynote, I'll review the state since last year, and show how not only were additional similar bugs added in both Dxgkrnl and Ntoskrnl, as well as how entire new security features continued to have fatal design flaws (leading to over 100K in bug bounty money due to their discovery). While these examples are Windows centric, equivalents exist in the Linux and macOS space, as this is not some sort of unique Microsoft problem.

Programmers are human, and humans make mistakes. Is automation truly the solution, or are there more fundamental changes that are needed for how we address security engineering? This keynote will make one last plea to propose changes to the engineering processes and educational priorities of future software practitioners.

Bluetooth enables basic communication prior to pairing as well as low-energy information exchange with multiple devices. The Apple ecosystem is extensively using Bluetooth for coordination tasks that run in the background and enable seamless device handover. To this end, Apple established proprietary protocols. Since their implementation is closed-source and over-the-air fuzzers are very limited, these protocols are largely unexplored and not publicly tested for security. In this paper, we summarize the current state of Apple's Bluetooth protocols. Based on this, we build the iOS in-process fuzzer ToothPicker and evaluate the implementation security of these protocols. We find a zero-click Remote Code Execution (RCE) that was fixed in iOS 13.5 and simple crashes.

Bluetooth chips must include a Random Number Generator (RNG). This RNG is used internally within cryptographic primitives but also exposed to the operating system for chip-external applications. In general, it is a black box with security-critical authentication and encryption mechanisms depending on it. In this paper, we evaluate the quality of RNGs in various Broadcom and Cypress Bluetooth chips. We find that the RNG implementation significantly changed over the last decade. Moreover, most devices implement an insecure Pseudo-Random Number Generator (PRNG) fallback. Multiple popular devices, such as the Samsung Galaxy S8 and its variants as well as an iPhone, rely on the weak fallback due to missing a Hardware Random Number Generator (HRNG). We statistically evaluate the output of various HRNGs in chips used by hundreds of millions of devices. While the Broadcom and Cypress HRNGs pass advanced tests, it remains indistinguishable for users if a Bluetooth chip implements a secure RNG without an extensive analysis as in this paper. We describe our measurement methods and publish our tools to enable further public testing.

Recent years have seen a surge in the number of data leaks despite aggressive information-containment measures deployed by cloud providers. When attackers acquire sensitive data in a secure cloud environment, covert communication channels are a key tool to exfiltrate the data to the outside world. While the bulk of prior work focused on covert channels within a single CPU, they require the spy (transmitter) and the receiver to share the CPU, which might be difficult to achieve in a cloud environment with hundreds or thousands of machines.

This work presents Bankrupt, a high-rate highly clandestine channel that enables covert communication between the spy and the receiver running on different nodes in an RDMA network. In Bankrupt, the spy communicates with the receiver by issuing RDMA network packets to a private memory region allocated to it on a different machine (an intermediary). The receiver similarly allocates a separate memory region on the same intermediary, also accessed via RDMA. By steering RDMA packets to a specific set of remote memory addresses, the spy causes deep queuing at one memory bank, which is the finest addressable internal unit of main memory. This exposes a timing channel that the receiver can listen on by issuing probe packets to addresses mapped to the same bank but in its own private memory region. Bankrupt channel delivers 74Kb/s throughput in CloudLab's public cloud while remaining undetectable to the existing monitoring capabilities, such as CPU and NIC performance counters.

I'll examine some practical implementations of cryptographic proofs, including zero knowledge proofs for facts such as proper mixing, decryption, and equality testing. In each case, we can generate a 'proof' of a fact that is clearly false. In some cases these are simply bugs; in others, the forgery is possible because of a subtle misalignment of the security assumptions of a prove n-secure component and the context of the protocol.

Examples will include the SwissPost-Scytl-iVote mixing and decryption proofs, plus some new results on Plaintext Equivalence in the Civitas implementation of the Juels-Catalano-Jakobsson e-voting protocol.

Although all my examples come from e-voting, these results justify more careful analysis of other uses of zero knowledge proofs in other practical scenarios, such as blockchains, cryptocurrencies, and online auctions.

This is joint work with Thomas Haines, Sarah Jamie Lewis, Eleanor McMurtry, and Olivier Pereira.