Jakob Engblom of Intel has 2 blog posts that talk about how modern operating systems use new Intel instructions.
https://software.intel.com/en-us/blogs/2017/10/17/does-software-actually-use-new-instruction-sets


Jakob Engblom of Intel has 2 blog posts that talk about how modern operating systems use new Intel instructions.
https://software.intel.com/en-us/blogs/2017/10/17/does-software-actually-use-new-instruction-sets


Re: https://firmwaresecurity.com/2016/11/04/uefi-bootkit/
Aidan Khoury of Quarkslab has updated UEFI-Bootkit. Only change to the project in the last year was update to readme, with more info. It is worth reading the USRT review of this bootkit, in the above URL.
https://github.com/dude719/UEFI-Bootkit
UEFI-Bootkit: A small bootkit designed to use zero assembly. Make sure to compile the driver as an EFI Runtime driver (EFI_RUNTIME_DRIVER) or else the bootkit will be freed once winload.efi calls ExitBootServices! Thanks to pyro666, dreamboot, and VisualUEFI.
New in this release:
* Initial support for NVME drives
* Support for vga emulation over a serial port in SeaBIOS (sercon)
* Support for serial debugging using MMIO based serial ports
* Support for scsi devices with multiple LUNs
* Support for boot-to-boot persistent coreboot cbmem logs
* Improved coreboot vga (cbvga) mode setting compatibility
* Several bug fixes and code cleanups
For full announcement, see Kevin O’Connor’s posting to the SeaBIOS list.
http://seabios.org/Releases
http://seabios.org/Download
https://mail.coreboot.org/mailman/listinfo/seabios
As WiFi/NFC/Bluetooth become part of a modern firmware stack, AMI has a blog post on bluetooth security issues:
https://ami.com/en/tech-blog/a-bad-case-of-bluebug-mitigating-risks-of-bluetooth-attacks/
https://twitter.com/revskills/status/928382801400991744
afl-unicorn let’s you fuzz any piece of binary that can be emulated by Unicorn Engine.
https://github.com/njv299/afl-unicorn
http://www.unicorn-engine.org/
https://hackernoon.com/afl-unicorn-fuzzing-arbitrary-binary-code-563ca28936bf
[…]Unicorn Mode works by implementing the block-edge instrumentation that AFL’s QEMU Mode normally does into Unicorn Engine. Basically, AFL will use block coverage information from any emulated code snippet to drive its input generation. The whole idea revolves around proper construction of a Unicorn-based test harness, as shown in the figure below:

Ian Nelson Santopietro of System76 has a project called Kernelstub. It has moved from Launchpad to Github. Apparently there is work underway for a 2.0 release, with some reworked config file handling.
[…]Today, we’re also introducing Project Cerberus, which provides a critical component for security protection that to date has been missing from server hardware – protection, detection and recovery from attacks on platform firmware.[…] Project Cerberus is a NIST 800-193 compliant hardware root of trust specifically designed to provide robust security for all platform firmware. It provides a hardware root of trust for firmware on the motherboard (UEFI BIOS, BMC, Options ROMs) as well as on peripheral I/O devices by enforcing strict access control and integrity verification from pre-boot and continuing to runtime.[…]
Microsoft’s Project Olympus delivers cloud hardware innovation at scale
https://github.com/opencomputeproject/Project_Olympus
Very excited to see NIST SP 800-193-compliance mentioned!!
https://csrc.nist.gov/publications/detail/sp/800-193/draft
Vulnerability Note VU#739007
IEEE P1735 implementations may have weak cryptographic protections
Date: 03 Nov 2017
The P1735 IEEE standard describes methods for encrypting electronic-design intellectual property (IP), as well as the management of access rights for such IP. The methods are flawed and, in the most egregious cases, enable attack vectors that allow recovery of the entire underlying plaintext IP. Implementations of IEEE P1735 may be weak to cryptographic attacks that allow an attacker to obtain plaintext intellectual property without the key, among other impacts. The P1735 IEEE standard describes methods for encrypting electronic-design intellectual property (IP), as well as the management of access rights for such IP. The methods are flawed and, in the most egregious cases, enable attack vectors that allow recovery of the entire underlying plaintext IP. Some of these attack vectors are well-known, such as padding-oracle attacks. Others are new, and are made possible by the need to support the typical uses of the underlying IP. In particular, the need for commercial electronic design automation (EDA) tools to synthesize multiple pieces of IP into a fully specified chip design and to provide HDL syntax errors. These flaws can be exploited by leveraging the commercial EDA tool as a black-box oracle. In addition to being able to recover entire plaintext IP, one can produce standard-compliant ciphertexts of IP that have been modified to include targeted hardware Trojans. An adversary can recover electronic design IPs encrypted using the P1735 workflow, resulting in IP theft and/or analysis of security critical features, as well as the ability to insert hardware trojans into an encrypted IP without the knowledge of the IP owner. Impacts may include loss of profit and reputation of the IP owners as well as integrated circuits (ICs) with trojans that contain backdoors, perform poorly, or even fail completely. See the researcher’s paper for full impact details.[...]
https://www.kb.cert.org/vuls/id/739007
Standardizing Bad Cryptographic Practice
A teardown of the IEEE P1735 standard for protecting electronic-design intellectual property
Animesh Chhotaray, Adib Nahiyan, Thomas Shrimpton, Domenic Forte, Mark Tehranipoor
We provide an analysis of IEEE standard P1735, which describes methods for encrypting electronic-design intellectual property (IP), as well as the management of access rights for such IP. We find a surprising number of cryptographic mistakes in the standard. In the most egregious cases, these mistakes enable attack vectors that allow us to recover the entire underlying plaintext IP. Some of these attack vectors are well-known, e.g. padding-oracle attacks. Others are new, and are made possible by the need to support the typical uses of the underlying IP; in particular, the need for commercial system-on-chip (SoC) tools to synthesize multiple pieces of IP into a fully specified chip design and to provide syntax errors. We exploit these mistakes in a variety of ways, leveraging a commercial SoC tool as a black-box oracle. In addition to being able to recover entire plaintext IP, we show how to produce standard-compliant ciphertexts of IP that have been modified to include targeted hardware Trojans. For example, IP that correctly implements the AES block cipher on all but one (arbitrary) plaintext that induces the block cipher to return the secret key. We outline a number of other attacks that the standard allows, including on the cryptographic mechanism for IP licensing. Unfortunately, we show that obvious “quick fixes” to the standard (and the tools that support it) do not stop all of our attacks. This suggests that the standard requires a significant overhaul, and that IP-authors using P1735 encryption should consider themselves at risk.
http://ieeexplore.ieee.org/document/7274481/
https://standards.ieee.org/findstds/standard/1735-2014.html
It is amazing to see the Intel ME research coming out of Positive Technologies!
From Google Translate:
JTAG in each house: full access via USB
Researchers at Positive Technologies have activated hardware debugging (JTAG) for Intel Management Engine, which allows full access to all PCH devices (Platform Controller Hub) using Intel DCI technology (via USB interface). We plan to share the details at one of the nearest conferences. And how to activate this interface, but for the main processor, we will tell below.[…]
https://habrahabr.ru/company/pt/blog/341946/
https://translate.google.com/translate?hl=en&sl=ru&u=https://habrahabr.ru/company/pt/blog/341946/
Intel ME is the new “Pandora’s Box”, defenders are going to need bigger (better) tools… 😦
Hardware and firmware attacks: defending, detecting, and responding
Ted Reed, Facebook
The attack landscape for firmware is maturing and needs more attention from defense and detection communities.[…]
https://code.facebook.com/posts/182707188759117
https://twitter.com/steffenbauch/status/928076864060608512?s=09
Intel ME running Minix is in the news again…
An Open Letter to Intel
[…]I knew that Intel had some potential interest in MINIX 3 several years ago when one of your engineering teams contacted me about some secret internal project and asked a large number of technical questions about MINIX 3, which I was happy to answer. I got another clue when your engineers began asking me to make a number of changes to MINIX 3, for example, making the memory footprint smaller and adding #ifdefs around pieces of code so they could be statically disabled by setting flags in the main configuration file.[…]
Yours truly,
Andrew S. Tanenbaum
http://www.cs.vu.nl/~ast/intel/
https://en.wikipedia.org/wiki/Andrew_S._Tanenbaum
Time Travel Debugging is now available in WinDbg Preview
We are excited to announce that Time Travel Debugging (TTD) features are now available in the latest version of WinDbg Preview. About a month ago, we released WinDbg Preview which provides great new debugging user experiences. We are now publicly launching a preview version of TTD for the first time and are looking forward to your feedback.[…]
https://blogs.msdn.microsoft.com/windbg/2017/09/25/time-travel-debugging-in-windbg-preview/
As I hear, TTD has been used at Microsoft internally for years, just now getting this feature out to the public. Though they are not identical in implementation, GDB has had reverse execution for a while.
https://www.gnu.org/software/gdb/news/reversible.html
https://sourceware.org/gdb/onlinedocs/gdb/Reverse-Execution.html
https://sourceware.org/gdb/wiki/ReverseDebug
PCILeech FPGA contains software and HDL code for FPGA based devices that may be used together with the PCILeech Direct Memory Access (DMA) Attack Toolkit. Using FPGA based devices have many advantages over using the USB3380 hardware that have traditionally been supported by PCILeech. FPGA based hardware provides full access to 64-bit memory space without having to rely on a kernel module running on the target system. FPGA based devices are also more stable compared to the USB3380. FPGA based devices may also send raw PCIe Transaction Layer Packets TLPs – allowing for more specialized research.
https://github.com/ufrisk/pcileech-fpga
https://github.com/ufrisk/pcileech/
The current plugfest ended a few days ago. The UEFI Forum has announced the next plugfest will be in Seattle next Spring:
Spring 2018 UEFI Plugfest
Mar. 26-30, 2018
Embassy Suites by Hilton Seattle Bellevue, 3225 158th Ave SE, Bellevue, WA 98008
Trammell Hudson tests Apple macOS’s eficheck against Thunderstrike2:
https://twitter.com/qrs/status/927565241449410560
https://twitter.com/qrs/status/927599689515626496
https://trmm.net/Thunderstrike
https://trmm.net/Thunderstrike_2
https://support.apple.com/en-us/HT207475

Automated Detection, Exploitation, and Elimination of Double-Fetch Bugs using Modern CPU Features
Michael Schwarz, Daniel Gruss, Moritz Lipp, Clémentine Maurice, Thomas Schuster, Anders Fogh, Stefan Mangard
(Submitted on 3 Nov 2017)
Double-fetch bugs are a special type of race condition, where an unprivileged execution thread is able to change a memory location between the time-of-check and time-of-use of a privileged execution thread. If an unprivileged attacker changes the value at the right time, the privileged operation becomes inconsistent, leading to a change in control flow, and thus an escalation of privileges for the attacker. More severely, such double-fetch bugs can be introduced by the compiler, entirely invisible on the source-code level. We propose novel techniques to efficiently detect, exploit, and eliminate double-fetch bugs. We demonstrate the first combination of state-of-the-art cache attacks with kernel-fuzzing techniques to allow fully automated identification of double fetches. We demonstrate the first fully automated reliable detection and exploitation of double-fetch bugs, making manual analysis as in previous work superfluous. We show that cache-based triggers outperform state-of-the-art exploitation techniques significantly, leading to an exploitation success rate of up to 97%. Our modified fuzzer automatically detects double fetches and automatically narrows down this candidate set for double-fetch bugs to the exploitable ones. We present the first generic technique based on hardware transactional memory, to eliminate double-fetch bugs in a fully automated and transparent manner. We extend defensive programming techniques by retrofitting arbitrary code with automated double-fetch prevention, both in trusted execution environments as well as in syscalls, with a performance overhead below 1%.
Dynamic FPGA Detection and Protection of Hardware Trojan: A Comparative Analysis
Amr Alanwar, Mona A. Aboelnaga, Yousra Alkabani, M. Watheq El-Kharashi, Hassan Bedour
(Submitted on 3 Nov 2017)
Hardware Trojan detection and protection is becoming more crucial as more untrusted third parties manufacture many parts of critical systems nowadays. The most common way to detect hardware Trojans is comparing the untrusted design with a golden (trusted) one. However, third-party intellectual properties (IPs) are black boxes with no golden IPs to trust. So, previous attempts to detect hardware Trojans will not work with third-party IPs. In this work, we present novel methods for Trojan protection and detection on field programmable gate arrays (FPGAs) without the need for golden chips. Presented methods work at runtime instead of test time. We provide a wide spectrum of Trojan detection and protection methods. While the simplest methods have low overhead and provide limited protection mechanisms, more sophisticated and costly techniques are introduced that can detect hardware Trojans and even clean up the system from infected IPs. Moreover, we study the cost of using the FPGA partial reconfiguration feature to get rid of infected IPs. In addition, we discuss the possibility to construct IP core certificate authority that maintains a centralized database of unsafe vendors and IPs. We show the practicality of the introduced schemes by implementing the different methodologies on FPGAs. Results show that simple methods present negligible overheads and as we try to increase security the delay and power overheads increase.
https://arxiv.org/abs/1711.01010
Follow Arrigo on Twitter, for many more posts to related academic documents, a great resource.
Standards for a highly secure Windows 10 device
11/05/2017
These standards are for general purpose desktops, laptops, tablets, 2-in-1’s, mobile workstations, and desktops. This topic applies specifically and uniquely for Windows 10 version 1709, Fall Creators Update. Windows enterprise security features light up when you meet or exceed these standards and your device is able to provide a highly secure experience.[…]
https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-highly-secure
It will actually take more than 2 minutes to read this …properly.
NE Alpha 44:
+ support of MS Surface implementation of Intel Boot Guard
+ optional disabling Intel Boot Guard marking
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Discover the Desktop
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
News from coreboot world
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Just another WordPress.com site
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
You must be logged in to post a comment.