ESET adds UEFI Scanner

ESET’s internet security just keeps getting better thanks to new IoT protection and UEFI Scanner
October 24, 2017

ESET, a global leader in cybersecurity celebrating 30 years of continuous IT innovation, today launched its latest consumer security product portfolio for Windows. The enhanced solutions are designed to protect people from an expanding array of cyberthreats, data theft, malware and viruses. The features released today enhance the security capabilities of ESET NOD32 Antivirus, ESET Internet Security and ESET Smart Security Premium. The Unified Extensible Firmware Interface (UEFI) Scanner, included in all three products, adds elevated levels of malware protection by detecting and removing threats that potentially launch before the operating system boots up. Threats, including rootkits and ransomware, target vulnerabilities in the UEFI and are highly persistent, even surviving after an operating system is reinstalled. ESET’s UEFI Scanner prevents these types of attacks.[…]

https://www.eset.com/us/about/newsroom/press-releases/esets-internet-security-just-keeps-getting-better-thanks-to-new-iot-protection-and-uefi-scanner/

http://www.businesswire.com/news/home/20171024005379/en/ESET%E2%80%99s-Internet-Security-New-IoT-Protection-UEFI

 

Embedi: UEFI BIOS holes. So much magic. Don’t come inside.

24 October, 2017
UEFI BIOS holes. So Much Magic. Don’t Come Inside.
In recent years, embedded software security has become a red-hot topic, attracting the attention of high profile security researchers from all around the globe. However, the quality of code is still far from perfect as long as its security is considered. For instance, the CVE-2017-5721 SMM Privilege Elevation vulnerability in the firmware could affect such scope of vendors like Acer, ASRock, ASUS, Dell, HP, GIGABYTE, Lenovo, MSI, Intel, and Fujitsu. This white paper is intended to describe how to detect a vulnerability in a motherboard firmware with the help of the following tools: Intel DAL, UEFITool, CHIPSEC, RWEverything, and how to bypass the patch that fixes this vulnerability.[…]

https://embedi.com/blog/uefi-bios-holes-so-much-magic-dont-come-inside

ARM Innovator Program launched

Arm is pleased to announce the launch of the Arm Innovator Program in collaboration with Hackster.io, the leading community dedicated to learning hardware. The Arm Innovator Program is a new initiative to help support the global ecosystem of Arm developers, highlight the impressive work happening around the world based on Arm technology and share key domain knowledge from top technical experts building solutions on Arm with a wider audience. Without further ado, we’re excited to announce the first group of Arm Innovators below; you’ll learn more about them later in the blog:

John Teel, President of Predictable Designs
Laura Kassovic, President and Co-founder of MbientLab
Forrest Iandola, CEO and Founder of DeepScale
Amit Moran, VP of Innovation at temi – the personal robot
Laurent Itti, Computational Neuroscientist, creator of the JeVois
Orlando Hoilett, PHD student and founder of Calvary Engineering
Renee Love, Open-source roboticist
Azeria – Independent Security Researcher, Founder of Azeria Labs
Andrew Dresner, Open-source roboticist
Honggang Li, Co-founder of Maker Collider

 

https://community.arm.com/company/b/blog/posts/introducing-the-arm-innovator-program-in-collaboration-with-hackster-io
https://www.arm.com/innovation/meet-innovators

 

MSI-GT7x-VGA-Switch: toggle Intel/Nvidia VGA from UEFI Shell

MSI-GT7x-VGA-SWITCH: Selects VGA from LINUX or EFI!

These programs or batch scripts will let you swtch the VGA from INTEL to NVIDIA (or the opposite). This is possible at the moment only from Windows (bad choice MSI!). Now it will also be possible from Linux or directly from an EFI SHELL! Intel.nsh and nvidia.nsh are two EFI Shell scripts that can be run directly from EFI shell. Just “make intel” and “make nvidia” to compile the 2 C sources. A reboot is needed afterwards because the VGA is switched by BIOS at boot time.[…]

https://github.com/Zibri/MSI-GT7x-VGA-SWITCH

Microsoft renames VBS

https://twitter.com/aionescu/status/922539069292400640

https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-vbs

It is funny and also sad to see the new MSFT docs include data about how long it’ll take to read the page, for those potential readers who’re worried it’ll be too long to read. “4 minutes to read”. I wonder what the current attention span is, that forces writers to dumb down documents for reduced attention spans of modern readers? 😦

https://blogs.technet.microsoft.com/mmpc/2017/10/23/hardening-the-system-and-maintaining-integrity-with-windows-defender-system-guard/

 

Eclypsium funding news

Congratulations to Eclypsium for getting funded! Here’s some more recent news stories on this:

http://altolawgroup.com/2017/10/06/eclypsium-inc-closes-2-3-million-seed-round-financing/

https://www.nwinnovation.com/eclypsium_finds_funding_from_intel_for_security_software/s-0072416.html

http://www.oregonlive.com/silicon-forest/index.ssf/2017/10/intel_capital_boosts_startup_i.html

Data is the name of the game, as Intel Capital puts $60M in 15 startups, $566M in 2017 overall

 

Why no firmware blob audits?

https://www.reuters.com/article/us-usa-security-kaspersky-russia/kaspersky-lab-to-open-software-to-review-says-nothing-to-hide-idUSKBN1CS0Y1

Recently, Kaspersky has had some trust issues with their OS-present binaries. Now they’re opening up their sources to 3rd party auditors. When I hear this, I wonder why we IT industry doesn’t have something like this in place for ALL criticial closed-source binaries, OS-present as well as firmware binaries. Most firmware binaries by vendors are closed-source, not bothering to audit the firmware yet being concerned about some OS-present software seems like wasted effort. I’d love to see an international group of security researchers, from commercial, academic, and government sectors, who have regular/ongoing audits of the closed-source firmware of Intel/ARM/AMD/etc. as well as all OEMs/ODMs/IHVs. Multiple overlapping audits, with some mechanism — like a WoT — to get aggregated results of each of these audits. All SMM code, any IPMI, Redfish, iLo, etc code, all AMT firmware, the ME sources (the Minix team should be one of the ME source reviewers), Intel FSP, AMD AGESA should be high on the list of audited code. If I have to trust the international vendor supply chain for hardware, I’d like to have some method to better trust the blobs on my system. If there is no open source firmware solution, where I can re-build my blobs from sources that I can audit, then I’d like some third parties to help add trust to the current closed-source blob situation. It is not just free-as-in-Freedom people that care about blobs anymore, it is a base security concern. Given how the military of some countries already ban hardware from other countries, you’d think these governments would have required some firmware auditing procedure like this already. Today, you don’t even get hashes of the blobs from the vendors. No third party audits. Code signing, and trusting a CA is best you can hope for, if at all. The recent downstream issues of Infineon’s TPM firmware, the password issues with Intel AMT, do you think a third party security audit could have helped with those issues?

https://motherboard.vice.com/en_us/article/d3y48v/what-is-a-supply-chain-attack?utm_source=mbtwitter

ARM releases Platform Security Architecture

ARM has announced a Platform Security Architecture.

As well, they’ve announced the ARM CryptoIsland family of TrustZone family.

And they’ve announced the ARM CoreSight SDC-600 Secure Debug Channel, which provides a dedicated path to a debugged system for authenticating debug accesses.

https://www.arm.com/news/2017/10/a-common-industry-framework

https://developer.arm.com/products/architecture/platform-security-architecture

https://community.arm.com/processors/b/blog/posts/platform-security-architecture-scalable-security-for-the-iot

https://developer.arm.com/products/system-ip/trustzone-security-ip/cryptoisland-family

https://developer.arm.com/products/system-ip/coresight-debug-and-trace/coresight-components/coresight-sdc-600-secure-debug-channel

more on Infineon TPM issue

Simple PowerShell script to check whether a computer is using an Infineon TPM chip that is vulnerable to CVE-2017-15361.
https://github.com/lva/Infineon-CVE-2017-15361

Windows tool that analyzes your computer for Infineon TPM weak RSA keys (CVE-2017-15361)
https://github.com/jnpuskar/RocaCmTest

Infineon Embedded Linux TPM Toolbox 2 (ELTT2) for TPM 2.0
https://github.com/Infineon/eltt2

Google response:
https://sites.google.com/a/chromium.org/dev/chromium-os/tpm_firmware_update

Toshiba response:
https://support.toshiba.com/sscontent?contentId=4015874

Lenovo response:
https://support.lenovo.com/us/en/product_security/len-15552

HPE response:
https://support.hp.com/us-en/document/c05792935

gnu-efi-applets

The GNU-EFI-Applets project appears to be about a month old. There are a LOT of UEFI applications ported in this project, including a LISP interpreter. It also includes “efilibc”, another LibC implementation from musl or the EADK libraries. These build with GNU-EFI, not Tianocore/EDK2 build environment.

Name: gnu-efi-applets
Version: 3.0.3
Release: 3
Summary: Building Applets using GNU-EFI

Some missing applets for the EFI system.

Building Environment for building GNU-EFI applets.

Tue Sep 19 2017
Wei-Lun Chao <bluebat@member.fsf.org> – 3.0.3
First release

https://github.com/bluebat/gnu-efi-applets
https://github.com/bluebat/gnu-efi-applets/tree/master/efilibc.applets
https://github.com/bluebat/gnu-efi-applets/tree/master/efilibc

 

Scotch: Combining SGX and SMM to Monitor Cloud Resource Usage

First Online: 12 October 2017
Part of the Lecture Notes in Computer Science book series (LNCS, volume 10453)

The growing reliance on cloud-based services has led to increased focus on cloud security. Cloud providers must deal with concerns from customers about the overall security of their cloud infrastructures. In particular, an increasing number of cloud attacks target resource allocation in cloud environments. For example, vulnerabilities in a hypervisor scheduler can be exploited by attackers to effectively steal CPU time from other benign guests on the same hypervisor. In this paper, we present Scotch, a system for transparent and accurate resource consumption accounting in a hypervisor. By combining x86-based System Management Mode with Intel Software Guard Extensions, we can ensure the integrity of our accounting information, even when the hypervisor has been compromised by an escaped malicious guest. We show that we can account for resources at every task switch and I/O interrupt, giving us richly detailed resource consumption information for each guest running on the hypervisor. We show that using our system incurs small but manageable overhead—roughly 1 μ
s every task switch or I/O interrupt. We further discuss performance improvements that can be made for our proposed system by performing accounting at random intervals. Finally, we discuss the viability of this approach against multiple types of cloud-based resource attacks.

https://link.springer.com/chapter/10.1007/978-3-319-66332-6_18

ChipEasy

Apparently there’s a Windows binary called ChipEasy that helps diagnose USB devices. I can’t find the source code, and am not sure of the official home page. 😦 It appears to be closed source, so take extra care if you dare to risk running freeware these days. Please leave a Comment on this blog post if you can point out a better tool, hopefully something open source.

http://www.upan.cc/tools/test/ChipEasy_EN.html

 

Linux UEFI Validation Project v2.2-rc1 released

Megha Dey of Intel has taken over the role of LUV maintainer, and announced the 2.2-rc1 release. Excerpts of announcement are below, read full announcement for list of bugfixes.

This is to announce the release of LUV v2.2-rc1. Firstly, I would inform all of you that I have taken over the role of maintainer of this project from Ricardo Neri. I would like to thank Ricardo for all the guidance and support he has provided to make this release possible. This release comes approximately 3 months after our last 2.1-rc2 release and we are further working to have releases more frequently. It mostly includes updates to yocto, meta-oe, various test suites and kernel version. We have also added a new test suite called pstore-test which will run the pstore selftests of the kernel and added some tests in kernel-efi-warnings to detect machine check errors. Given that this is the first time I am doing the release, it is possible for some issues to arise, hence it made sense to have this release as rc1 of v2.2 to allow stabilization towards the next release cycle.

We added a new test suite called pstore-test. This test-suite will check the pstore behavior and are useful to avoid regressions of pstore. This test-suite will cause a reboot during its execution. The necessary groundwork to ensure these type of test suites can be integrated seamlessly into LUV has also been included in this release.

Also, Ricardo added some tests in kernel-efi-warnings to detect machine check errors such as system bus errors, parity errors, cache errors and TLB errors. Linux has support to detect this underlying mechanism and report the error in the kernel message buffer.

We include FWTS V17.09.00 Chipsec 1.3.3 and NDCTL v58, the latest versions available as of this week.

The release images for x86 (disk and network) will be available on 10/23/2017.

 

https://01.org/linux-uefi-validation/v2.2 (apparently this URL won’t be valid until 10/23?)

https://01.org/linux-uefi-validation

Full announcement:
https://lists.01.org/mailman/listinfo/luv

OpenPOWER firmware updates using ZMODEM

Stewart Smith of IBM has a new blog post about adding ZMODEM support to OpenPOWER firmware.

From checkin: This enables the use of rz/sz to send/receive files using ZMODEM. This enables error detection and correction when using the console to transfer files to/from the host.

From blog:

ZMODEM saves the day! Or, why my firmware for a machine with a CPU from 2017 contains a serial file transfer protocol from the 1980s

Recently, I added the package lrzsz to op-build in this commit. This package provides the rz and sz commands – for receive zmodem and send zmodem respectively. For those who don’t know, op-build builds a firmware image for OpenPOWER machines, and adding this package adds the commands to the petitboot shell (the busybox environment you get when you “exit to shell” from the boot menu).[…]

ZMODEM saves the day! Or, why my firmware for a machine with a CPU from 2017 contains a serial file transfer protocol from the 1980s


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

 

What’s next, a UEFI runtime service for Kermit, using CKermit? UEFI NNTP Boot, using signed images on alt.binaries.firmware.*? 🙂

more on Infineon TPM issue (ROCA)

http://blog.ptsecurity.com/2017/10/a-major-flaw-in-popular-encryption.html

ROCA: Vulnerable RSA generation (CVE-2017-15361)

A newly discovered vulnerability in generation of RSA keys used by a software library adopted in cryptographic smartcards, security tokens and other secure hardware chips manufactured by Infineon Technologies AG allows for a practical factorization attack, in which the attacker computes the private part of an RSA key. The attack is feasible for commonly used key lengths, including 1024 and 2048 bits, and affects chips manufactured as early as 2012, that are now commonplace. Assess your keys now with the provided offline and online detection tools and contact your vendor if you are affected. Major vendors including Microsoft, Google, HP, Lenovo, Fujitsu already released the software updates and guidelines for a mitigation. Full details including the factorization method will be released in 2 weeks at the ACM CCS conference as ‘The Return of Coppersmith’s Attack: Practical Factorization of Widely Used RSA Moduli’ (ROCA) research paper.

https://crocs.fi.muni.cz/public/papers/rsa_ccs17

 

Where there’s a JTAG, there’s a way: obtaining full system access via USB

WHERE THERE’S A JTAG, THERE’S A WAY: OBTAINING FULL SYSTEM ACCESS VIA USB
Maxim Goryachy and Mark Ermolov
Everyone makes mistakes. These words are certainly true for developers involved in low-level coding, where such common tools as print debugging and software debuggers run into limits. To solve this problem, hardware developers use in-circuit emulators or, if available on the target platform, the JTAG debugging interface (IEEE1149.1 [1]). Such debugging mechanisms first appeared in the 1980s [2]. Over time, microchip vendors extended the functionality of these interfaces. This allowed developers to obtain detailed information on power consumption, find bottlenecks in high-performance algorithms, and perform many other useful tasks. Hardware debugging tools are also of interest to security researchers. These tools grant low-level system access and bypass important security protections, making it easier for researchers to study a platform’s behavior and undocumented features. Unsurprisingly, these abilities have attracted the attention of intelligence services as well.[…]

Click to access Where-theres-a-JTAG-theres-a-way.pdf

 

OpenXT

Linux.com has a nice article on Xen, Linux, TPM, and TXT. It also mentions the OpenXT toolkit.

https://www.linux.com/blog/event/elce/2017/10/device-we-trust-measure-twice-compute-once-xen-linux-tpm-20-and-txt

OpenXT is an open-source development toolkit for hardware-assisted security research and appliance integration. Released as Open-Source Software (OSS) in June 2014, OpenXT stands on the shoulders of Xen Project and OpenEmbedded. It is derived from XenClient XT, which was first released in May 2011. It includes hardened Xen VMs that can be configured as a user-facing virtualization appliance, for client devices with Linux and/or Windows guests. It has been used to develop managed software appliances to isolate demanding graphics workloads, untrusted workloads and multiple networks on a single laptop or desktop. OpenXT is optimized for x86 devices with Intel VT-d, TXT (Trusted Execution Technology) and a TPM. OpenXT is being developed to meet the varied needs of the security and virtualization communities, as a toolkit for the configurable disaggregation of operating systems and user workflows. Client appliances developed on OpenXT can contain a mixture of open-source and proprietary software, supporting a range of business models.[…]

https://openxt.atlassian.net/wiki/spaces/OD/pages/10747915/What+is+OpenXT