Category: Uncategorized

Duo on ChromeOS Verified Access API

~ hucktech ~ Leave a comment

https://twitter.com/jonoberheide/status/776522542773338112

Duo Collaborates With Google to Provide Verified Access for Chrome OS

[…]
Ensuring Trusted Access with Google’s Verified Access API
For the past few months, we’ve worked with Google on testing early versions of the Chrome OS Verified Access API, which is now publicly available and configurable in the Google Apps Admin Panel. Verified Access is a new API that allows Chromebooks to cryptographically attest to the state of certain security properties of the device to a third party – in our case, that third party is actually Duo’s service – for the purposes of making decisions around activities like access control. We use this to reliably assess the security posture of Chromebooks at Duo before they are allowed to access particularly sensitive resources. What does the attestation protocol actually tell us? According to the source code:[…]

https://duo.com/blog/duo-collaborates-with-google-to-provide-verified-access-for-chromeos
http://googleforwork.blogspot.com/2016/09/pushing-the-boundary-of-Chrome-OS-Security-with-Verified-Access.html

coreboot now supports Ada

~ hucktech ~ Leave a comment

Ihttp://spark-2014.org/

https://review.coreboot.org/#/c/11836/

https://review.coreboot.org/#/c/11869/

“Add minimal GNAT run time system (RTS)
Add a stripped-down version of libgnat. This is somehow comparable to libgcc but for Ada programs. It’s licensed under GPLv3 but with the runtime library exception. So it’s totally fine to link it with our GPLv2 code and keep it under GPLv2.”

WIP: SPARK: Add driver for Intel GMA initialization
This is derived from an experimental branch, which was started to support Haswell. It supports many processors in the Core architecture line starting with the Ironlake graphics (found first in Nehalem). But I had to strip off the FDI (connection between processor and chipset) configuration during refactoring, so not everything is working again yet. Also, after the refactoring, I started to work with SPARK 2014. While the code is SPARK 2014 compliant, it’s pretty much unannotated. Absence of runtime errors is automatically provable (with one exception), though. What currently should work: Virtually everything but VGA on Haswell and Broadwell. eDP on Ivy Bridge (maybe Sandy Bridge and Nehalem, too, but untested). Other connectors would need FDI configuration on these older processors. Integration is most WIP: Configuration is static and hardcoded currently (see HW.GFX.GMA.Config). There is one package with an interface to C (HW.GFX.GMA.Coreboot) that’s hardcoded to bring up an eDP on Ivy Bridge. There’s another interface in HW.GFX.GMA: Update_Outputs() which supports two different, runtime selectable outputs[…]

Senrio’s IoT firmware security checklist

~ hucktech ~ Leave a comment

Senrio has a blog post with a list of firmware security tips for IoT devices:

http://blog.senr.io/blog/5-tips-for-better-iot-and-firmware-security

5 Tips for Better IoT and Firmware Security

In this new wold of “the Internet of Things” and billions of networked embedded devices,  it is crucial for device manufacturers to bake security into their new designs before they leave the factory. Here are five tips from a team of security researchers who make a living reverse engineering (hacking) into IoT devices on behalf of industry clients.  […]

ORWL on Joanna’s security comments

~ hucktech ~ Leave a comment

ORWL has a response to Joanna’s comments on ORWL security:

 

“Recently, Joanna Rutkowska, the founder of Qubes OS (which we announced as a default OS option), posted on her Invisible Things blog and on Twitter some of her thoughts on ORWL. We offer here our comments and responses to specific points, as well as a more general response. Some of what is described in this update is laid out in our previous update on secure microcontroller (MCU) details.[…]”

https://www.crowdsupply.com/design-shift/orwl/updates/invisible-things

ORWL funded!

Lindholm on UEFI driver development

~ hucktech ~ Leave a comment

Leif Lindholm has a new blog post, which appears to be the first in a series, on UEFi development. As most UEFI-centric blog posts are often Intel-centric, I’m looking forward to seeing some ARM-centric UEFI topics!

UEFI Driver Development – Part 1

One of the key features of UEFI is that the specification and the APIs/ABIs it guarantees provides the ability to produce portable applications, drivers and libraries (in the form of protocols). On the simpler side, by letting you compile the driver once for each architecture – and on the more space age side by letting you build a single driver that works across all architectures (using EFI Byte Code). The extra magic comes in the form of Option ROM support, which lets plug-in PCI cards keep a driver onboard, informing UEFI to load it on boot. (Any jokes about Forth drivers for Open Firmware go here.) So, having never actually written a UEFI driver from scratch, and most of the drivers I have come across having really been platform drivers, I figured that would be a good start to write a standalone driver from scratch. And the outcome is this slightly hands-on blog post series. This part covers:

* creating a new driver from scratch
* building it as a standalone driver
* loading it from the UEFI Shell
* having it detect the presence of a device it recognizes
* unloading it from the UEFI Shell

[…]

http://blog.eciton.net/uefi/uefi-driver-part1.html

UEFI EDK2 FDF V1.27 draft spec available

~ hucktech ~ Leave a comment

Laurie Jarlstrom of Intel announced the latest UEFI FDF spec: V1.27 Draft for Review.

“Please Review By EOW”.

I think I already saw an issue show up on the public EDK2 bug database.

EDK II FDF File Spec v1.27 DRAFT for Review
Update Sept 2016 (DRAFT)
This document describes the EDK II Flash Description (FDF) file format. This format was designed to support new build requirements of building EDK and EDK II modules within the EDK II build infrastructure. The EDK II Build Infrastructure supports generation of current Unified EFI, Inc. (UEFI 2.6 and PI 1.4) compliant binary images. The FDF file is used to describe the content and layout of binary images. Binary images described in this file may be any combination of boot images, capsule images or PCI Options ROMs.

https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Specifications

Click to access FDF_Spec_1_27_Review_Draft.pdf

ARM big.LITTLE and cache flushing

~ hucktech ~ Leave a comment

[[
UPDATE: Here’s a message from Mark Rutland of ARM that clarifies some issues in Mono blog post:

https://lists.linaro.org/pipermail/linaro-toolchain/2016-September/005900.html

]]

Below is an excerpt of an email from Riku Voipio to the Linaro cross-distro and toolchain lists, about the recent ARM big.LITTLE issue discovered by the Mono project:

As painfully found out by mono team, if big/little cores have different cache line sizes, __clear_cache doesn’t work as expected. This affects any home-grown cache flushing mechanism as well.
Protip, if you suspect your application issues might related to big.LITTLE, use taskset(1) or hwloc-bind(1) to tie the process to either big or little cluster (or just a single core).

Here’s an excerpt from the Mono blog post (spoiler alert: it’s the final paragraph):

[…] Summary: Some ARM big.LITTLE CPUs can have cores with different cache line sizes, and pretty much no code out there is ready to deal with it as they assume all cores to be symmetrical. Worse, not even the ARM ISA is ready for this. An astute reader might realize that computing the cache line on every invocation is not enough for user space code: It can happen that a process gets scheduled on a different CPU while executing the __clear_cache function with a certain cache line size, where it might not be valid anymore. Therefore, we have to try to figure out a global minimum of the cache line sizes across all CPUs. Here is our fix for Mono: Pull Request. Other projects adopted our fix as well already: Dolphin and PPSSPP.

More info:

http://www.mono-project.com/news/2016/09/12/arm64-icache/

https://lists.linaro.org/pipermail/linaro-toolchain/2016-September/005899.html

new HP printers to include additional firmware security

~ hucktech ~ Leave a comment

Multiple news sites have stories about new HP printer which has new firmware security features. Quoting a story by Samira Sarraf and Steven Kiernan in CRM Australia:

[…] The recently announced printers, which are expected to start shipping in April 2017, also boast beefed-up security, including run-time intrusion detection, which monitors constantly for sign of attack and sends alerts into security management. There is also a firmware whitelisting device that makes sure that only good and certified firmware have access to the devices. And Sure Start, a chip on the devices that checks for the bios integrity during boot time, shuts the device down if it detects anything wrong and reboots. […]

http://www.crn.com.au/news/hp-mounts-assault-on-australian-copier-market-436797
http://www8.hp.com/us/en/hp-news/media-kits/2016/GPC_2016.html
http://www8.hp.com/us/en/printers/a3-multifunction.html
http://www8.hp.com/us/en/hp-news/newsroom.html

SPYRUS secure USB drives in some Microsoft Surface devices

~ hucktech ~ Leave a comment

Recently SPYRUS, Inc. announced the integration of their NIST 140-2 Level 3 secure USB 3.0 drive family with Microsoft Surface Pro devices.

“SPYRUS is currently the only manufacturer of hardware encrypted Windows To Go products that have successfully integrated support with the Microsoft Surface Pro family of tablets.  The unique feature set, to include provisioning support to boot the Windows To Go in UEFI Secure Boot mode, in conjunction with FIPS 140-2 Level 3 certification sets a new standard for security features and performance,” said Tom Dickens, SPYRUS COO. “Use cases for these smart drives also dovetail perfectly with the rapidly emerging requirements for collaboration, secure data storage, secure mobile computing, and secure devices with auditable cybersecurity.”

http://www.spyrus.com/windows-to-go-live-drives and http://www.spyrus.com/encrypting-usb-storage/
http://www.spyrus.com/spyrus-announces-integration-of-windows-to-go-and-p-3x-product-lines-with-microsoft-surface-pro-3-and-4/

Stewart on compiling your IBM S822LC’s firmware

~ hucktech ~ Leave a comment

Stewart Smith of IBM has a new blog post on how to compile your own firmware for the OpenPOWER-based IBM S822LC:

[…] IBM (my employer) recently announced  the new S822LC for HPC POWER8+NVLINK NVIDIA P100 GPUs server. The “For HPC” suffix on the model number is significant, as the S822LC is a different machine. What makes the “for HPC” variant different is that the POWER8 CPU has (in addition to PCIe), logic for NVLink to connect the CPU to NVIDIA GPUs.[…]

Compiling your own firmware for the S822LC for HPC

FWTS 16.09.00 released

~ hucktech ~ Leave a comment

Alex Hung of Canonical announced the latest release of FWTS, the FirmWare Test Suite, on the fwts-announce  and other lists.

New Features include:
  * lib: acpi: add supports for WPBT
  * acpi: wpbt: add ACPI WPBT test
  * lib: acpi: add supports for DRTM
  * acpi: drtm: add ACPI DRTM test
  * lib: fwts_guid: add a compare function
  * acpi: nfit: check fields equals 0 for Virtual CD and Disk
  * opal: mtd: Add OPAL MTD Validation
  * acpi: ACPI Platform check updates
  * acpi: fadt: Remove HEADLESS check on reduced hardware
  * pci: aspm: Add segment support
  * ACPICA: Update to version 20160831

See the full announcement for list of bugfixes.

http://fwts.ubuntu.com/release/fwts-V16.09.00.tar.gz
https://launchpad.net/~firmware-testing-team/+archive/ubuntu/ppa-fwts-stable
https://wiki.ubuntu.com/FirmwareTestSuite/ReleaseNotes/16.09.00
https://launchpad.net/ubuntu/+source/fwts

U-Boot v2016.09 released

~ hucktech ~ Leave a comment

Tom Rini of Konsulko announced the latest release of U-Boot on the u-boot list @lists.denx.de.

Highlights:
– More DM work (MMC, of-platdata for size constrained instances, etc)
– Lots and lots of architecture / SoC / Platform updates: x86, rockchip,
  sunxi, TI, NXP/FSL, Tegra, Zynq, uniphier
– mkimage cleanups
– More test.py updates, vboot now a testcase
– Secure boot work on both ARM and PowerPC.
– PSCI updates
– MAKEALL is gone, buildman is for use by all
– We now have xtensa support
– DT overlays
– More Kconfig migration
– Some NFS fixes

Read the full announcement if you’re able to help U-Boot with testing, they’re looking for some help with their new automated test framework.
https://github.com/swarren/uboot-test-hooks
https://github.com/trini/uboot-test-hooks
http://www.denx.de/wiki/U-Boot

New UEFI RNG tool

~ hucktech ~ Leave a comment

Finnbarr P. Murphy has a new UEFI tool that checks your firmware for RNGs, and it sounds like he’s found some Lenovo Thinkpad errors with it:

[…] Here is a small UEFI shell utility that checks your firmware for available RNGs: […] I built the utility on a 64-bit Fedora 24 platform using GCC and UDK2015. I have not tried building a 32-bit utility nor have I build it using Visual Studio or other development frameworks – so do not be surprised if you have modify either the code or the build recipe in these cases. I tested the utility on a Lenovo T450 using firmware version JBET60WW (1.24) and was surprised to find that the firmware did not appear to support any RNGs as evidenced by the zero RNG algorithm count returned. However, by explicitly, testing for the default RNG if the count was zero, it was possible to determine that the T450 did in fact at least support the default RNG. Perhaps, I am not parsing the UEFI specification correctly but I would expect the RNG count returned by GetInfo to include the default RNG. Interestingly, when I build and load the UDK2015 test RNG DXE driver which contains a reference counter mode DRBG (Deterministic Random Bit Generator) conforming to NIST SP 800-90a, the algorithm count returned by GetInfo jumps to 2. This leads me to suspect that their is a bug in the firmware w.r.t. to the RNG protocol implementation. Please let me know if I am incorrect in my assumptions or observations.

http://blog.fpmurphy.com/2016/08/rng-protocol-error-in-lenovo-thinkpad-firmware.html

Update on Intel SMM vulnerability

~ hucktech ~ Leave a comment

Intel SMM EoP mitigations due Sep-19

More on this:

Multiple Intel systems have SMM runtime EoP

https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00056&languageid=en-fr

Intel has a security advisory about SMM Elevation of Privilege vulnerability on multiple Intel product. It appears they have an estimated release for this: “Estimated Sept. 19th”

Severity rating: Important

Intel is releasing mitigations for a privilege escalation issue. This issue affects the UEFI BIOS of select Intel Products. The issue identified is a method that enables malicious code to gain access to System Management Mode (SMM). A malicious attacker with local administrative access can leverage the vulnerable function to gain access to System Management Mode (SMM) and take full control of the platform. Intel products that are listed below should apply the update. Other vendors’ products which use the common BIOS function SmmRuntime may be impacted.  To find out whether a product you have may be vulnerable to this issue, please contact your system supplier. Intel highly recommends applying the mitigations. For Intel branded products where a mitigation is still pending, we recommend following good security practices including running with least privilege and keeping security software and operating systems up to date.

The advisory also shows how to use dmidcode on Linux to get the vendor ID:

dmidecode -t 0 | grep Version | awk -F : ‘{ print $2 }’ | sed s/\ //g
dmidecode -t 2 | grep Product | awk -F : ‘{ print $2 }’ | sed s/\ //g

More info:
https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00056&languageid=en-fr

ORWL funded!

~ hucktech ~ Leave a comment

ORWL, “The First Open Source, Physically Secure Computer”, just got funded on CrowdSupply!

https://www.crowdsupply.com/design-shift/orwl/updates/funded-and-coreboot-bios

Joanna Rutkowska wrote a recent post that gives some great background on ORWL’s physical security:

http://blog.invisiblethings.org/2016/09/03/thoughts-about-orwl.html

New Intel/UEFI whitepaper: Establishing the Root of Trust

~ hucktech ~ 1 Comment

https://twitter.com/Intel_UEFI/status/773597835467956224

Click to access UEFI%20RoT%20white%20paper_Final%208%208%2016%20%28003%29.pdf

Vincent Zimmer and Michael Krau of Intel have written a new whitepaper for the UEFI Forum: “Establishing the root of trust”.

The first step in securing a computing device – from a simple embedded device to a supercomputer and everything in between – is to ensure that it can start up under the following conditions:
– It is operating as expected
– All the firmware needed to run the system is intact
– It has not been tampered with in any way

As described in the first white paper in this series, Understanding the Chain of Trust and Its Vital Role in Keeping Computing Systems Secure, the UEFI specification includes a mechanism for ensuring the integrity and security of firmware (the all-important link between the hardware and the operating system) as a system starts up. This mechanism is called Secure Boot and uses public key cryptography to validate that each piece of firmware has been digitally signed and is therefore unmodified as the system starts up. In a chain of trust, each piece of firmware must be digitally signed before it can start up. Once one piece of code has been validated, it can then validate the next section and so on until the system is fully booted and control handed over to the operating system. But how does that chain get started? While difficult, it would be possible for an attacker to inject malicious attack code of some sort prior to start of the chain of trust to gain low-level and nearly undetectable control over the system. To prevent this, the chain of trust requires a strong foundation. In modern systems, this is known as the root of trust. A root of trust, one that can be counted on to anchor the chain of trust in the face of the most determined attackers, can be established in a number of ways. The most secure approaches use some form of an unchangeable section of hardware to validate the initial keyed signature, but there are a number of effective approaches. Ultimately it comes down to the level of security you’re comfortable with and an understanding of the approach used to establish the root of trust. This white paper looks at several common methods for establishing a root of trust as the basis for the UEFI Secure Boot process. […]