Corrode: Rust to C translator

I wish UEFI Forum had bindings to languages other than C, such as Rust, which has multiple community implementations.

I also wish there was a Rust-to-C project for Tianocore. 😉

http://jamey.thesharps.us/2017/04/corrode-update-control-flow-translation.html

 

https://github.com/jameysharp/corrode

Shadow Brokers/Equation Group: EQGRP

https://github.com/x0rz/EQGRP

 

UEFITool updated to A40

I missed this. In mid-February, the ‘new engine’ branch of  UEFITool (and the other command line tools) were updated from A32 to A40.

*  Decoding of JEDEC chip IDs and LZMAF86 sections support added in A33
*  GoToOffset dialog (Ctrl+G) and CPU microcode info added in A35
*  Internal GUID database (override in runtime also possible) added in A40
*  Various bugfixes

https://github.com/LongSoft/UEFITool/tree/new_engine

https://github.com/LongSoft/UEFITool/commits/new_engine

https://github.com/LongSoft/UEFITool/releases

 

Pandavirtualization: Exploiting the Xen hypervisor

Pandavirtualization: Exploiting the Xen hypervisor
Posted by Jann Horn, Project Zero

On 2017-03-14, I reported a bug to Xen’s security team that permits an attacker with control over the kernel of a paravirtualized x86-64 Xen guest to break out of the hypervisor and gain full control over the machine’s physical memory. The Xen Project publicly released an advisory and a patch for this issue 2017-04-04. To demonstrate the impact of the issue, I created an exploit that, when executed in one 64-bit PV guest with root privileges, will execute a shell command as root in all other 64-bit PV guests (including dom0) on the same physical machine.[…]

https://xenbits.xen.org/xsa/advisory-212.html

https://bugs.chromium.org/p/project-zero/issues/detail?id=1184

https://googleprojectzero.blogspot.com/2017/04/pandavirtualization-exploiting-xen.html

 

 

Tactical Network Solutions unveils firmware evaluation services

https://twitter.com/IoTSecurity/status/850741842803032064

[…]On April 3, 2017, Tactical Network Solutions (TNS) officially unveiled its firmware evaluation services to its clients and prospects. TNS seeks to assist as many companies as possible in order to secure as many devices as possible. They believe that true IoT security can be a reality for developers and manufacturers. The evaluation services are priced at an initial, introductory rate to allow companies to take advantage of the service.[…]

http://www.pr.com/press-release/711824

https://www.tacnetsol.com/

MBR2GPT

“MBR2GPT.EXE converts a disk from Master Boot Record (MBR) to GUID Partition Table (GPT) partition style without modifying or deleting data on the disk. The tool is designed to be run from a Windows Preinstallation Environment (Windows PE) command prompt, but can also be run from the full Windows 10 operating system (OS).[…]”

https://technet.microsoft.com/itpro/windows/deploy/mbr-to-gpt

https://blogs.technet.microsoft.com/windowsitpro/2017/04/05/whats-new-for-it-pros-in-the-windows-10-creators-update/

https://redmondmag.com/articles/2017/04/07/windows-10-creators-update-tools-and-documentation-released.aspx

 

Google: exploiting Broadcom’s Wi-Fi

Google ProjectZero has an excellent blog post on Broadcom WiFi firmware.

[…]In this two-part blog series, we’ll explore the exposed attack surface introduced by Broadcom’s Wi-Fi SoC on mobile devices. Specifically, we’ll focus our attention on devices running Android, although a vast amount of this research applies to other systems including the same Wi-Fi SoCs. The first blog post will focus on exploring the Wi-Fi SoC itself; we’ll discover and exploit vulnerabilities which will allow us to remotely gain code execution on the chip. In the second blog post, we’ll further elevate our privileges from the SoC into the the operating system’s kernel. Chaining the two together, we’ll demonstrate full device takeover by Wi-Fi proximity alone, requiring no user interaction. We’ll focus on Broadcom’s Wi-Fi SoCs since they are the most common Wi-Fi chipset used on mobile devices. A partial list of devices which make use of this platform includes the Nexus 5, 6 and 6P, most Samsung flagship devices, and all iPhones since the iPhone 4. For the purpose of this blog post, we’ll demonstrate a Wi-Fi remote code execution exploit on a fully updated (at the time, now fixed) Nexus 6P, running Android 7.1.1 version NUF26K.  All the vulnerabilities in the post have been disclosed to Broadcom. Broadcom has been incredibly responsive and helpful, both in fixing the vulnerabilities and making the fixes available to affected vendors. For a complete timeline, see the bug tracker entries. They’ve also been very open to discussions relating to the security of the Wi-Fi SoC. I would like to thank Thomas Dullien (@halvarflake) for helping boot up the research, for the productive brainstorming, and for helping search the literature for any relevant clues. I’d also like to thank my colleagues in the London office for helping make sense of the exploitation constraints, and for listening to my ramblings. […]

https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcoms-wi-fi_4.html

https://bugs.chromium.org/p/project-zero/issues/detail?id=1046#c2

http://www.wi-fi.org/product-finder-results?sort_by=default&sort_order=desc&categories=1,2,4,6,7,5,9,3&certifications=38

https://news.ycombinator.com/item?id=14034092

https://arstechnica.com/security/2017/04/wide-range-of-android-phones-vulnerable-to-device-hijacks-over-wi-fi/

I do not look forward to the day that most Redfish implementations are WiFi-based. 😦

Dmytro’s Rogue PCI-E device

Wow.

 

https://www.dropbox.com/s/yxgw0bl241hkt3n/pcie_dxe_backdoor_tlp.log?dl=0

U-Boot gets NVMe support

Zhikang Zhang of NXP added NVMe driver support to U-Boot.

Add Support of devices that follow the NVM Express standard

 Basic functions:
    nvme init/scan
    nvme info – show the basic information of device
    nvme Read/Write

 Driver model:
    Use block device(CONFIG_BLK)’s structure to support nvme’s DM.
    Use UCLASS_PCI as a parent uclass.

The driver code heavily copy from the NVMe driver code in Linux Kernel.

Add nvme commands in U-Boot command line.

1. “nvme list” – show all available NVMe blk devices
2. “nvme info” – show current or a specific NVMe blk device
3. “nvme device” – show or set current device
4. “nvme part” – print partition table
5. “nvme read” – read data from NVMe blk device
6. “nvme write” – write data to NVMe blk device

More info: U-Boot mailing list.

Linux Kernel: exclude EFI from KASLR VA space randomization

Greg Kroah-Hartman of the Linux Foundation submitted version 4.10 of a 81-part(!) patch to the Linux kernel by Baoquan He of Red Hat.

[PATCH 4.10 65/81] x86/mm/KASLR: Exclude EFI region from KASLR VA space randomization

4.10-stable review patch.  If anyone has any objections, please let me know.

commit a46f60d76004965e5669dbf3fc21ef3bc3632eb4 upstream.

Currently KASLR is enabled on three regions: the direct mapping of physical memory, vamlloc and vmemmap. However the EFI region is also mistakenly included for VA space randomization because of misusing EFI_VA_START macro and assuming EFI_VA_START < EFI_VA_END. (This breaks kexec and possibly other things that rely on stable addresses.) The EFI region is reserved for EFI runtime services virtual mapping which should not be included in KASLR ranges. In Documentation/x86/x86_64/mm.txt, we can see:

        ffffffef00000000 – fffffffeffffffff (=64 GB) EFI region mapping space

EFI uses the space from -4G to -64G thus EFI_VA_START > EFI_VA_END, Here EFI_VA_START = -4G, and EFI_VA_END = -64G. Changing EFI_VA_START to EFI_VA_END in mm/kaslr.c fixes this problem.

More info: see the linux-efi/linux-kernel list.

Linux Kernel lockdown

David Howells of Red Hat has posted a 24-part patch to the Linux-(Kernel,EFI) lists, which hardens Linux from some firmware attacks.

These patches provide a facility by which a variety of avenues by which userspace can feasibly modify the running kernel image can be locked down. These include:
 (*) No unsigned modules and no modules for which can’t validate the signature.
 (*) No use of ioperm(), iopl() and no writing to /dev/port.
 (*) No writing to /dev/mem or /dev/kmem.
 (*) No hibernation.
 (*) Restrict PCI BAR access.
 (*) Restrict MSR access.
 (*) No kexec_load().
 (*) Certain ACPI restrictions.
 (*) Restrict debugfs interface to ASUS WMI.

The lock-down can be configured to be triggered by the EFI secure boot status, provided the shim isn’t insecure.  The lock-down can be lifted by typing SysRq+x on a keyboard attached to the system.[…]

See the full patch for more info:

http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=efi-lockdown
http://vger.kernel.org/majordomo-info.html

SyScan360 Seattle

https://www.syscan360.org/