Month: May 2018

ARM64JSON: AArch64 instructions encoded in JSON

~ hucktech ~ Leave a comment

https://twitter.com/kov4l3nko/status/995433621925384192

 

The repository contains ARM64 (AArch64) instruction encoding in a machine-readable JSON:

* ISA_v83A_A64_xml_00bet6_instructions.json contains encoding of every instruction, including ARM64v2/v3 extensions.

* ISA_v83A_A64_xml_00bet6_group_class.json contains hierarchical encoding ARM64 top level -> Instruction group (e.g. “Data Processing — Immediate”) -> Instruction class (e.g. “Add/subtract (immediate)”). No instruction encodings in this file.

The simple and easyly-organised JSON data was extracted from a machine-readable ARM64 specs. A64 ISA XML for Armv8.3 ver. 00bet6.1 released by ARM.

https://github.com/kov4l3nko/ARM64JSON

See-also:

ARM: documents CSDB (Consumption of Speculative Data Barrier) instruction

ARM Releases Machine Readable Architecture Specification

 

fwupd / LVFS and user privacy

~ hucktech ~ Leave a comment

There’s been a few blog posts from the LVFS project and the System76 team regarding firmware updates.

Don’t buy System76 hardware and expect to get firmware updates from the LVFS

System76: System76 and LVFS – what really happened

The latest article is from FOSSpost.org by M.Hanny Sabbagh, which focuses on privacy issues of LVFS, from the last System76 article. While privacy issues are important, don’t forget that firmware update privacy issues exist with ALL other OSes, and LVFS team mentions transition to Linux Foundation for hosting. Most firmware updates come from OEM, so each will have their own CDN/privacy/security issues. I’m hoping the LVFS project gets picked up by the Qubes/TAILS/Subgraph/GNUHardenedLinux or some other privacy/security-centric distro, and can integrate with latest security and privacy techniques, making it Tor-friendly, etc.

See threads here and comments in fosspost.org blog post, and in Twitter feed:

https://lists.debian.org/debian-efi/2018/05/threads.html

https://fosspost.org/analytics/privacy-security-concern-regarding-gnome-software

Diverse Lynx: seeks PenTester to use CHIPSEC [against Lenovo?]

~ hucktech ~ Leave a comment

Lenovo working throug an external pentest firm? Wish I saw more OEMs asking for appropriate job skills.

If you’re thinking about applying, look at some of the reviews for this consulting firm before doing so. Maybe look if Lenovo has a direct position open as well.

Diverse Lynx: Penetration tester
[…]It is also firmware analysis which according to Lenovo is analyzing anything that may be on disk. […] Chipsec needs to be used for this assessment. It’s for UEFI attacks, but it’s fairly automated.[…]

https://www2.jobdiva.com/candidates/myjobs/openjob_outside.jsp?id=10760288

https://www.diverselynx.com/

 

CVE-2018-8897: Debug Exception May Cause Unexpected Behavior

~ hucktech ~ Leave a comment

A statement in the System Programming Guide of the Intel 64 and IA-32 Architectures Software Developer’s Manual (SDM) was mishandled in the development of some or all operating-system kernels, resulting in unexpected behavior for #DB exceptions that are deferred by MOV SS or POP SS, as demonstrated by (for example) privilege escalation in Windows, macOS, some Xen configurations, or FreeBSD, or a Linux kernel crash. The MOV to SS and POP SS instructions inhibit interrupts (including NMIs), data breakpoints, and single step trap exceptions until the instruction boundary following the next instruction (SDM Vol. 3A; section 6.8.3). (The inhibited data breakpoints are those on memory accessed by the MOV to SS or POP to SS instruction itself.) Note that debug exceptions are not inhibited by the interrupt enable (EFLAGS.IF) system flag (SDM Vol. 3A; section 2.3). If the instruction following the MOV to SS or POP to SS instruction is an instruction like SYSCALL, SYSENTER, INT 3, etc. that transfers control to the operating system at CPL < 3, the debug exception is delivered after the transfer to CPL < 3 is complete. OS kernels may not expect this order of events and may therefore experience unexpected behavior when it occurs.

https://www.triplefault.io/2018/05/spurious-db-exceptions-with-pop-ss.html

Click to access popss.pdf

https://software.intel.com/en-us/articles/intel-sdm

https://www.kb.cert.org/vuls/id/631579
https://nvd.nist.gov/vuln/detail/CVE-2018-8897
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-8897
http://openwall.com/lists/oss-security/2018/05/08/1
http://openwall.com/lists/oss-security/2018/05/08/4

https://github.com/torvalds/linux/commit/d8ba61ba58c88d5207c1ba2f7d9a2280e7d03be9
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d8ba61ba58c88d5207c1ba2f7d9a2280e7d03be9
https://patchwork.kernel.org/patch/10386677/
https://people.canonical.com/~ubuntu-security/cve/2018/CVE-2018-8897.html
https://security-tracker.debian.org/tracker/CVE-2018-8897
https://kb.vmware.com/s/article/54988
https://bugzilla.redhat.com/show_bug.cgi?id=1567074
https://support.apple.com/HT208742
https://svnweb.freebsd.org/base?view=revision&revision=333368
https://www.freebsd.org/security/advisories/FreeBSD-SA-18:06.debugreg.asc
https://xenbits.xen.org/xsa/advisory-260.html
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2018-8897

System76: System76 and LVFS – what really happened

~ hucktech ~ 1 Comment

Re: https://firmwaresecurity.com/2018/05/10/dont-buy-system76-hardware-and-expect-to-get-firmware-updates-from-the-lvfs/ this is the Sytem76 side of the story:

The Future of Firmware

LVFS and UpdateCapsule might be okay for companies mostly focused on a proprietary future (Logitech, Dell, etc.). UpdateCapsule is not the technique companies will use in a future of open source firmware—the future we’re working toward. Liberating firmware is going to be a long and challenging process. Much like Free Software has replaced proprietary software over time, we must chip away at the proprietary firmware pieces within the hardware supply chain. Manufacturing is the first step. This year we’ll manufacture open source desktop designs in our Denver plant. The CAD will be free to download, change, and produce. There will be a separate, open source electrical design and open source firmware daughter board to control functions within the desktop. On a mainboard there is the BIOS chip and one or more embedded controllers that manage fans, keyboard, LEDs, hotkeys and other critical functions. It’s all proprietary. Our strategy is to move this functionality from the proprietary mainboard to the open source daughter board. Then anyone can create a PCB with basic computer functionality, understand how it works, and improve upon the work. One could have this PCB made at Osh Park, install it in their desktop, tune it, and replace a bunch of proprietary firmware instantly. We’ll grow from there. Slowly we’ll chip away at more and more of the mainboard functions until what’s left is Intel and AMD bits. Then there’s the challenge of convincing them to go open. There’s room for cautious optimism.[…]

http://blog.system76.com/post/173801677358/system76-and-lvfs-what-really-happened

Who is working to fix (unify) Linux firmware solutions? UEFI Forum? Linux Foundation? I don’t see a single OEM (eg, System76) driving any such standardization. … 😦

Throwhammer

~ hucktech ~ Leave a comment

https://arstechnica.com/information-technology/2018/05/attackers-trigger-rowhammer-bit-flips-by-sending-network-packets-over-a-lan/

https://securityaffairs.co/wordpress/72377/hacking/throwhammer-rowhammer-attack.html

INTEL-SA-00106: Intel Integrated Performance Primitives Cryptography Library Update

~ hucktech ~ Leave a comment

Intel ID: INTEL-SA-00106
Product family: Intel® Integrated Performance Primitives
Impact of vulnerability: Information Disclosure
Last revised: 05/10/2018

Some implementations in Intel® Integrated Performance Primitives Cryptography Library before version 2018 U2.1 do not properly ensure constant execution time. Intel recommends that users of Intel® Integrated Performance Primitives Cryptography Library evaluate their implementations and update to IPP 2018 U2.1 as appropriate. Intel thanks Ahmad Moghimi, Thomas Eisenbarth, and Berk Sunar from Worcester Polytechnic Institute for reporting this issue.[…]

https://registrationcenter.intel.com/en/forms/?productid=2717

https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00106.html

INTEL-SA-00135: Intel SGX Platform Software

~ hucktech ~ Leave a comment

Intel ID: INTEL-SA-00135
Product family: Intel® SGX SDK and Intel® SGX Platform Software
Impact of vulnerability: Information Disclosure
Last revised: 05/10/2018

Intel® Software Guard Extensions Software Development Kit (SDK) and Platform Software (PSW) utilize the Intel® Integrated Performance Primitives Cryptography Library. Vulnerabilities in this cryptography library have been reported that may enable a local attacker running malware utilizing software based side channel methods to gather data concerning certain cryptographic keys. In accordance with the recent public security advisory INTEL-SA-00106 published for the Intel® Integrated Performance Primitives Cryptography Library, new versions of the Intel® SGX SDK and Intel® SGX PSW have been released.[…]

https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00135.html

 

RISC-V: Secure Boot and Remote Attestation in the Sanctum Processor

~ hucktech ~ Leave a comment

Cryptology ePrint Archive: Report 2018/427

Secure Boot and Remote Attestation in the Sanctum Processor

During the secure boot process for a trusted execution environment, the processor must provide a chain of certificates to the remote client demonstrating that their secure container was established as specified. This certificate chain is rooted at the hardware manufacturer who is responsible for constructing chips according to the correct specification and provisioning them with key material. We consider a semi-honest manufacturer who is assumed to construct chips correctly, but may attempt to obtain knowledge of client private keys during the process. Using the RISC-V Rocket chip architecture as a base, we design, document, and implement an attested execution processor that does not require secure non-volatile memory, nor a private key explicitly assigned by the manufacturer. Instead, the processor derives its cryptographic identity from manufacturing variation measured by a Physical Unclonable Function (PUF). Software executed by a bootloader built into the processor transforms the PUF output into an elliptic curve key pair. The (re)generated private key is used to sign trusted portions of the boot image, and is immediately destroyed. The platform can therefore provide attestations about its state to remote clients. Reliability and security of PUF keys are ensured through the use of a trapdoor computational fuzzy extractor.

We present detailed evaluation results for secure boot and attestation by a client of a Rocket chip implementation on a Xilinx Zynq 7000 FPGA.

https://eprint.iacr.org/2018/427

Click to access 427.pdf

Symbiotic: tool for finding bugs in computer programs based on instrumentation, program slicing and KLEE

~ hucktech ~ Leave a comment

Symbiotic is a tool for analysis of computer programs. It can check all common safety properties like assertion violations, invalid pointer dereference, double free, memory leaks, etc. Symbiotic uses three well-know techniques: instrumentation, program slicing, and symbolic execution. We use LLVM as program representation.

https://github.com/staticafi/symbiotic

http://staticafi.github.io/symbiotic/

DMTF Redfish and PCIMG form alliance for Industrial IoT standards

~ hucktech ~ Leave a comment

DMTF and PICMG Form Alliance

DMTF and the PCI Industrial Computer Manufacturer Group (PICMG) have formed an alliance to help ensure the two organizations’ standards are coordinated and aligned in the Industrial Internet of Things (IIoT) domain.

Click to access PICMG_Work_Register_v1.0.pdf

https://www.picmg.org/https://dmtf.org/

Expect to see Redfish listed as 10th entry here shortly, I am guessing:

Open Standards

 

CacheQuote: Efficiently Recovering Long-term Secrets of SGX EPID via Cache Attacks

~ hucktech ~ Leave a comment

CacheQuote: Efficiently Recovering Long-term Secrets of SGX EPID via Cache Attacks

Intel Software Guard Extensions (SGX) allows users to perform secure computation on platforms that run untrusted software. To validate that the computation is correctly initialized and that it executes on trusted hardware, SGX supports attestation providers that can vouch for the user’s computation. Communication with these attestation providers is based on the Extended Privacy ID (EPID) protocol, which not only validates the computation but is also designed to maintain the user’s privacy. In particular, EPID is designed to ensure that the attestation provider is unable to identify the host on which the computation executes. In this work we investigate the security of the Intel implementation of the EPID protocol. We identify an implementation weakness that leaks information via a cache side channel. We show that a malicious attestation provider can use the leaked information to break the unlinkability guarantees of EPID. We analyze the leaked information using a lattice-based approach for solving the hidden number problem, which we adapt to the zero-knowledge proof in the EPID scheme, extending prior attacks on signature schemes.

https://tches.iacr.org/index.php/TCHES/article/view/879

Don’t buy System76 hardware and expect to get firmware updates from the LVFS

~ hucktech ~ 2 Comments

Re: https://firmwaresecurity.com/2018/01/29/linux-oems-support-fwupd-org/

This is a good example of how vendors have vendor-centric tools. Windows Update supports updating firmware, but most Windows OEMs don’t use it. LVFS supports updating firmware on Linux, but most Linux OEMs don’t use it. Sad for users. It seems a bit worse now that UEFI supposedly has a common interface to update firmware, there’s still a problem with UEFI firmware updates. 😦

tl;dr: Don’t buy System76 hardware and expect to get firmware updates from the LVFS

System76 and the LVFS

 

 

QEMU v2.12.0 released (with Spectre/Meltdown update)

~ hucktech ~ Leave a comment

QEMU version 2.12.0 released
24 Apr 2018
This release contains 2700+ commits from 204 authors.

* Spectre/Meltdown mitigation support for x86/pseries/s390 guests.
* Better IPMI support for Platform Events and SEL logging in internal BMC emulation
* SMBIOS support for “OEM Strings”, which can be used for automating guest image activation without relying on network-based querying

[…]A previous post detailed how QEMU/KVM might be affected by Spectre/Meltdown attacks, and what the plan was to mitigate them in QEMU 2.11.1 (and eventually QEMU 2.12). QEMU 2.11.1 is now available, and contains the aforementioned mitigation functionality for x86 guests, along with additional mitigation functionality for pseries and s390x guests (ARM guests do not currently require additional QEMU patches). However, enabling this functionality requires additional configuration beyond just updating QEMU, which we want to address with this post.[…]

https://www.qemu.org/2018/04/24/qemu-2-12-0/

More on QEMU and Spectre/Meltdown:

https://www.qemu.org/2018/02/14/qemu-2-11-1-and-spectre-update/

https://www.qemu.org/2018/01/04/spectre/

Microsoft: Hardware Security Test Interface (HSTI) 1.1a

~ hucktech ~ Leave a comment

I think this web page has just changed. However, I’m not sure if HSTI 1.1a is new or I’ve got a “false positive” in my searching for new stuff… 🙂 The checklist of issues for IBVs and IHVs is worth [re]reading.

Hardware Security Test Interface (HSTI) 1.1a
05/07/2018
HSTI specifies a standard test interface for proprietary platform security technologies that enforce the Secure Boot promise (for example, SPI flash or eMMC partition locking, proper SMM configuration, Intel Boot Guard properly configured, and so on). Silicon and BIOS vendors specify and implement the necessary test cases which are shipped in release firmware as a built-in self-test. The inclusion of the test interface into the firmware allows the knowledgeable consumer the ability to verify the presence or absence of firmware security features.[…]

https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/hardware-security-test-interface-1-1a

https://docs.microsoft.com/en-us/windows-hardware/test/hlk/testref/hardware-security-testability-specification

 

Microsoft: C++ Developer Guidance for Speculative Execution Side Channels

~ hucktech ~ Leave a comment

C++ Developer Guidance for Speculative Execution Side Channels
05/03/2018
Matt Miller Colin Robertson Mike B

This article contains guidance for developers to assist with identifying and mitigating speculative execution side channel hardware vulnerabilities in C++ software. These vulnerabilities can disclose sensitive information across trust boundaries and can affect software that runs on processors that support speculative, out-of-order execution of instructions. This class of vulnerabilities was first described in January, 2018 and additional background and guidance can be found in Microsoft’s security advisory. The guidance provided by this article is related to the class of vulnerabilities represented by CVE-2017-5753, also known as Spectre variant 1. This hardware vulnerability class is related to side channels that can arise due to speculative execution that occurs as a result of a conditional branch misprediction. The Visual C++ compiler in Visual Studio 2017 (starting with version 15.5.5) includes support for the /Qspectre switch provides a compile-time mitigation for a limited set of potentially vulnerable coding patterns related to CVE-2017-5753. The documentation for the /Qspectre flag provides more information on its effects and usage.[…]

https://docs.microsoft.com/en-us/cpp/security/developer-guidance-speculative-execution

[…]An accessible introduction to speculative execution side channel vulnerabilities can be found in the presentation titled The Case of Spectre and Meltdown by one of the research teams that discovered these issues.[…]