http://doc.qt.io/QtForDeviceCreation/qtee-supported-platforms.html#minimum-hardware-requirements
http://blog.qt.io/blog/2018/05/03/qt-microncontrollers-mcu/
PS: I wonder when the Qt project will pick up the UEFI ports done by EFIDroid:
Category: Uncategorized
RouterSploit 3.0 released
[…]Also, RouterSploit will now be maintained by Threat9, which means there will be more resources to improve the tool.[…]
https://www.threat9.com/blog.html
https://github.com/threat9/routersploit
Platform Security Summit
https://twitter.com/platformsec/status/989654674469998592
Platform Security Summit
May 23-24, 2018 · Fairfax, VA
Day 1 topics include:
* Incentives, policy and software ecosystems
* Hypervisor requirements and use cases
* Boot integrity and firmware security
Day 2 topics include:
* Hypervisor-based products
* Operating system boot integrity
* Hypervisor research and development
Open Source Software and the Department of Defense David A. Wheeler
A Model of Agent Authority: Interpretation, Trust, and the Role of Rules Tim Clancy
SecureView Overview Kevin Pearson
Enterprise Scale Separation VMM Systems Myong Kang
TrenchBoot: Unified Approach to Harness Boot Integrity Technologies Daniel Smith
Dell Firmware Security: Past, Present, and Future Justin Johnson
Endpoint Resiliency in an Age of Advanced Persistent Threats Jim Mann
Firmware is the new Software Trammell Hudson
Open-Source Host Firmware Directions Vincent Zimmer
A penny per visit adds up real fast: designing effective defenses against an adversary that makes more money than your entire company does Michael Tiffany
Xen Security Weather Report 2018 Lars Kurth
Crucible: Tailoring Xen to support Critical Systems Ryan Thibodeaux
Introduction to the Bareflank Hypervisor and OpenXT Rian Quinn
XenTT: Deterministic System Analysis in Xen Anton Burtsev
Bear – A Resilient Operating System Stephen Kuhn
Anti-Evil Maid with UEFI and Xen Brendan Kerrigan
TPM 2.0 Software Stack: Usability, Privacy and Security Philip Tricca
STM PE Eugene Myers
Magrana Server John Shackleton
The meta-virtualization Layer of OpenEmbedded Bruce Ashfield
Improving the security of QEMU as a device emulator in Xen Paul Durrant
Installing coreboot on a Lenovo ThinkPad X220
Lenovo LEN-20241: System x Secure Boot Vulnerability
System x Secure Boot Vulnerability
Lenovo Security Advisory: LEN-20241
Potential Impact: Booting unauthenticated code
Severity: High
Scope of Impact: Lenovo-only
CVE Identifier: CVE-2017-3775
Lenovo internal testing discovered some System x server BIOS/UEFI versions that, when Secure Boot mode is enabled by a system administrator, do not properly authenticate signed code before booting it. As a result, an attacker with physical access to the system could boot unsigned code. Lenovo ships these systems with Secure Boot disabled by default, because signed code is relatively new in the data center environment, and standard operator configurations disable signature checking. Apply the BIOS/UEFI update appropriate for your model described in the product impact section below. If you are relying on Secure Boot, you may want to control physical access to systems prior to applying the updates.[…]
https://support.lenovo.com/us/en/solutions/len-20241
Fruct20: UEFI BIOS and Intel ME attack vectors and vulnerabilities
UEFI BIOS and Intel Management Engine Attack Vectors and Vulnerabilities
Alexander Ogolyuk, Andrey Sheglov, Konstantin Sheglov
Saint Petersburg National Research University of Information Technologies, Mechanics and Optics
St. Petersburg, Russia
We describe principles and implementation details of UEFI BIOS attacks and vulnerabilities, suggesting the possible security enhancement approaches. We describe the hidden Intel Management Engine implementation details and possible consequences of its security possible discredit. Described breaches in UEFI and Intel Management Engine could possibly lead to the invention of “invulnerable” malicious applications. We highlight the base principles and actual state of Management Engine (which is a part of UEFI BIOS firmware) and its attack vectors using reverse engineering techniques.
From conclusion:
* Disable all SMM code (if possible by patching or other methods)
* Disable any external firmware components (PCI boot)
* Disable S3 Bootscript (after sleep mode)
* SMI transaction Monitor extensive usage (to find malicious SMI calls)
* Enable Secure Boot mode
* Enable BIOS password
* Extensive reverse engineering of vendor’s firmware samples to find and report vulnerabilities
* Code reviews (of open sourced UEFI based systems like Tiano-Core)
NIST updates 193 to non-draft status
GLitch: a remote Rowhammer exploit on ARM Android devices
What is GLitch?
GLitch is one part of our series of Rowhammer attacks. We started by breaking the EDGE browser and the cloud. Then we moved towards Android devices showing how to root them with bit flips. This time we wanted to show that also mobile phones can be attacked remotely via the browser.
Meet GLitch: the first instance of a remote Rowhammer exploit on ARM Android devices. This makes it possible for an attacker who controls a malicious website to get remote code execution on a smartphone without relying on any software bug.
You want to know what makes this attack even cooler? It is carried out by the GPU. This is the first GPU-accelerated Rowhammer attack.[…]
https://www.vusec.net/projects/glitch/
On the Path to a Secure Boot Solution for RISC-V
On the Path to a Secure Boot Solution for RISC-V
By SecureRF | April 26, 2018 | 0
As the RISC-V ISA gains in popularity and more industries proceed with plans to build and deploy systems based on RISC-V technologies, the security requirements of those systems will grow. One avenue that hackers have used to exploit systems has been to modify the firmware and cause it to misbehave. For example, one of the recent vehicle hacks involved corrupting firmware in order to jump from an infotainment center to the CAN-BUS. The solution to this style of attack is a secure boot, and with minimal additions to the ISA, RISC-V can provide secure boot hooks directly. Secure boot is a self-hosted root of trust that uses a digital signature and a known, trusted, public key to protect the firmware before it loads. The RISC-V system validates the signature over the firmware using the trusted public key and will run the code only if the signature verifies correctly. If the firmware has been modified in any way, the signature validation will fail. Once this initial trusted load completes, subsequent loads can use the same process to chain the trust to additional loads.[…]
Alex Ionescu: Advancing the State of UEFi Bootkids, slides online
Rust-OSdev/ACPI: Library for parsing ACPI tables and AML
A library to parse ACPI tables and AML, written in Rust. Designed to be easy to use from inside a kernel written in Rust, and fully tested. Acpi is currently very early in development, will be highly unstable and is next to useless for actually parsing ACPI or AML.
AMI Adds TPM Support on Arm-based Systems Running Aptio® V UEFI Firmware
AMI has announced support for TPM on Arm®-based systems running AMI’s flagship Aptio® V UEFI Firmware. […] Previously, AMI only provided TPM support for x86 platforms. With the growing need to extend TPM support for additional platforms, AMI has added TPM support for Arm-based systems currently running AMI’s Aptio® V UEFI firmware. The added TPM support for Arm-based systems includes features specifically for the Arm architecture such as TPM driver support within Arm® TrustZone® technology and Linux OS support. The Arm TrustZone TPM Firmware can be accessed by the BIOS and OS via the Command Response Buffer interface using Secure Monitor calls. Other generic features supported by TPM include cryptographic algorithms and measurement of SecureBoot variables.[…]
Building UEFI Applications with Clang and LLD
Re: https://firmwaresecurity.com/2018/04/20/efi-clang-build-uefi-apps-with-clang-and-lld/
There’s a blog post on this toolchain:
[…]Disillusioned (more like repulsed) with Tianocore’s offering, I decided to hold my nose and try the gnu-efi way of doing things. […]
http://yoppeh.com/2018/04/18/building-uefi-applications-with-clang-and-lld/
PS: see latest project by author, new set of EFI headers:
Duo on Apple firmware security (and new EFIgy release)
Nice article on latest Apple changes to firmware security, T2 processor, Secure Boot, etc, are discussed here. Maybe one day Apple will create a similar whitepaper.
more on Spectre/Meltdown
A few new Spectre/Meltdown-related things in the news:
https://twitter.com/daniel_bilar/status/991962885969600513
https://www.heise.de/ct/artikel/Super-GAU-fuer-Intel-Weitere-Spectre-Luecken-im-Anflug-4039134.html
https://www.wired.com/story/rowhammer-remote-android-attack/
https://www.arm.com/products/security-on-arm/security-ip/side-channel-mitigation
Google Asylo: SDK for apps that run in TEEs
https://twitter.com/qrs/status/992109956659863552
[…]Today we’re excited to announce Asylo (Greek for “safe place”), a new open-source framework that makes it easier to protect the confidentiality and integrity of applications and data in a confidential computing environment. Asylo is an open-source framework and SDK for developing applications that run in trusted execution environments (TEEs). TEEs help defend against attacks targeting underlying layers of the stack, including the operating system, hypervisor, drivers, and firmware, by providing specialized execution environments known as “enclaves”. TEEs can also help mitigate the risk of being compromised by a malicious insider or an unauthorized third-party. Asylo includes features and services for encrypting sensitive communications and verifying the integrity of code running in enclaves, which help protect data and applications.[…]
Intel Platform Armoring and Resiliency group seeking senior security researcher
The Platform Armoring and Resiliency SSG/STO/PSI/PAR organization is looking for a senior security researcher. The ideal candidate will be responsible for secure design, development and operation of Intel’s hardware and software products and services. […]
https://jobs.intel.com/ShowJob/Id/1605323/Security%20Researcher
I wonder, is this to fill John’s recently-vacated position? 🙂
VMWare and Microsoft Virtualization Based Security (VBS)
Introducing support for Virtualization Based Security and Credential Guard in vSphere 6.7
Mike Foley
Microsoft virtualization-based security, also known as “VBS”, is a feature of the Windows 10 and Windows Server 2016 operating systems. It uses hardware and software virtualization to enhance Windows system security by creating an isolated, hypervisor-restricted, specialized subsystem. Starting with vSphere 6.7, you can now enable Microsoft (VBS) on supported Windows guest operating systems. You may or may not be familiar with these new Windows features. Based on conversations I have with security teams, you might want to become familiar! What you will hear first and foremost is the requirement for “Credential Guard” which is why I added that to the title. In order to level set the conversation in this blog I will go over the features as they related to a bare metal installation of Windows and then a Windows VM on ESXi.[…]
Apple: set your firmware password
Apple has recently updated this support article, covering firmware password information:
https://support.apple.com/en-us/HT204455
https://support.apple.com/en-us/HT201255
Microsoft: Update your security processor (TPM) firmware
Microsoft has recently updated (or created?, as I’ve never read it before) this document, showing how to update your TPM firmware.
https://support.microsoft.com/en-us/help/4096377/windows-10-update-security-processor-tpm-firmware
Firmware Security 
You must be logged in to post a comment.