Re: https://firmwaresecurity.com/2019/01/07/ltefuzz-a-dynamic-testing-tool-for-lte-network-security/
more info:
https://sites.google.com/view/ltefuzz
Author: hucktech
OpenBMC on PantsDown
[…]Solution: The mitigations are in the 2.6 level of OpenBMC for all supported SPEED-based platforms. The complete solution is platform dependent because it can involve patching both the BMC firmware and the host firmware. For example, disabling the iLPC2AHB bridge can be a bit of a finicky process. The host platform’s operating system may be impacted when the P2A bridge is disabled. The solution may require an updated ASPEED video driver. See Linux commit 71f677a.[…]
Goodbye Gnu-EFI! (using Clang to target UEFI)
David, who did the previous Rust UEFI patch from the previous blog post, has written a blog post about Clang, GNU-EFI, and targetting UEFI:
[…]Voilà! No need for GNU-EFI, no need to mess with separated toolchains. With LLVM you get all this through your local toolchain.[…]
Compiling native UEFI applications in Rust
Intel Trace Hub manual: temporarily available??
Microarchitectural Attacks training at RuhrSec
Training by Ass.Prof. Dr. Daniel Gruss, Moritz Lipp, Michael Schwarz (TU Graz)
With the beginning of 2018, microarchitectural attacks received a lot of attention by the computer security community and other fields. Meltdown and Spectre break isolation between processes and security domains on a hardware level. In this training, we provide a hands-on experience on microarchitectural attacks. Starting with the basics, we first learn how caches work and then implement three very basic microarchitectural side-channel attacks. We start with Flush+Reload and use it to implement two different attacks; one on a cryptographic algorithm and one template attack. We also see how performance counters can reveal interesting information for microarchitectural attacks. After having learned how to mount Flush+Reload attacks on shared libraries, we go one step further and get rid of the requirement of shared memory step by step. For this purpose, we learn how to build eviction sets and implement an Evict+Reload attack. Continuing from there, we implement Prime+Probe, an attack which does not require any shared memory. Finally, we implement a Meltdown and a Spectre attack, based on the Flush+Reload implementation we already have implement in the first third of the course. This course teaches attendees where microarchitectural attack surface is created and how it can be exploited. This provides engineers with valuable knowledge for building more secure hardware and software resilient to these attacks.
Head of Android Security Says Locking Out Law Enforcement Is an ‘Unintended Side Effect’
“The risk for insider attack in the long chain, in the whole ecosystem is—I think—currently bigger than the few cases where legitimate law enforcement access would happen to have to break the chain,”
amonet: a bootrom exploit for MediaTek devices
This is an exploit chain for Fire HD 8 (2018) (8th gen / karnak / KFKAWI). It contains a MediaTek bootrom exploit and a LittleKernel bootloader exploit.
UEFI: GUI UEFI config tool
A new GUI UEFI config tool, written with Python and Qt5: Quoting 100% of the documentation: “This is a GUI for UEFI config”
NSA Lojax guidance incorrectly still says Secure Boot is a mitigation
Re: https://firmwaresecurity.com/2019/01/28/nsa-hardware-and-firmware-security-guidance-updated/
Hmm, the NDA guidance for Lojax appears to be incorrect. It mentions Secure Boot will mitigate, but a comment from Nikolaj Schlej — and I thought also a tweet from Yuriy, but I can’t find that — and later the updated research says it does not. Guess I should submit a Pull Request to NSAcyber…
https://github.com/nsacyber/Hardware-and-Firmware-Security-Guidance
“To mitigate LoJax, ensure that UEFI Secure Boot is enabled and functioning. Standard mode is sufficient. Advanced organizations can also utilize custom mode.”
https://www.welivesecurity.com/2018/09/27/lojax-first-uefi-rootkit-found-wild-courtesy-sednit-group/
“Update, 9 October 2018: The remediation section of the white paper contained inaccurate information. Secure Boot doesn’t protect against the UEFI rootkit described in this research. We advise that you keep your UEFI firmware up-to-date and, if possible, have a processor with a hardware root of trust as is the case with Intel processors supporting Intel Boot Guard (from the Haswell family of Intel processors onwards).”
walk_the_redfish: flatten a Redfish API into a single file
quick and dirty way to flatten a redfish api into a single file
Installing UDK2018 with Clang 7.0 On Fedora 2
FPMurphy has a new blog post on how to configure UDK to use Clang on Linux:
https://blog.fpmurphy.com/2019/01/installing-and-configuring-udk2018-clang-7-0-on-fedora-29.html
Msc_UefiHda_PreOs_Accessibility: UEFI application capable of processing sound
This is the sample code developed during my Msc, where I created a UEFI application capable of processing sound streams at UEFI environment.
https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
see-also:
NSA Hardware and Firmware Security Guidance: updated
Re: https://firmwaresecurity.com/2018/10/17/nsa-cybersecurity-hardware-and-firmware-security-guidance/
First update in over 6 months just happened.
https://github.com/nsacyber/Hardware-and-Firmware-Security-Guidance
Microsoft seeks Director Firmware Development
The Cloud Server Infrastructure Firmware Development (CSI-FW) team is responsible for server hardware definition, design and development of Server and Rack Infrastructure engineering for Microsoft’s online services. We are seeking a Director for our Firmware Development team. In this role it will be your job to help the firmware development team deliver on its product roadmap and strategy. You are also expected to educate and grow the software engineers on your team as well as help teach the engineers across our organization to see the vision you help us create. The candidate should have strong coding skills, debugging and troubleshooting abilities, with experience in leading and driver development in either Linux Kernel or Windows Kernel. The successful candidate should have experience with some or all of the following: firmware development, driver development, Windows OS development, yocto, UEFI, network sockets, platform initialization, Board Support Packages, peripherals interfaces such as PCIe, I2C, eMMC, SPI, USB, UARTs. OS primitives, memory management, scheduling, interrupts requests, threading and synchronization.
https://careers.microsoft.com/us/en/job/577536/Director-Firmware-Development
CVM-EFIvar: efivar to access Cavium ThunderX specific uefi variables
This is a utility derived from github efivar. Added read / write and parsing cavium specific uefi variables to the utility command line, by adding new options. The standard options are still wroking the way it is, even access cavium specific variables.
IL2C – A translator for ECMA-335 CIL/MSIL to C language (including UEFI Shell target)
Interesting, this may help enable porting C# and other .NET IL-based) languages to target UEFI Shell….
IL2C is a translator (transpiler) for ECMA-335 CIL/MSIL to C language.
We’re aiming for:
Better predictability for runtime costs, better human readability for the IL2C translated C source code.
Very tiny footprint requirements, we are thinking about how fit between tiny embedded system and large system with many resources.
Better code/runtime portability, minimum requirements are only C99 compiler.
Better interoperabilities for exist C libraries, we can use standard .NET interop technics (likely P/Invoke.)
Contains seamless building system for major C toolkits, for example: CMake system, Arduino IDE, VC++ …
[…]
“Calculator.UEFI” can execute directly on UEFI platform.
Exactly, this code absolutely contains non-OSes, can boot up from USB flash memory 🙂
It contains platform-dependent glue functions.
Bypass from-to UEFI console service functions.
ConIn, ConOut, OutputString, WaitForEvent, WaitForKey, ReadKeyStroke.
https://github.com/kekyo/IL2C/tree/master/samples/Calculator
Everybody Does It: The Messy Truth About Infiltrating Computer Supply Chains
C Compiler Warnings
Spoiler alert:
[…]All the flags presented so far can be combined into the following list, provided below for copy-pasting purposes :
-Wall -Wextra -Wcast-qual -Wcast-align -Wstrict-aliasing -Wpointer-arith -Winit-self -Wshadow -Wswitch-enum -Wstrict-prototypes -Wmissing-prototypes -Wredundant-decls -Wfloat-equal -Wundef -Wvla -Wdeclaration-after-statement -Wc++-compat
https://fastcompression.blogspot.com/2019/01/compiler-warnings.html
SIMCom: Statistical Sniffing of Inter-Module Communications for Run-time Hardware Trojan Detection
Faiq Khalid, Syed Rafay Hasan, Osman Hasan, Falah Awwad, Muhammad Shafique
Timely detection of Hardware Trojans (HT) has become a major challenge for secure integrated circuits. We present a run-time methodology for HT detection that employs a multi-parameter statistical traffic modeling of the communication channel in a given System-on-Chip (SoC). Towards this, it leverages the Hurst exponent, the standard deviation of the injection distribution and hop distribution jointly to accurately identify HT-based online anomalies. At design time, our methodology employs a property specification language to define and embed assertions in the RTL, specifying the correct communication behavior of a given SoC. At runtime, it monitors the anomalies in the communication behavior by checking the execution patterns against these assertions. We evaluate our methodology for detecting HTs in MC8051 microcontrollers. The experimental results show that with the combined analysis of multiple statistical parameters, our methodology is able to detect all the benchmark Trojans (available on trust-hub) inserted in MC8051, which directly or indirectly affect the communication-channels in SoC.
Firmware Security 
You must be logged in to post a comment.