Assessing Unikernel Security
Unikernels are small, specialized, single-address-space machine images constructed by treating component applications and drivers like libraries and compiling them, along with a kernel and a thin OS layer, into a single binary blob. Proponents of unikernels claim that their smaller codebase and lack of excess services make them more efficient and secure than full-OS virtual machines and containers. We surveyed two major unikernels, Rumprun and IncludeOS, and found that this was decidedly not the case: unikernels, which in many ways resemble embedded systems, appear to have a similarly minimal level of security. Features like ASLR, W^X, stack canaries, heap integrity checks and more are either completely absent or seriously flawed. If an application running on such a system contains a memory corruption vulnerability, it is often possible for attackers to gain code execution, even in cases where the application’s source and binary are unknown. Furthermore, because the application and the kernel run together as a single process, an attacker who compromises a unikernel can immediately exploit functionality that would require privilege escalation on a regular OS, e.g. arbitrary packet I/O. We demonstrate such attacks on both Rumprun and IncludeOS unikernels, and recommend measures to mitigate them.
Private Key Extraction from Qualcomm Hardware-backed Keystores
A side-channel attack can extract private keys from certain versions of Qualcomm’s secure keystore. Recent Android devices include a hardware-backed keystore, which developers can use to protect their cryptographic keys with secure hardware. On some devices, Qualcomm’s TrustZone-based keystore leaks sensitive information through the branch predictor and memory caches, enabling recovery of 224 and 256-bit ECDSA keys. We demonstrate this by extracting an ECDSA P-256 private key from the hardware-backed keystore on the Nexus 5X.
Alignment requirements for memory management functions
The alignment requirements are ambiguous in how they affect small allocations (sizes less than _Alignof(max_align_t)). Some implementations interpret this sentence to require _Alignof(max_align_t)-alignment even for allocation sizes that could not hold an object with that alignment. This is referred to as the strong-alignment reading. Other implementations interpret this sentence as requiring the returned memory to be aligned only enough to accommodate those types that could inhabit the returned memory. In particular, because sizeof(T) >= _Alignof(T) for all portably defined types T, allocations with sizes smaller than _Alignof(max_align_t) need only be aligned to the largest power of two less than or equal to the requested size. This is referred to as the weak-alignment reading.
Cisco ASA mempools
In part six, we document some of the details around Cisco ASA mempools and how the mempool-related functions wrap more traditional heap functions in order to inject their own book-keeping structures. We will introduce a gdb plugin called libmempool  that aids with analysing these structures.
They say to read the other parts in the series, but you don’t have to.
FedEx & TNT Express: A lesson in M&A cyber security due diligence & collateral economic disruption
Prepare for 19-Digit Credit Cards
Can’t wait to get one of these and be unable to buy anything online from broken web forms.
DriverBuddy Tool Release
DriverBuddy is an IDAPython plugin that helps automate some of the tedium surrounding the reverse engineering of Windows kernel drivers.