Nice job title, …and without using “Cyber”, even!
Job description is well-written, I can guess at who wrote it. 🙂
Month: June 2018
CopperheadOS and AndroidHardening project
ZeroTrace: enables building systems secure against side-channels in SGX enclaves
https://twitter.com/sergey_nog/status/1006582302057619456
ZeroTrace(ZT) is the first system that enabled instantiations of Oblivious-RAMs(ORAMs) on a server-device that supports Intel-SGX. ZT is also secure against known side-channel attacks against SGX.* Oblivous RAM or ORAMs have been theoretically known for a long while now [1], with the advent of secure hardware modules like Intel SGX, we notice an opportunity to make these incredible cryptographic primitives, deployable in practical scenarios.[…]
https://github.com/sshsshy/ZeroTrace
10-Part Introduction to KiCad video series available
A 10-part video introduction to KiCad is now available:
Expliot: IoT Exploitation Framework (pronounced – expl-aa-yo-tee)
Expliot (Pronounced – expl-aa-yo-tee)
Internet Of Things Exploitation Framework
Expliot is a framework for security testing IoT and IoT infrastructure. It provides a set of plugins (test cases) and can be extended easily to create new plugins. The name expliot is a pun on exploit and explains the purpose of the framework i.e. IoT exploitation. It is developed in python3[…]
https://gitlab.com/expliot_framework/expliot
Intel Floating Point issue?
According to the oss-security list, there’s an ‘Intel FP issue’, and the BSDs are doing patches against it:
https://marc.info/?l=openbsd-cvs&m=152818076013158&w=2
http://lists.dragonflybsd.org/pipermail/commits/2018-June/672324.html
https://svnweb.freebsd.org/base?view=revision&revision=335072
I don’t know more about this FP issue other than above. For the record, I prefer the old days, when kernel mode didn’t rely on floating point, so the OS didn’t have to save state for drivers. 🙂
Facebook open sources Sonar, debugging tool
Open-sourcing Sonar, a new extensible debugging tool
Emil Sjölander
One challenge that comes from having many engineers working collaboratively on larger apps is that typically no single person knows how every module works. This segmentation of knowledge and expertise can make it difficult to develop new features, investigate bugs, or optimize performance. To help engineers at Facebook manage this complexity, we built Sonar, an extensible cross-platform debugging tool. Sonar gives us a surface where framework experts and developers can convey important information to framework users. Now we are adding functionality and sharing Sonar as an open source project to help others accelerate the app development process. With Sonar, engineers have a highly flexible, intuitive way to inspect and understand the structure and behavior of their iOS and Android applications. We believe Sonar improves on current tools by providing a more visual and interactive experience that is extensible to fit engineers’ specific needs.[…]
https://github.com/facebook/Sonar/
NEMU: fork of QEMU by Intel
NEMU is an open source hypervisor specifically built and designed to run modern cloud workloads on modern 64-bit Intel and ARM CPUs.
Windows: new feature using IOMMU to block DMA access for Thunderbolt devices when machine is locked
The latest version of Windows apparently has new protections against PCILeech and related attacks:
Introducing graphene-ng: running arbitrary payloads in SGX enclaves
Jun 11, 2018 by Joanna Rutkowska
A few months ago, during my keynote at Black Hat Europe, I was discussing how we should be limiting the amount of trust when building computer systems. Recently, a new technology from Intel has been gaining popularity among both developers and researchers, a technology which promises a big step towards such trust-minimizing systems. I’m talking about Intel SGX, of course. Intel SGX caught my attention for the first time about 5 years ago, a little while before Intel has officially added information about it to the official Software Developer’s Manual. I’ve written two posts about my thoughts on this (then-upcoming) technology, which were a superposition of both positive and negative feelings. Over the last 2 years or so, together with my team at ITL, we’ve been investigating this fascinating technology a bit closer. Today I’d like to share some introductory information on this interesting project we’ve been working on together with our friends at Golem for several months now.[…]
https://blog.invisiblethings.org/2018/06/11/graphene-ng.html
An ice-cold Boot to break BitLocker
An ice-cold Boot to break BitLocker
By Olle Segerdahl & Pasi Saarinen
A decade ago, academic researchers demonstrated how computer memory remanence could be used to defeat popular disk encryption systems. Not much has happened since, and most seem to believe that these attacks are too impractical for real world use. Even Microsoft have even started to play down the threat of memory remanence attacks against BitLocker, using words such as “they are not possible using published techniques”. We will publish techniques that allow recovery of BitLocker encryption keys from RAM on most, if not all, currently available devices. While BitLocker is called out in the title, the same attacks are also valid against other platforms and operating systems.
Olle is a veteran of the IT-security industry, having worked with both “breaking” and “building” security solutions for almost 20 years. During that time, he has worked on securing classified systems, critical infrastructure and cryptographic products as well as building software whitelisting solutions used by industrial robots and medical equipment. He is currently the Swedish Principal Security Consultant with F-Secure’s technical security consulting practice.
Pasi is an experienced security researcher with a background in both software and network security. In previous employment he has worked on a modern framework for white-box fuzz testing of binaries and security standardization of the 5G mobile network. While he has a very Finnish name, he plays for team Sweden in F-Secure’s technical security consulting practice.
Using S2E to generate PoVs for Linux, Windows, and CGC binaries
US Treasury Sanctions Russian Federal Security Service Enablers
https://twitter.com/GossiTheDog/status/1006187828366192641
“Embedi was designated pursuant to E.O. 13694, as amended. As of May 2017, Embedi was owned or controlled by Digital Security.”
https://home.treasury.gov/news/press-releases/sm0410
Embedi does firmware security research.
Subverting your server through it’s BMC: the HPE iLo4 case (presentation + toolbox)
NIST SP 800-125A: Security Recommendations for Server-based Hypervisor Platforms
Date Published: June 2018
Supersedes: SP 800-125A (January 2018)
The Hypervisor platform is a collection of software modules that provides virtualization of hardware resources (such as CPU, Memory, Network and Storage) and thus enables multiple computing stacks (made of an operating system (OS) and application programs) called Virtual Machines (VMs) to be run on a single physical host. In addition, it may have the functionality to define a network within the single physical host (called virtual network) to enable communication among the VMs resident on that host as well as with physical and virtual machines outside the host. With all this functionality, the hypervisor has the responsibility to mediate access to physical resources, provide run time isolation among resident VMs and enable a virtual network that provides security-preserving communication flow among the VMs and between the VMs and the external network. The architecture of a hypervisor can be classified in different ways. The security recommendations in this document relate to ensuring the secure execution of baseline functions of the hypervisor and are therefore agnostic to the hypervisor architecture. Further, the recommendations are in the context of a hypervisor deployed for server virtualization and not for other use cases such as embedded systems and desktops. Recommendations for secure configuration of a virtual network are dealt with in a separate NIST document (Special Publication 800-125B). [This revision includes additional technologies for device virtualization such as para-virtualization, passthrough and self-virtualizing hardware devices as well as associated security recommendations. Major content changes in this revision are in: Section 1.1, Section 2.2.2 and Section 5.]
https://csrc.nist.gov/News/2018/NIST-Publishes-SP-800-125A-Rev-1
https://csrc.nist.gov/publications/detail/sp/800-125a/rev-1/final
Automated Detection, Exploitation, and Elimination of Double-Fetch Bugs using Modern CPU Features
Double-fetch bugs are a special type of race condition, where an unprivileged execution thread is able to change a memory location between the time-of-check and time-of-use of a privileged execution thread. If an unprivileged attacker changes the value at the right time, the privileged operation becomes inconsistent, leading to a change in control flow, and thus an escalation of privileges for the attacker. More severely, such double-fetch bugs can be introduced by the compiler, entirely invisible on the source-code level. We propose novel techniques to efficiently detect, exploit, and eliminate double-fetch bugs. We demonstrate the first combination of state-of-the-art cache attacks with kernel-fuzzing techniques to allow fully automated identification of double fetches. We demonstrate the first fully automated reliable detection and exploitation of double-fetch bugs, making manual analysis as in previous work superfluous. We show that cache-based triggers outperform state-of-the-art exploitation techniques significantly, leading to an exploitation success rate of up to 97%. Our modified fuzzer automatically detects double fetches and automatically narrows down this candidate set for double-fetch bugs to the exploitable ones. We present the first generic technique based on hardware transactional memory, to eliminate double-fetch bugs in a fully automated and transparent manner. We extend defensive programming techniques by retrofitting arbitrary code with automated double-fetch prevention, both in trusted execution environments as well as in syscalls, with a performance overhead below 1%.
Niklas Baumstark: Unboxing your VirtualBox
How to acquire Linux memory images using without a driver
How to acquire Linux memory images using without a driver
Posted on Sunday, June 10th, 2018 at 5:52 am.
Written by blschatz
For a long time now, operating systems such as Windows and MacOS have prevented user space applications from accessing the raw physical memory of the machine. Physical acquisition and virtualisation approaches aside, this has led the field to require the use of kernel drivers to export physical ram for acquisition. In the linux realm, Joe Sylve’s LiME is the go-to for many. It appears not widely known that on Linux x64, acquisition of physical memory is possible without using a driver such as LiME. The prerequisite here is that /proc/kcore is enabled, which fortunately is widely the case: Ubuntu ships with it enabled by default, as does Redhat. On x64 the full physical address space is mapped into the kernel address space, and /proc/kcore exports this as a part of its virtual ELF file view.[…]
FreeBSD 11.2R released, with speculative execution and UEFI updates
The latest version of FreeBSD is out, and has a few speculative execution and UEFI changes, including:
https://www.freebsd.org/releases/11.2R/relnotes.html
[arm64] The bsdinstall(8) installer has been updated to default to UEFI-only boot. [r322254]
(Sponsored by The FreeBSD Foundation)
The efibootmgr(8) utility has been added, which is used to manipulate the EFI boot manager. [r332126]
(Sponsored by Netflix)
https://www.freebsd.org/cgi/man.cgi?query=efibootmgr&sektion=8&manpath=freebsd-release-ports
The cpucontrol(8) utility has been updated to include a new flag, -e, which is used to re-evaluate reported CPU features after applying firmware updates. [r327871]
Note: The cpucontrol(8) -e flag should only be used after microcode update have been applied to all CPUs in the system, otherwise system instability may be experienced if processor features are not identical across the system.
https://www.freebsd.org/cgi/man.cgi?query=cpucontrol&sektion=8&manpath=freebsd-release-ports
FreeBSD-SA-18:03.speculative_execution 14 March 2018. Speculative Execution Vulnerabilities
Note: This advisory addresses the most significant issues for FreeBSD 11.x on amd64 CPUs. We expect to update this advisory to include i386 and other CPUs.
https://www.freebsd.org/security/advisories/FreeBSD-SA-18:03.speculative_execution.asc
iPXE-Boot-Server: Setup iPXE to support both BIOS and UEFI
Step by step guide for how to build your own PXE boot server supporting both legacy BIOS and EFI hardare
Build your own PXE boot server
This article is a step by step guide for building your own PXE boot infrastructure which can be used to boot both legacy BIOS and EFI based hardware from network. There are many articles on the Internet for building PXE boot infrastructure however I found most of them does not work for EFI based hardware. I use iPXE as the boot image and dnsmasq as DHCP & TFTP server and I found it’s dead simple to setup those two software.
https://github.com/boliu83/ipxe-boot-server
Firmware Security 
You must be logged in to post a comment.