(Submitted on 8 Nov 2018)
Smart home connects tens of home devices into the Internet, running a smart algorithm in the cloud that sends remote commands to the devices. While bringing unprecedented convenience, accessibility, and efficiency, it also introduces safety hazards to users. Prior research studied smart home security from various aspects. However, we found that the complexity of the interactions among the participating entities (device, IoT cloud, and mobile app) has not yet been systematically investigated. In this work, we conducted an in-depth analysis to four widely used smart home solutions. Combining firmware reverse-engineering, network traffic interception, and black-box testing, we distill the general state transitions representing the complex interactions among the three entities. Based on the state machine, we reveal several vulnerabilities that lead to unexpected state transitions. While these minor security flaws appear to be irrelevant, we show that combining them in a surprising way poses serious security or privacy hazards to smart home users. To this end, five concrete attacks are constructed and illustrated. We also discuss the implications of the disclosed attacks in the context of business competition. Finally, we propose some general design suggestions for building a more secure smart home solution.
(Submitted on 11 Oct 2018)
Industrial Control Systems (ICS) are sensible targets for high profile attackers and advanced persistent threats, which are known to exploit USB thumb drives as an effective spreading vector. In ICSes, thumb drives are widely used to transfer files among disconnected systems and represent a serious security risks, since, they may be promiscuously used in both critical and regular systems. The threats come both from malware hidden in files stored in the thumb drives and from BadUSB attacks . BadUSB leverages the modification of firmware of USB devices in order to mimic the behaviour of a keyboard and send malicious commands to the host. We present a solution that allows a promiscuous use of USB thumbs drives while protecting critical machines from malware, that spread by regular file infection or by firmware infection. The main component of the architecture we propose is an hardware, called USBCaptchaIn, intended to be in the middle between a critical machine and all USB devices. We do not require users to change the way they use thumb drives. To avoid human-errors, we do not require users to take any decision. The proposed approach is highly compatible with already deployed products of a ICS environment and proactively blocks malware before they reach their targets. We describe our solution, provide a thorough analysis of the security of our approach in the ICS context, and report the informal feedback of some experts regarding our first prototypes.
(Submitted on 8 Oct 2018)
Intel has introduced a trusted computing technology, Intel Software Guard Extension (SGX), which provides an isolated and secure execution environment called enclave for a user program without trusting any privilege software (e.g., an operating system or a hypervisor) or firmware. Nevertheless, SGX is vulnerable to several side channel attacks (e.g. page-fault-based attack and cache-based attack). In this paper, we explore a new, yet critical side channel attack in SGX, interface-based side channel attack, which can infer the information of the enclave input data. The root cause of the interface-based side channel attack is the input dependent interface invocation information (e.g., interface information and invocation patterns) which can be observed by the untrusted privilege software can reveal the control flow in the enclave. We study the methodology which can be used to conduct the interface-based side channel attack. To illustrate the effectiveness of the interface-based side-channel attacks, we use our methodology to infer whether tracked web pages have been processed by the SGX-assisted NFV platforms and achieve the accuracy of 87.6% and recall of 76.6%. We also identify the packets which belong to the tracked web pages, with the accuracy of 67.9%and recall of 71.1%. We finally propose some countermeasures to defense the interface-based side channel attack in SGX-assisted applications.
This article explores iPXE, an open source network boot firmware that I think BIOS developers should be aware of.[…]
Tools and techniques for traversing treacherous code bases
– or- How I managed to develop understanding of U-Boot
The UEFI Forum has specified the date/location of the next plugfest:
Event Date: April 8-12, 2019
Location: Bellevue, WA
[…]This provides specific guidance for firmware based upon the EFI Developer Kit II (EDKII) and coreboot. Because this document deals with host firmware internal requirements, it is not intended to provide side channel mitigation guidance for general application developers.
Scope: This addresses bare-metal firmware runtime risks and mitigation suggestions for the bounds check bypass, branch target injection, rogue data cache load, rogue system register read, and speculative store bypass side channel methods. Our examples and context are primarily focused on ring 0 firmware runtimes (for example: EFI Developer Kit II, PI SMM, and coreboot SMM). Other firmware execution environments are out of scope.[…]
Graphics Processing Units (GPUs) are commonly integrated with computing devices to enhance the performance and capabilities of graphical workloads. In addition, they are increasingly being integrated in data centers and clouds such that they can be used to accelerate data intensive workloads. Under a number of scenarios the GPU can be shared between multiple applications at a fine granularity allowing a spy application to monitor side channels and attempt to infer the behavior of the victim. For example, OpenGL and WebGL send workloads to the GPU at the granularity of a frame, allowing an attacker to interleave the use of the GPU to measure the side-effects of the victim computation through performance counters or other resource tracking APIs. We demonstrate the vulnerability using two applications. First, we show that an OpenGL based spy can fingerprint websites accurately, track user activities within the website, and even infer the keystroke timings for a password text box with high accuracy. The second application demonstrates how a CUDA spy application can derive the internal parameters of a neural network model being used by another CUDA application, illustrating these threats on the cloud. To counter these attacks, the paper suggests mitigations based on limiting the rate of the calls, or limiting the granularity of the returned information.
Modern processor optimizations such as branch prediction and out-of-order execution are crucial for performance. Recent research on transient execution attacks including Spectre and Meltdown showed, however, that exception or branch misprediction events may leave secret-dependent traces in the CPU’s microarchitectural state. This observation led to a proliferation of new Spectre and Meltdown attack variants and even more ad-hoc defenses (e.g., microcode and software patches). Unfortunately, both the industry and academia are now focusing on finding efficient defenses that mostly address only one specific variant or exploitation methodology. This is highly problematic, as the state-of-the-art provides only limited insight on residual attack surface and the completeness of the proposed defenses.
In this paper, we present a sound and extensible systematization of transient execution attacks. Our systematization uncovers 7 (new) transient execution attacks that have been overlooked and not been investigated so far. This includes 2 new Meltdown variants: Meltdown-PK on Intel, and Meltdown-BR on Intel and AMD. It also includes 5 new Spectre mistraining strategies. We evaluate all 7 attacks in proof-of-concept implementations on 3 major processor vendors (Intel, AMD, ARM). Our systematization does not only yield a complete picture of the attack surface, but also allows a systematic evaluation of defenses. Through this systematic evaluation, we discover that we can still mount transient execution attacks that are supposed to be mitigated by rolled out patches.
Linux subsystem for managing device events
Create a script that triggers your computer to do a specific action when a specific device is plugged in.
13 Nov 2018
Seth Kenlon (Red Hat)
Udev is the Linux subsystem that supplies your computer with device events. In plain English, that means it’s the code that detects when you have things plugged into your computer, like a network card, external hard drives (including USB thumb drives), mouses, keyboards, joysticks and gamepads, DVD-ROM drives, and so on. That makes it a potentially useful utility, and it’s well-enough exposed that a standard user can manually script it to do things like performing certain tasks when a certain hard drive is plugged in. This article teaches you how to create a udev script triggered by some udev event, such as plugging in a specific thumb drive. Once you understand the process for working with udev, you can use it to do all manner of things, like loading a specific driver when a gamepad is attached, or performing an automatic backup when you attach your backup drive.[…]
With the increasing popularity of ARM64/AArch64 systems, from the Raspberry Pi 3 and PINE64 to Fujitsu’s move away from SPARC64 supercomputers, there hasn’t been a better time to get started with learning this architecture. I wanted to make a start to an Aarch64 assembly language tutorial but didn’t have access to my RPi3, so I looked into the state of QEMU’s emulation. I didn’t need RPi3-specific hardware – which is just as well as I can’t remember off-hand how the bootcode and start.elf crap would work with QEMU – anyway, I opted for a generic device using Linaro’s EDK2 UEFI firmware. The first pre-built EDK2 binary I downloaded wouldn’t play nicely with the OpenBSD kernel so I grabbed a release mentioned by the FreeBSD team – which worked.[…]
Jordan Rhee of Microsoft has created a new project. All the documentation was used for the Title.
Now I’m wondering what Project Cyres is.
one might think that such universality as a system being smart enough to be able to run any program might be difficult or hard to achieve, but it turns out to be the opposite and it is difficult to write a useful system which does not immediately tip over into TC
And a nice reference to this old Tweet:
It’s amazing how many heterogeneous CPU cores were integrated in Intel Silvermont’s Moorefield SoC (ANN): x86, ARC, LMT, 8051, Audio DSP, each running own firmware and supporting JTAG interface
[…]Will this work on a non-IBM server?
No, this uses IBM-specific UEFI hooks to reset the passwords.
Proc. 46th ACM SIGPLAN Symposium on Principles of Programming Languages
Architecture specifications notionally define the fundamental interface between hardware and software: the envelope of allowed behaviour for processor implementations, and the basic assumptions for software development and verification. But in practice, they are typically prose and pseudocode documents, not rigorous or executable artifacts, leaving software and verification on shaky ground. In this paper, we present rigorous semantic models for the sequential behaviour of large parts of the mainstream ARMv8-A, RISC-V, and MIPS architectures, and the research CHERI-MIPS architecture, that are complete enough to boot operating systems, variously Linux, FreeBSD, or seL4. Our ARMv8-A models are automatically translated from authoritative ARM-internal definitions, and (in one variant) tested against the ARM Architecture Validation Suite. We do this using a custom language for ISA semantics, Sail, with a lightweight dependent type system, that supports automatic generation of emulator code in C and OCaml, and automatic generation of proof-assistant definitions for Isabelle, HOL4, and (currently only for MIPS) Coq. We use the former for validation, and to assess specification coverage. To demonstrate the usability of the latter, we prove (in Isabelle) correctness of a purely functional characterisation of ARMv8-A address translation. We moreover integrate the RISC-V model into the RMEM tool for (user-mode) relaxed-memory concurrency exploration. We prove (on paper) the soundness of the core Sail type system. We thereby take a big step towards making the architectural abstraction actually well-defined, establishing foundations for verification and reasoning.
Keystone is an open-source project for building trusted execution environments (TEE) with secure hardware enclaves, based on the RISC-V architecture. Our goal is to build a secure and trustworthy open-source secure hardware enclave, accessible to everyone in industry and academia.