WAMOS 2018 Fourth Wiesbaden Workshop on Advanced Microkernel Operating Systems

WAMOS 2018 Fourth Wiesbaden Workshop on Advanced Microkernel Operating Systems Editor / Program Chair: Robert Kaiser RheinMain University of Applied Sciences Information Science Unter den Eichen 5 65195 Wiesbaden Germany Technical Report July 2018 Contents Foreword 3 Program Committee 3 Session 1: Hardware-Related Attacks 5 Branchscope and more Dominik Swierzy ......................................... 5 Exploiting Speculative Execution (Spectre) via JavaScript Lucas Noack and Tobias Reichert ................................. 11 Spectre-NG, an avalanche of attacks Marius Sternberger ........................................ 21 Common Attack Vectors of IoT Devices Alexios Karagiozidis ....................................... 27 Session 2: Mitigation 35 Mitigation of actual CPU attacks A hare and hedgehog race not to win Jens Nazarenus .......................................... 35 KPTI a Mitigation Method against Meltdown Lars Mller ............................................. 41 Current state of mitigations for spectre within operating systems Ben Stuart ............................................. 47 Overview of Meltdown and Spectre patches and their impacts Marc Lw .............................................. 53 Attempts towards OS Kernel protection from Code-Injection Attacks Bernhard Grtz ........................................... 63 An overview about Information Flow Control at different categories and levels Danny Ziesche ........................................... 69 Session 3: Cross-Cutting Concerns 75 Detecting Spectre Attacks by identifying Cache Side-Channel Attacks using Machine Learning Philipp Altmeyer and Jonas Depoix ................................ 75 Software based side-channel attacks on CPUs - Their history and how we behaved Harald Heckmann ......................................... 87 Adapting Kerckhoffss principle: CPU Attacks leading a path from cryptography to open-source- hardware Thorsten Knoll .......................................... 93 Program 100 © Copyright 2018 RheinMain University of Applies Sciences (HSRM). All rights reserved. The copyright of this collection is with HSRM. The copyright of the individual articles remains with their authors. Foreword Welcome to HSRM and to WAMOS 2018, the fourth edition of the Wiesbaden Workshop on Advanced Micro- kernel Operating Systems. This workshop series was conceived to provide a forum for students of the technical seminar on advanced operating systems at Wiesbaden University of Applied Sciences to present their work. Besides submitting papers themselves, students also serve as members of the program comittee and are involved in the peer-reviewiewing process. The intention, besides the presentation of interesing operating system papers, is to provide hands-on experience in organizing and running a workshop. The authors were given the opportunity to revise and re-submit ﬁnal versions of their papers based on the reviews. The papers contained herein are the ﬁnal versions submitted just before the workshop. I’d like to thank all participants for their enthusiasm. The Workshop Chair, Robert Kaiser RheinMain University of Applied Sciences Wiesbaden, Germany Program Committee Jens Nazarenus, Wiesbaden University of applied sciences Jonas Depoix, Wiesbaden University of applied sciences Alexios Karagiozidis, Wiesbaden University of applied sciences Ben Stuart, Wiesbaden University of applied sciences Marius Sternberger, Wiesbaden University of applied sciences Thorsten Knoll, Wiesbaden University of applied sciences Danny Ziesche, Wiesbaden University of applied sciences Bernhard Grtz, Wiesbaden University of applied sciences Marc Lw, Wiesbaden University of applied sciences Harald Heckmann, Wiesbaden University of applied sciences Tobias Reichert, Wiesbaden University of applied sciences Lucas Noack, Wiesbaden University of applied sciences Dominik Swierzy, Wiesbaden University of applied sciences Philipp Altmeyer, Wiesbaden University of applied sciences Lars Mller, Wiesbaden University of applied sciences RheinMain University of Applied Sciences, Wiesbaden, Germany 3 Branchscope and more Dominik Swierzy RheinMain University of Applied Sciences [email protected] ACM Reference Format: Text0 Text0 Text0 Text0 Text0 Text0 Texts Texts Texts Texts Texts Textt Textt Textt Textt Textt Textd Textd Textd Textd Textd Text0 Text0 Text0 Text0 Text0 Text1 Text0 Text0 Text0 Text0 Text0 Destination Dominik Swierzy. 2018. Branchscope and more. In Proceedings of WAMOS. Addition Register Addition Register Opcode ACM, New York, NY, USA, 6 pages. Register Abstract Figure 1: Bit presentation of an add instruction. This paper will provide the basic knowledge of how a CPU and further- more a Branch Prediction Unit (BPU) works to later describe how one of the recent offspring of Spectre and Meltdown called Branchscope operates. ... Branchscope is like Spectre targeting the BPU but while Spectre attacks add $d $s $ t the Branch Target Buffer inside of the Branch Predictor Branchscope fo- cuses on the Direction Predictor itself and is thereby one of the first. With beq $s $ t ADDRESS Branchscope it is possible to read secret data from a victim program if the ... secret is used for a directional branch making it a huge vulnerability. If the CPU shall execute this program, it will first be loaded into 1 INTRODUCTION RAM. Although the machine code is still readable by a human in RAM it will be encoded just in bits. Therefore the add Instruction The introduction of Meltdown [1] and Spectre [2] showed huge vul- from the listing could in memory have the representation depicted nerabilities in modern CPU in regards of out of order execution and in figure 1 with a specific address pointing toit. speculatively execution. These side channel attacks are allowing The opcode contains the information which instruction the bits an attacker to read normally protected memory of other programs are representing and therefore how they have to be decoded. Op- or even the kernel which can lead to leakage of cryptographic keys code 100000 is the add instruction therefore the bits 25 to 21 (repre- or personal data. Since these vulnerabilities exist on the hardware sented with ’s’) are decoding the first register, the bits marked with itself and are not software bugs there are no easy fixes. The most t the second register and d the destination register. The unused bits used fix against Meltdown is KAISER [3] but leads to a performance are set to zero and do not have an effect on the operation. drop of up to 30% [4]. The execution of the program follows a pipeline. First a register Another side channel attack which exploits these vulnerabilities which contains the address of the next instruction which has to be is Branchscope [5]. Branchscope was published March 2018 and executed will be read. This register is called program counter or similar to Spectre attacks the Branch Prediction Unit (BPU) of a short PC. This stage of the Execution-Pipeline is called Instruction- CPU. Unlike Spectre and other side channel attacks, Branchscope Fetch (IF). After fetching the instruction has to be decoded, this though attacks the Direction Predictor inside a BPU and not the happens in stage two called instruction decode (ID). In this stage it Branch Target Buffer as usual. Branchscope works from user space will be determined if some registers have to be read or a memory on multiple modern Intel processors and can even be extended to access is necessary. In the above mentioned example the opcode attack Intels Software Guard Extensions. would be decoded as an add-instruction and therefore it would be Outline: First of all it will be explained how modern CPUs known that the values of the two registers s and t have to be read work and especially Branch Prediction Units since these will be and provided for the next stages. In the Execution-Phase (EXE) attacked by Branchscope. After showing the design of BPUs the the actual computation of the instruction will be done, hence s + t general attack procedure will be stated. Afterwards the require- would be calculated. If a memory reference would be needed a ments and assumptions for an successfull attack will be shown. virtual address would be determined in the EXE-Stage. The next Finally mitigation tactics against Branchscope will be shown and a stage is called memory access (MEM) and as long as the instruction short summary. doesn’t need to access memory it will be skipped otherwise the memory will be accessed. The last step in the pipeline is called 2 CPU PIPELINING write back (WB) which writes the result of the instruction into the The following listing shows some example machine code which destination register specified in the instruction. could be part of a bigger software: Every instruction has to go through these steps but through pipelining as soon as one instruction leaves the IF-stage and enters Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed the ID-Stage the next instruction can enter the IF-stage, therefore for profit or commercial advantage and that copies bear this notice and the full citation up to five instructions can be simultaneously processed as seenin on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, figure 2. to post on servers or to redistribute to lists, requires prior specific permission and/or a Unfortunately

Load more