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.[…]

http://www.schatzforensic.com.au/insideout/2018/06/how-to-acquire-linux-memory-images-using-without-a-driver/

https://github.com/google/rekall/tree/master/tools/pmem

https://evimetry.com/getting-started/linear-ram-live/

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

client_boot1.gif

 

 

LAVA: Large-scale Automated Vulnerability Addition for PANDA

Re: https://firmwaresecurity.com/2015/11/23/panda-vm/ and https://firmwaresecurity.com/2016/12/01/panda-2-0-released/

PANDA is an open-source Platform for Architecture-Neutral Dynamic Analysis. It is built upon the QEMU whole system emulator, and so analyses have access to all code executing in the guest and all data. PANDA adds the ability to record and replay executions, enabling iterative, deep, whole system analyses. Further, the replay log files are compact and shareable, allowing for repeatable experiments. A nine billion instruction boot of FreeBSD, e.g., is represented by only a few hundred MB. PANDA leverages QEMU’s support of thirteen different CPU architectures to make analyses of those diverse instruction sets possible within the LLVM IR. In this way, PANDA can have a single dynamic taint analysis, for example, that precisely supports many CPUs. PANDA analyses are written in a simple plugin architecture which includes a mechanism to share functionality between plugins, increasing analysis code re-use and simplifying complex analysis development.

LAVA (Large Scale Automated Vulnerability Addition) for PANDA:

Evaluating and improving bug-finding tools is currently difficult due to a shortage of ground truth corpora (i.e., software that has known bugs with triggering inputs). LAVA attempts to solve this problem by automatically injecting bugs into software. Every LAVA bug is accompanied by an input that triggers it whereas normal inputs are extremely unlikely to do so. These vulnerabilities are synthetic but, we argue, still realistic, in the sense that they are embedded deep within programs and are triggered by real inputs. Our work forms the basis of an approach for generating large ground-truth vulnerability corpora on demand, enabling rigorous tool evaluation and providing a high-quality target for tool developers. 

https://github.com/panda-re/lava

https://github.com/panda-re/panda

PANDA’s LAVA is separate from the Linaro LAVA project, which the Tags on this blog points to.

 

 

VMWare: Enable or Disable UEFI Secure Boot for a Virtual Machine

I believe this is a new (or revised) document [to me].

[…]VMware Tools version 10.1 or later is required for virtual machines that use UEFI secure boot. You can upgrade those virtual machines to a later version of VMware Tools when it becomes available.

For Linux virtual machines, VMware Host-Guest Filesystem is not supported in secure boot mode. Remove VMware Host-Guest Filesystem from VMware Tools before you enable secure boot.[…]

https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-898217D4-689D-4EB5-866C-888353FE241C.html

 

CHIPSEC gets support for Nine more ACPI tables

Lots of news are filled with news about the latest  version of CHIPSEC released. I don’t see that, but there are some interesting new checkins w/r/t ACPI support:

ACPI_TABLE_SIG_BGRT = ‘BGRT’
ACPI_TABLE_SIG_LPIT = ‘LPIT’
ACPI_TABLE_SIG_ASPT = ‘ASPT’
+ACPI_TABLE_SIG_FIDT = ‘FIDT’
+ACPI_TABLE_SIG_HEST = ‘HEST’
+ACPI_TABLE_SIG_BERT = ‘BERT’
+ACPI_TABLE_SIG_ERST = ‘ERST’
+ACPI_TABLE_SIG_EINJ = ‘EINJ’
+ACPI_TABLE_SIG_TPM2 = ‘TPM2’
+ACPI_TABLE_SIG_WSMT = ‘WSMT’
+ACPI_TABLE_SIG_DBG2 = ‘DBG2’
+ACPI_TABLE_SIG_NHLT = ‘NHLT’
+ACPI_TABLE_SIG_MSCT = ‘MSCT’
+ACPI_TABLE_SIG_RASF = ‘RASF’
+ACPI_TABLE_SIG_SPMI = ‘SPMI’
+ACPI_TABLE_SIG_OEM1 = ‘OEM1’
+ACPI_TABLE_SIG_OEM2 = ‘OEM2’
+ACPI_TABLE_SIG_OEM3 = ‘OEM3’
+ACPI_TABLE_SIG_OEM4 = ‘OEM4’
+ACPI_TABLE_SIG_NFIT = ‘NFIT’

as well as some new SGX support… Fun!

https://github.com/chipsec/chipsec/commits/master

Down the rabbit hole of tboot, E820 maps, and Xen PV PCI-passthrough domains

https://github.com/OpenXT/xenclient-oe/pull/890#issuecomment-395497431

From an OpenXT bug report:

TL;DR: a minor adjustment had to be made in tboot so that it picks the right memory protection for itself in the E820 map. The bug only affected PV Linux guests with PCI-passthrough devices as correctly guessed above.[…]

Microsoft Research 2017: The Seven Properties of Highly Secure Devices

The Seven Properties of Highly Secure Devices
March 31, 2017
MSR-TR-2017-16

Industry largely underestimates the critical societal need to embody the highest levels of security in every network-connected device—every child’s toy, every household’s appliances, and every industry’s equipment. High development and maintenance costs have limited strong security to high-cost or highmargin devices. Our group has begun a research agenda to bring high-value security to low-cost devices. We are especially concerned with the tens of billions of devices powered by microcontrollers. This class of devices is particularly ill-prepared for the security challenges of internet connectivity. Insufficient investments in the security needs of these and other price-sensitive devices have left consumers and society critically exposed to device security and privacy failures. This paper makes two contributions to the field of device security. First, we identify seven properties we assert are required in all highly secure devices. Second, we describe our experiment working with a silicon partner to revise one of their microcontrollers to create a prototype, highly secure microcontroller. Our experimental results suggest that in the near future even the most price-sensitive devices should be redesigned to achieve the high levels of device security critical to society’s safety. While our first experimental results are promising, more ongoing research remains and we seek to enlist the broader security community in a dialog on device security.

https://www.microsoft.com/en-us/research/publication/seven-properties-highly-secure-devices/

 

Firmwalker review

SecurityBoulevard has a new blog post on the FirmWalker tool.

IoT Firmware Analysis — Firmwalker
by Nitesh Malviya on May 27, 2018

IoT is the next big technology that will change the way we communicate and exchange data. Every day thousands of IoT devices are coming into the market. Most of these devices collect and exchange data over the cloud. Not much effort has been put into securing the IoT devices, thus understanding the security of IoT devices and their communication is of utmost importance.[…]

IoT Firmware Analysis — Firmwalker

 

Uptane, and: firmware security humor: nearly impossible :-)

“Uptane is the first compromise-resilient software update security system for the automotive industry. […] Uptane has been security audited by several different groups. We welcome further audits from the community. You can help to fix security issues before hackers use them to exploit millions of cars!.”

https://uptane.github.io/

https://github.com/uptane/uptane

A humorous 3-tweet conversation, in the context of automotive firmware updates and security, from where I learned about Uptane:

https://twitter.com/trishankkarthik/status/1003360144862916613

 

Side-channel attacking browsers through CSS3 features

tl;dr:
We (co-)discovered a side-channel vulnerability in browser implementations of the CSS3 feature “mix-blend-mode” which allowed to leak visual content from cross-origin iframes.
We demonstrate the impact of this vulnerability by showing how visiting a malicious site was enough to de-anonymize Facebook users. In particular, exploitation allowed to leak the profile picture, username and likes of unsuspecting visitors all while requiring no additional user interaction.
This vulnerability affected major browsers like Chrome and Firefox and was disclosed responsibly.

Side-channel attacking browsers through CSS3 features

 

OpenBSD gets RETGUARD (anti-ROP) for Clang x64

RETGUARD for clang (amd64) added to -current

Contributed by rueda on 2018-06-06 from the d(e)ropping-the-gadgets dept.

Todd Mortimer has committed “RETGUARD” for clang (for amd64).

http://undeadly.org/cgi?action=article;sid=20180606064444

Phasar, LLVM-based static-analysis framework

Phasar is a LLVM-based static analysis framework written in C++. It allows users to specify arbitrary data-flow problems which are then solved in a fully-automated manner on the specified LLVM IR target code. Computing points-to information, call-graph(s), etc. is done by the framework, thus you can focus on what matters.

PhASAR

Tutorial

https://github.com/pdschubert/phasar

alt text

 

Eclypsium: new Supermicro firmware research

https://twitter.com/ABazhaniuk/status/1004835960507559936

https://blog.eclypsium.com/2018/06/07/firmware-vulnerabilities-in-supermicro-systems/

https://www.bleepingcomputer.com/news/security/firmware-vulnerabilities-disclosed-in-supermicro-server-products/

[…]We have confirmed missing firmware storage access controls and insecure firmware updates on specific Supermicro systems. Many other systems are likely to have similar vulnerabilities, leaving them exposed to attacks targeting firmware and hardware. Since most organizations do not monitor at this deep level, these attacks may go unnoticed for an extended period. By providing this summary of the vulnerabilities, impacts, and mitigation strategies, we hope to assist organizations in understanding and defending against threats at this level.

I did not see any CVE yet, I hope SuperMicro has seen this.

Teddy Reed on U-Boot’s Verified Boot

Teddy Reed, author of UEFI Firmware Parser, among other things, has some U-Boot Verified Boot issues:

Verified boot production uses question

Hi all, question, is anyone using the U-Boot verified-boot in production? I am using configuration verification for several OpenCompute/OpenBMC boards. After a deep-dive review I found some edge cases that in rare circumstances could lead to a signature check bypass. I think this is low-risk at best since the scenario requires special hardware behavior to exist. Our board were susceptible in the general sense, but we had implemented some additional sanity checks on the FIT structures that
prevented this. There are some proposed changes that attempt to mitigate this [1], [2], [3]. Any one of these changes mitigates the bypass scenario. If you don’t mind reaching out to me I can share the exact situation/details.

[1] https://lists.denx.de/pipermail/u-boot/2018-June/330454.html
[2] https://lists.denx.de/pipermail/u-boot/2018-June/330487.html
[3] https://lists.denx.de/pipermail/u-boot/2018-June/330599.html

https://lists.denx.de/pipermail/u-boot/2018-June/330898.html

Shadow-Box: Lightweight and Practical Kernel Protector for x86 (or ARM)

Lightweight Hypervisor-Based Kernel Protector

Shadow-box v2 (for ARM) is a next generation of Shadow-box v1 (for x86). If you want to know about Shadow-box for ARM, please visit Shadow-box for ARM project.

https://github.com/kkamagui/shadow-box-for-x86

https://github.com/kkamagui/shadow-box-for-arm

ACM SIG Int’l Symposium on Microarchitecture 2017: slides “temporarily available”

https://drive.google.com/drive/folders/1cmjix6YEPiyRde7Be2vshtny4mHjZ50p

https://www.microarch.org/micro50/

https://dl.acm.org/citation.cfm?id=3123939

http://www.wikicfp.com/cfp/servlet/event.showcfp?eventid=60858

Graz: School on Security and Correctness in the IoT 2018

Welcome to our second School on Security & Correctness in the Internet of Things 2018, held from 3.-9. September. It is hosted by the research center “Dependable Internet of Things“, located at Graz University of Technology. This school targets graduate students interested in security aspects of tomorrow’s IoT devices. Current advances in technology drive miniaturization and efficiency of computing devices, opening a variety of novel use cases like autonomous transportation, smart cities and health monitoring devices. However, device malfunction could potentially threaten human welfare or even life. Malfunction might not only be caused by design errors but also by intentional impairment. As computing devices are supposed to have high and permanent network connectivity, an attacker finding a vulnerability might easily target millions of devices at once. Moreover, integration of computing devices in everyday items exposes them to a potentially hostile physical environment. A central requirement of tomorrow’s IoT is the ability to execute software dependably on all kinds of devices. IoT devices need to provide security in the presence of network attacks as well as against attackers having physical access to the device. During the five-day school, participants will gain awareness of these IoT-related challenges. Introductory classes are supplemented by advanced courses in the area of system security, cryptography as well as software and hardware side-channels. During spare time participants are invited to enjoy the city of Graz and attend organized events.

https://www.securityweek.at/school/