Month: February 2018

ARM adds Shared Virtual Addressing (SVA) for IOMMU to Linux kernel

~ hucktech ~ Leave a comment

Jean-Philippe Brucker of ARM sent a 37-part patch, adding SVA support to Linux kernel, excerpts of announcement below:

Shared Virtual Addressing (SVA) is the ability to share process address spaces with devices. It is called “SVM” (Shared Virtual Memory) by OpenCL and some IOMMU architectures, but since that abbreviation is already used for AMD virtualisation in Linux (Secure Virtual Machine), we prefer the less ambiguous “SVA”. Sharing process address spaces with devices allows to rely on core kernel memory management for DMA, removing some complexity from application and device drivers. After binding to a device, applications can instruct it to perform DMA on buffers obtained with malloc.

The device, buses and the IOMMU must support the following features:
* Multiple address spaces per device, for example using the PCI PASID (Process Address Space ID) extension. The IOMMU driver allocates a PASID and the device uses it in DMA transactions.
* I/O Page Faults (IOPF), for example PCI PRI (Page Request Interface) or Arm SMMU stall. The core mm handles translation faults from the IOMMU.
* MMU and IOMMU implement compatible page table formats.

This series requires to support all three features. I tried to facilitate using only a subset of them but enabling it requires more work. Upcoming patches will enable private PASID management, which allows device driver to use an API similar to classical DMA, map()/unmap() on PASIDs. In the future device drivers should also be able to use SVA without IOPF by pinning all pages, or without PASID by sharing the single device address space with a process. Although we don’t have any performance measurement at the moment, SVA will likely be slower than classical DMA since it relies on page faults, whereas classical DMA pins all pages in memory. SVA mostly aims at simplifying DMA management, but also improves security by isolating address spaces in devices. Intel and AMD IOMMU drivers already offer slightly differing public functions that bind process address spaces to devices. Because they don’t go through an architecture-agnostic API, only integrated devices could use them so far. […]

Full patch:
https://lists.linuxfoundation.org/pipermail/iommu/2018-February/025992.html
More info on IOMMUs:
http://pages.cs.wisc.edu/~basu/isca_iommu_tutorial/index.htm
https://github.com/chipsec/chipsec/blob/master/chipsec/hal/iommu.py
https://www.spinics.net/lists/arm-kernel/msg609771.html
https://www.spinics.net/lists/kernel/msg2651481.html
https://www.spinics.net/lists/kvm/msg148819.html
https://developer.arm.com/products/architecture/a-profile/docs/100940/latest/separation-of-kernel-and-application-virtual-address-spaces
https://software.intel.com/en-us/articles/opencl-20-shared-virtual-memory-overview
https://www.khronos.org/registry/OpenCL/sdk/2.1/docs/man/xhtml/sharedVirtualMemory.html
https://lwn.net/Articles/726606/

Click to access 48882_IOMMU.pdf

https://en.wikipedia.org/wiki/List_of_IOMMU-supporting_hardware
https://software.intel.com/en-us/blogs/2009/03/02/intels-virtualization-for-directed-io-aka-iommu-part-1

 

DelegaTEE: Brokered Delegation Using Trusted Execution Environments

~ hucktech ~ Leave a comment

DelegaTEE: Brokered Delegation Using Trusted Execution Environments

Sinisa Matetic and Moritz Schneider and Andrew Miller and Ari Juels and Srdjan Capkun

We introduce a new concept called brokered delegation. Brokered delegation allows users to flexibly delegate credentials and rights for a range of service providers to other users and third parties. We explore how brokered delegation can be implemented using novel trusted execution environments (TEEs). We introduce a system called DelegaTEE that enables users (Delegatees) to log into different online services using the credentials of other users (Owners). Credentials in DelegaTEE are never revealed to Delegatees and Owners can restrict access to their accounts using a range of rich, contextually dependent delegation policies. DelegaTEE fundamentally shifts existing access control models for centralized online services. It does so by using TEEs to permit access delegation at the user’s discretion. DelegaTEE thus effectively reduces mandatory access control (MAC) in this context to discretionary access control (DAC). The system demonstrates the significant potential for TEEs to create new forms of resource sharing around online services without the direct support from those services. We present a full implementation of DelegaTEE using Intel SGX and demonstrate its use in four real-world applications: email access (SMTP/IMAP), restricted website access using a HTTPS proxy, e-banking/credit card, and a third-party payment system (PayPal).

https://eprint.iacr.org/2018/160

Click to access 160.pdf

FACT: Firmware Analysis and Comparison Tool

~ hucktech ~ Leave a comment

Firmware Analysis and Comparision Tool (FACT)
Peter Weidenbach
The Firmware Analysis and Comparison Tool (FACT) is intended to automate Firmware Security analysis. Thereby, it shall be easy to use (web GUI), extend (plug-in system) and integrate (REST API). When analyzing Firmware, you face several challenges: unpacking, initial analysis, identifying changes towards other versions, find other firmware images that might share vulnerabilities you just found. FACT is able to automate many aspects of these challenges leading to a massive speedup in the firmware analysis process. This means you can focus on the fun part of finding new vulnerabilities, whereas FACT does all the boring stuff for you.[…]

https://fkie-cad.github.io/FACT_core/

https://github.com/fkie-cad/FACT_firmadyne_analysis_plugin

https://www.blackhat.com/asia-18/arsenal/schedule/index.html#firmware-analysis-and-comparision-tool-fact-9712

FACT Logo

Low-level iOS forensics: iBoot ‘metadata whitening’

~ hucktech ~ Leave a comment

Low-level iOS forensics
Thu 28 June 2012 by jean

iOS filesystem encryption and data protection mechanisms are now well documented and supported by many forensics tools. iOS devices use NAND flash memory as their main storage area, but physical imaging usually refers to a “dd image” of the logical partitions. The iOS Flash Translation Layer for current devices is software-based (implemented in iBoot and the kernel), which means that the CPU has direct access to raw NAND memory. In this post we will describe how to acquire a NAND image and use FTL metadata to recover deleted files on A4 devices. The information presented here is based on the great reverse engineering work done by the iDroid/openiBoot team.[…]

http://esec-lab.sogeti.com/posts/2012/06/28/low-level-ios-forensics.html

https://code.google.com/archive/p/iphone-dataprotection/wikis

Teddy Reed: Exploring secured boot on the Sabre Lite i.MX6S (v1.3) SBC and NXP HABv4

~ hucktech ~ Leave a comment

Exploring secured boot on the Sabre Lite i.MX6S (v1.3) SBC and NXP HABv4
February 10, 2018

This document is a linear review of my notes taken while exploring the Sabre Lite single-board-computer. It is a mildly expensive ($200 from Boundary Devices) SBC but it has a well documented secure boot implementation rooted in silicon ROM. It is a very good example of a vendor proprietary firmware verification mechanism. The goal of this article is purely an overview of notes, nothing here is novel or groundbreaking and it is not intended to be a tutorial.[…]

https://prosauce.org/blog/2018/2/10/exploring-secured-boot-on-the-sabre-lite-imx6s-v13-sbc-and-nxp-habv4

The i/MX image header, where Image Data can be U-Boot, followed by an optional CSF.

Apple baseband comm driver kext source leaked?

~ hucktech ~ Leave a comment

https://twitter.com/Mario_Vilas/status/962023148806750208

https://twitter.com/chronic/status/962090476072525826

https://twitter.com/internals_apple/status/962143308070957057

https://twitter.com/i_droid_phone/status/961770262894186497

https://twitter.com/Apple_External/status/962147625221767168

https://twitter.com/internals_apple/status/961391228771332097

https://twitter.com/kittenpies3/status/962343688373440513

Lenovo: Intel AMT MEBx Access Control Bypass

~ hucktech ~ Leave a comment

Intel Active Management Technology MEBx Access Control Bypass
2018-02-08
Initial Release

Scope of Impact: Industry-wide
Lenovo Security Advisory: LEN-19568
Potential Impact: Remote access and control
Severity: Critical

Intel has issued an advisory for Intel vPro Active Management Technology (AMT) to all system manufacturers. The Intel AMT default configuration has weak security around the Management Engine BIOS Extension (MEBx) password.[…]

ThinkPad – Updates coming soon
ThinkServer- Researching

https://support.lenovo.com/us/en/solutions/LEN-19568

https://sintonen.fi/advisories/intel-active-management-technology-mebx-bypass.txt

https://www.intel.com/content/www/us/en/support/articles/000020917/software/manageability-products.html

Click to access Intel_AMT_Security_Best_Practices_QA.pdf

http://thinkdeploy.blogspot.com/2016/08/the-think-bios-config-tool.html

 

 

LAVA 2018.2 released

~ hucktech ~ Leave a comment

Neil Williams of Linaro announced the 2018.2 release of LAVA. Here’s 3 changes excerpted from the announcement below:

* Bootloader support changes: Better detect errors in the bootloader – this adds support to distinguish between a bootloader failure and a kernel failure to detect problems when the bootloader tries to start the kernel. This has an important effect on how some test jobs run – see Quiet Kernels below. The parallel change (7a2b3a68 Change the flow of bootloader commands so they are executed individually) supports detecting failures to download artifacts as distinct from failures to execute once downloaded.

* Bootloader action optimisations: To support the better error detection, several bootloader actions have been optimised. This means that different actions may be used, changing the names you may be using for timeouts. e.g.
https://staging.validation.linaro.org/scheduler/job/209814/definition#defline10
The timeout name was u-boot-interrupt – now it is bootloader-interrupt. The UI shows you which actions have been assembled into the pipeline.
e.g.: bootloader-interrupt: Wait for prompt Hit any key to stop autoboot (timeout 00:02:00)

* Quiet Kernels: The bootloader support changes wait for an indication that the bootloader has completed and that the kernel has started, by watching for a kernel_start_message. If your kernel is configured to be quiet, then each test job using that kernel *must* clear the kernel_start_message:
   context:
   kernel_start_message: ”
In most cases, the test job should not use ‘quiet’ as this hides important debugging information from the kernel boot process.
[…]

https://lists.linaro.org/pipermail/lava-announce/2018-February/000048.html
https://www.linaro.org/initiatives/lava
https://validation.linaro.org/
https://wiki.linaro.org/LAVA
https://github.com/search?q=org%3ALinaro+lava

cpu_features: library from Google Compiler Research Team

~ hucktech ~ Leave a comment

https://twitter.com/revskills/status/961322810349105154

[…]Here’s the problem: there’s no way to know a priori which instructions your CPU supports. Identifying the CPU manufacturer isn’t sufficient. For instance, Intel’s Haswell architecture supports the AVX2 instruction set, while Sandy Bridge doesn’t. Some developers resort to desperate measures like reading /proc/cpuinfo to identify the CPU and then consulting hardcoded mappings of CPU IDs to instructions. Enter cpu_features, a small, fast, and simple open source library to report CPU features at runtime. Written in C89 for maximum portability, it allocates no memory and is suitable for implementing fundamental functions and running in sandboxed environments. The library currently supports x86, ARM/AArch64, and MIPS processors, and we’ll be adding to it as the need arises. We also welcome contributions from others interested in making programs “write once, run fast everywhere.”

By Guillaume Chatelet, Google Compiler Research Team

https://opensource.googleblog.com/2018/02/cpu-features-library.html

https://github.com/google/cpu_features

Microsoft driver security checklist

~ hucktech ~ Leave a comment

Driver security checklist
01/26/2018
Don Marshall

This article provides a driver security checklist for driver developers to help reduce the risk of drivers being compromised.[…]

https://docs.microsoft.com/en-us/windows-hardware/drivers/driversecurity/driver-security-checklist

 

 

Apple iBoot source code gets leaked

~ hucktech ~ Leave a comment

DMCA takedowns have taken down some of the copies, but multiple others are still online.

https://twitter.com/RNavalgund_/status/961234957866754049

https://twitter.com/sizeofcat/status/961566184612114432

https://github.com/ZioShiba/iBoot

https://github.com/h1x0rz3r0/iBoot

https://github.com/emrakul2002/iboot

https://0xacab.org/sizeofcat/iBoot

 

iLo4_toolbox: Toolbox for HPE iLO4 analysis

~ hucktech ~ Leave a comment

Subverting your server through its BMC: the HPE iLO4 case
iLO is the server management solution embedded in almost every HP servers for more than 10 years. It provides every feature required by a system administrator to remotely manage a server without having to reach it physically. Such features include power management, remote system console, remote CD/DVD image mounting, as well as many monitoring indicators. We’ve performed a deep dive security study of HP iLO4 (known to be used on the family of servers HP ProLiant Gen8 and ProLiant Gen9 servers) and the results of this study were presented at the REcon conference held in Brussels (February 2 – 4, 2018, see [1]). iLO4 runs on a dedicated ARM processor embedded in the server, and is totally independent from the main processor. It has a dedicated flash chip to hold its firmware, a dedicated RAM chip and a dedicated network interface. On the software side, the operating system is the proprietary RTOS GreenHills Integrity [2].[…]

https://github.com/airbus-seclab/ilo4_toolbox

 

Physically Unclonable Functions (PUF)

~ hucktech ~ Leave a comment

Imperfect Silicon, Near-Perfect Security
Physically unclonable functions (PUF) seem tailor-made for IoT security.
February 7th, 2018 – By: Kevin Fogarty
Some chipmakers, under pressure to add security to rapidly growing numbers of IoT devices, have rediscovered a “fingerprinting” technique used primarily as an anti-counterfeiting measure. Physically unclonable functions (PUFs) are used to assign a unique identification number based on inconsistencies in the speed with which current causes a series of logic gates to open or close. So otherwise identical chips will deliver different results in identical test circuits due to random variation in the speed with which those gates respond to a test, according to a 2007 paper by MIT researcher Srini Devadas, who discovered the pattern and founded the company Verayo to commercialize systems that use it.[…]
[…]More than 84% of chipmakers responding to a 2017 McKinsey & Co. survey said customers want good security. But only 15% predicted customers would pay a 20% premium for good security, while 40% said customers want prices to stay flat or decline.[…]

Imperfect Silicon, Near-Perfect Security

Click to access puf-dac07.pdf