#PCIExpress 5.0, #PCISIG’s newest specification, is now available to members. #PCIe 5.0 doubles the bandwidth of PCIe 4.0 and increases performance in a variety of high performance markets. Read the press release to discover the features of PCIe 5.0: https://t.co/fQ2z1tHlww pic.twitter.com/y7GfOzeBhl

— PCI-SIG (@pci_sig) May 29, 2019

PCIe 5.0 Specification Highlights:

• Delivers 32 GT/s raw bit rate and up to 128 GB/s via x16 configuration
• Leverages and adds to the PCIe 4.0 specification and its support for higher speeds via extended tags and credits
• Implements electrical changes to improve signal integrity and mechanical performance of connectors
• Includes new backwards compatible CEM connector targeted for add-in cards
• Maintains backwards compatibility with PCIe 4.0, 3.x, 2.x and 1.x

https://www.businesswire.com/news/home/20190529005766/en/PCI-SIG%C2%AE-Achieves-32GTs-New-PCI-Express%C2%AE-5.0

https://pcisig.com/specifications

I published a (rather badly written) post about reverse engineering and emulating Samsung bootloader and their new TrustZone OS known as TEEGRIS.https://t.co/rkqYudtHUd

(this might get slightly updated in future)

— Alexander Tarasikov (@astarasikov) May 29, 2019

http://allsoftwaresucks.blogspot.com/2019/05/reverse-engineering-samsung-exynos-9820.html

SpecFuzz is the first tool that enables dynamic testing for speculative execution vulnerabilities (e.g., Spectre). The key is the concept of speculation exposure: The program is instrumented to simulate speculative execution in software by forcefully executing the code paths that could be triggered due to mispredictions, thereby making the speculative memory accesses visible to integrity checkers. Combined with the conventional fuzzing techniques, speculation exposure enables more precise identification of potential vulnerabilities compared to the state-of-the-art static analyzers. Our prototype for detecting Spectre V1 vulnerabilities successfully identifies all known variations of Spectre V1, and dramatically reduces the overheads compared to the deployed Speculative Load Hardening mitigation across the evaluated applications, reducing the amount of necessary instrumentation by 99% in some of them.

https://arxiv.org/abs/1905.10311

.

Our speculative symbolic execution tool Pitchfork is now public! https://t.co/abxbDzTwRJ

Pitchfork symbolically executes not only the "correct" or "sequential" paths of a program, but also the "mispredicted" or "speculative" paths. 👇

— Craig Disselkoen (@craigdissel) May 29, 2019

Pitchfork is a static analysis tool, built on angr, which performs speculative symbolic execution. That is, it not only executes the “correct” or “sequential” paths of a program, but also the “mispredicted” or “speculative” paths, subject to some speculation window size. Pitchfork finds paths where secret data is used in either address calculations or branch conditions (and thus leaked), even speculatively – these paths represent Spectre vulnerabilities. Pitchfork covers Spectre v1, Spectre v1.1, and theoretically Spectre v4 (the code for v4 is here, but hasn’t been tested).

https://github.com/cdisselkoen/pitchfork

Linux kernel v5.0 was released last week! I'm excited about arm64's read-only linear mapping, per-task stack canaries for arm and arm64, top-byte-ignore on arm64, the ongoing marking of implicit-fallthroughs, and the continuing conversions to refcount_t https://t.co/Lr7mPfvUY5

— Kees Cook (@kees_cook) March 12, 2019

PSPTool is a Swiss Army knife for dealing with firmware of the AMD Secure Processor (formerly known as Platform Security Processor or PSP). It locates AMD firmware inside UEFI images as part of BIOS updates targeting AMD platforms. It is based on reverse-engineering efforts of AMD’s proprietary filesystem used to pack firmware blobs into UEFI Firmware Images. These are usually 16MB in size and can be conveniently parsed by UEFITool. However, all binary blobs by AMD are located in padding volumes unparsable by UEFITool. PSPTool favourably works with UEFI images as obtained through BIOS updates.

https://github.com/cwerling/psptool

We just published the slides for the TEE presentation @esanfelix gave at #zer0con2019 and #infiltrate19, and kicking off part 1/4 of a blog post series about this research. https://t.co/enaSbpbgSw

— Blue Frost Security (@bluefrostsec) May 27, 2019

By: Sujit Kumar Muduli Pramod Subramanyan, Sayak Ray

An important primitive in ensuring security of modern systems-on-chip designs are protocols for authenticated firmware load. These loaders read a firmware binary image from an untrusted input device, authenticate the image using cryptography and load the image into memory for execution if authentication succeeds. While these protocols are an essential part of the hardware root of trust in almost all modern computing devices, verification techniques for reasoning about end-to-end security of these protocols do not exist. In this paper, we take a step toward addressing this gap by introducing a system model, adversary model and end-to-end security property that enable reasoning about the security of authenticated load protocols. We then present a decomposition of the security property into two simpler hyperproperties. This decomposition enables more scalable verification. Experiments on a protocol model demonstrate viability of the methodology.

Click to access 564.pdf

A new C-based library for interacting with Huawei BMC via Redfish:

https://github.com/IamFive/huawei-utool

First Published: 2019 May 13 17:30 GMT
Last Updated: 2019 May 16 20:00 GMT
Workarounds: No workarounds available

A vulnerability in the logic that handles access control to one of the hardware components in Cisco’s proprietary Secure Boot implementation could allow an authenticated, local attacker to write a modified firmware image to the component. This vulnerability affects multiple Cisco products that support hardware-based Secure Boot functionality. The vulnerability is due to an improper check on the area of code that manages on-premise updates to a Field Programmable Gate Array (FPGA) part of the Secure Boot hardware implementation. An attacker with elevated privileges and access to the underlying operating system that is running on the affected device could exploit this vulnerability by writing a modified firmware image to the FPGA. A successful exploit could either cause the device to become unusable (and require a hardware replacement) or allow tampering with the Secure Boot verification process, which under some circumstances may allow the attacker to install and boot a malicious software image. This advisory will be updated as additional information becomes available. Cisco will release software updates that address this vulnerability. There are no workarounds that address this vulnerability.

https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190513-secureboot

I believe the author, Lorenzo Gaggini, works at Dell:

dell_hw_health is a python script / nagios check using Redfish API to get system hardware health

https://github.com/lgaggini/dell_hw_health

https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html

https://software.intel.com/security-software-guidance/insights/deep-dive-intel-analysis-microarchitectural-data-sampling

https://software.intel.com/security-software-guidance/software-guidance/microarchitectural-data-sampling

https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/adv190013/adv190013

https://access.redhat.com/security/vulnerabilities/mds

https://blog.ubuntu.com/2019/05/14/ubuntu-updates-to-mitigate-new-microarchitectural-data-sampling-mds-vulnerabilities

https://support.apple.com/en-us/HT210107

https://blogs.oracle.com/security/intelmds

https://docs.cloud.oracle.com/iaas/Content/Security/Reference/MDS_response.htm

https://en.wikipedia.org/wiki/Microarchitectural_Data_Sampling

MDS Tool: find out if you are vulnerable to Microarchitectural Data Sampling Attacks (MDS)