Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Wow, the coreboot blog is busy, a lot of GSoC activity to catch up to!
Jneuschaefer is doing RISC-V updates to coreboot….
[GSoC] Better RISC-V support, week #2
[GSoC] Better RISC-V support, week #3
Hatim Kanchwala is working on FlashROM…
[GSoC] Multiple status register support, week #1 and #2
http://blogs.coreboot.org/blog/2016/06/07/gsoc-multiple-status-register-support-week-1-and-2/
Antonello Dettori is working on SerialICE:
[GSOC] Panic Room, week #2
The Trusted Computing Group (TCG) has released revisions to multiple specifications:
I wish I knew why WordPress inserts the additional whitespace in these posts…. 😦
PC Client Specific Platform Firmware Profile Specification, Family 2.0, Level 00 Revision 00.21 and Errata
The PC Client Platform Specific Profile for TPM 2.0 systems defines the requirements for platform firmware to initialize and interact with a TPM 2.0 device in a PC Client platform. This specification should be used in conjunction with the TCG UEFI Protocol Specification Family 2.0, the TCG Physical Presence Interface Specification, and the TCG ACPI Specification to design and implement a PC Client TPM 2.0-enabled platform. This specification replaces the requirements defined in the PC Client Implementation Specification for Conventional BIOS and the PC Client UEFI Platform Specification for systems with TPM 2.0 devices.
http://www.trustedcomputinggroup.org/pc-client-specific-platform-firmware-profile-specification/
PC Client Work Group EFI Protocol Specification, Family 2.0, Level 00, Revision 00.13
The purpose of this document is to define a standard interface to the TPM on an UEFI platform. It defines data structures and APIs that allow an OS to interact with UEFI firmware to query information important in an early OS boot stage. Such information include: is a TPM present, which PCR banks are active, change active PCR banks, obtain the TCG boot log, extend hashes to PCRs, and append events to the TCG boot log.The latest revision of this specification is written with platforms with TPM 2.0 devices in mind, but nothing in this specification prevents the use with platforms with TPM 1.2 devices.
http://www.trustedcomputinggroup.org/tcg-efi-protocol-specification/
TCG Storage Opal Test Cases Specification, Version 2.00 Errata Version 1.00, Revision 1.00
The Opal Test Cases Specification contains a set of tests that are intended to verify the correct behavior of a storage device implementing the Opal SSC Specification. These test cases are intended to be used as a basis for the compliance component of the projected Storage certification program, which would seek to ensure a high level of interoperability of storage devices from multiple vendors.
http://www.trustedcomputinggroup.org/tcg-storage-opal-test-cases/
Multiple Stakeholder Model , Revision 3.40
The Multiple Stakeholder Model (MSM) is an informative reference document that describes use cases, recommended capabilities, and various implementation alternatives to allow multiple stakeholders to coexist safely on a mobile platform. This document includes guidance on how to leverage TCG specifications to realize each alternative. In particular, this document emphasizes the role of the Trusted Platform Module (TPM), the Mobile Common Profile, and the Mobile Reference Architecture specifications to support these capabilities for multiple stakeholders. The goal of the MSM is to provide trusted services, for example, TPM and Trusted Network Communications (TNC), in a secure and efficient manner to all interested stakeholders (both local and remote) for a given mobile device. This guidance is applicable to all mobile devices (smartphones, feature phones, basic phones, etc.) and may be useful for other computing devices. The target audience for this document includes designers, manufacturers, system integrators, application developers, and implementers of Trusted Computing technologies in mobile platforms.
http://www.trustedcomputinggroup.org/multiple-stakeholder-model/
http://www.trustedcomputinggroup.org/tpm-library-specification/
http://www.trustedcomputinggroup.org/tcg-tpm-2-0-mobile-common-profile/
http://www.trustedcomputinggroup.org/tpm-2-0-mobile-reference-architecture-specification/
TNC IF-M Segmentation Specification Version 1.0, Revision 5
The Trusted Network Communications (TNC) Work Group defines an open solution architecture that enables network operators to evaluate and enforce policies regarding endpoint integrity when granting access to a network infrastructure. As TCG’s Trusted Network Communications (TNC)-enabled technology is deployed in real-world environments, we’re learning that deplorer’s have the need to collect robust posture information to support endpoint compliance, security automation, and continuous monitoring. IF-M is the communication layer of the TNC architecture used to connect the endpoint components that collect information about the endpoint, and the corresponding components on a policy server that receive that information and act on it. IF-M is designed to be flexible to support communication of virtually any type of information about the endpoint that the enterprise might wish to know.
TCG Updates IF-M Segmentation to Enable Efficient Information Exchange
http://www.trustedcomputinggroup.org/tnc-ifm-segmentation-specification/
Julius Baxter has announced the 2016 ORCONF, the annual open source digital design conference, for October in Italy, excerpted announcement:
I’d like to announce ORCONF 2016, the annual open source digital design conference. This year we’re very pleased to be hosted by Davide Rossi and his group at the University of Bologna in Bologna, Italy over October 7th, 8th and 9th. As in previous years, we’re looking forward to bringing together those involved and interested in any facet of open source embedded systems engineering. We’d like to have a strong showing from the various open source communities and their projects that are out there, academia and their interesting research ideas that either directly or indirectly contribute to the open source hardware ecosystem, and commercial developers who either contribute or perhaps just have success stories to share about their use of, or collaboration with, open source hardware projects. The conference is being organised by the Free and Open Source Silicon Foundation (FOSSi) with help, of course, by our hosts at the University of Bologna. ORCONF will be free to attend, and we’d like to provide food and drinks during the day for attendees, amongst other things, and so are seeking sponsors for the event. Please get in touch if you’d like to sponsor us this year. Registration and presentation submission forms are now live. Please do register if you plan to attend.
Full announcement:
http://oshug.org/pipermail/oshug
More info:
http://orconf.org
http://goo.gl/forms/u6V54ay8P4i3wtXG2
http://goo.gl/forms/Nah5LH7cJWK1uQ6L2
I am becoming more and more of a luddite. 😦
http://www.scmagazine.com/nsa-looking-into-connected-biomedical-device-surveillance/article/503044/
http://www.popularmechanics.com/technology/security/news/a21319/the-nsa-wants-to-spy-on-internet-of-things/
http://news.softpedia.com/news/nsa-won-t-shy-away-from-hacking-iot-medical-devices-505205.shtml
NSA interested in exploiting internet-connected medical devices, spying on IoT
TrustZone Kernel Privilege Escalation (CVE-2016-2431)
In this blog post we’ll continue our journey from zero permissions to code execution in the TrustZone kernel. Having previously elevated our privileges to QSEE, we are left with the task of exploiting the TrustZone kernel itself.
“Why?”, I hear you ask. Well… There are quite a few interesting things we can do solely from the context of the TrustZone kernel. To name a few:
* We could hijack any QSEE application directly, thus exposing all of it’s internal secrets. For example, we could directly extract the stored real-life fingerprint or various secret encryption keys (more on this in the next blog post!).
 * We could disable the hardware protections provided by the SoC’s XPUs, allowing us to read and write directly to all of the DRAM. This includes the memory used by the peripherals on the board (such as the modem).
 * As we’ve previously seen, we could blow the QFuses responsible for various device features. In certain cases, this could allow us to unlock a locked bootloader (depending on how the lock is implemented).
So now that we’ve set the stage, let’s start by surveying the attack surface! […]
https://bits-please.blogspot.com/2016/06/trustzone-kernel-privilege-escalation.html
“ARMPwn: Repository to train/learn memory corruption exploitation on the ARM platform. This is the material of a workshop I prepared for my CTF Team”
https://github.com/saelo/armpwn
ARMPWN challenge write-up:
A few weeks ago, I came accross @5aelo repo called armpwn for people wanting to have a bit of ARM fun. I had recently spent some time adding new features and perfectionning old ones to my exploit helper gdb-gef and I saw there a perfect practice case. On top of that, I had nothing better to do yesterday ☺ This challenge was really fun, and made so much easier thanks to gef especially to defeat real life protections (NX/ASLR/PIC/Canary), and on a different architecture (Intel is so ‘90). This is mostly why I’m doing this write-up, but feel curious and do it by yourself. Fun time ahead guaranteed ☺ […]
Intel Security Center reports a vulnerability in some Intel SSD drives. See the full announcement for model specifics.
Vulnerability impacting the Intel® Solid-State Drive 540s Series, Intel® Solid State Drive E 5400s Series and Intel® Solid State Drive DC S3100 Series drives
Intel ID: Â Â Â Â INTEL-SA-00053
Product family:     Intel® Solid-State Drive Consumer, Embedded and Data Center
Impact of vulnerability: Â Â Â Â Elevation of Privilege
Severity rating: Â Â Â Â Moderate
Original release: Â Â Â Â Jun 14, 2016
A vulnerability was identified in the Intel® Solid-State Drive 540s Series, Intel® Solid State Drive E 5400s Series and Intel® Solid State Drive DC S3100 Series leading to a potential data corruption issue. A vulnerability was identified in the Intel® Solid-State Drive 540s Series, Intel® Solid State Drive E 5400s Series and Intel® Solid State Drive DC S3100 Series leading to a potential data corruption issue. This may occur If the Intel® Solid-State Drive 540s Series, Intel® Solid State Drive E 5400s Series or Intel® Solid State Drive DC S3100 Series drives receive a read or write command during ATA security locked state. Intel has not received any reports of any Intel SSD products having experienced this issue. Intel strongly recommends that customers with the listed products download and apply the mitigated firmware version using the update source outlined above.
https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00053&languageid=en-fr
Damien Zammit has a new post on BoingBoing:
Intel x86s hide another CPU that can take over your machine (you can’t audit it)
Recent Intel x86 processors implement a secret, powerful control mechanism that runs on a separate chip that no one is allowed to audit or examine. When these are eventually compromised, they’ll expose all affected systems to nearly unkillable, undetectable rootkit attacks. I’ve made it my mission to open up this system and make free, open replacements, before it’s too late. […]
Intel x86s hide another CPU that can take over your machine (you can’t audit it)
ARM has some new security videos in the works, targetting developers.
<soapbox>I hate “webinars”. Why require people to signup to watch an online video, often only at a particular time?. An evil marketing trick, good way to see how mature a company is. Just post the videos online and let people watch it when they want, and not have to register to watch them! </soapbox>
“A short while ago, slipstream/RoL dropped an exploit for the ASUS memory mapping driver (ASMMAP/ASMMAP64) which was vulnerable to complete physical memory access (read/write) to unprivileged users, allowing for local privilege escalation and all sorts of other problems. An aside to this was that there were also IOCTLs available to perform direct I/O operations (in/out instructions) directly from unprivileged usermode, which had additional interesting impacts for messing with system firmware without triggering AV heuristics.
[…]
In addition to the ASMMAP bugs, I also reported the exact same bugs in their UEFI update driver (AsUpIO.sys). This driver is deployed as part of the usermode UEFI update toolset, and exposes almost identical functionality which (as slipstream/RoL pointed out) is likely from an NT3.1 example driver that was written long before Microsoft took steps to segregate malicious users from physical memory in any meaningful way.”
[…]
http://blogs.intel.com/evangelists/2016/06/09/intel-innovating-stop-cyber-attacks/
https://forums.grsecurity.net/viewtopic.php?f=7&t=4490
The GRSecurity post has a few more links as well:
[…]
Full disclosure: we have a competing production-ready solution to defend against code reuse attacks called RAP, see [R1], [R2]. RAP isn’t tied to any particular CPU architecture or operating system, and it scales to real-life software from Xen to Linux to Chromium with excellent performance.
[…]
Conclusion
In summary, Intel’s CET is mainly a hardware implementation of Microsoft’s weak CFI implementation with the addition of a shadow stack. Its use will require the presence of Intel processors that aren’t expected to be released for several years. Rather than truly innovating and advancing the state of the art in performance and security guarantees as RAP has, CET merely cements into hardware existing technology known and bypassed by academia and industry that is too weak to protect against the larger class of code reuse attacks. One can’t help but notice a striking similarity with Intel’s MPX, another software-dependent technology announced with great fanfare a few years ago that failed to live up to its many promises and never reached its intended adoption as the solution to end buffer overflow attacks and exists only as yet another bounds-checking based debugging technology.
https://twitter.com/aionescu/status/741035301246783488
Intel release new technology specifications to protect against ROP attacks
By Baiju Patel on June 9, 2016Â Â Â
“Intel has a long history of working with the software community and making strides in strengthening protections of operating systems and software running on modern computer systems. As these protections came into effect, adversaries started looking for creative alternatives to bypass these protections, Return Oriented Programming (also known as ROP) and Jump Oriented Programming (also known JOP) are two such techniques that has been gaining popularity. ROP or JOP attacks are particularly hard to detect or prevent because the attacker uses existing code running from executable memory in a creative way to change program behavior. What makes it hard to detect or prevent ROP/JOP is the fact that attacker uses existing code running from executable memory. Many software-based detection and prevention techniques have been developed and deployed with limited success.
Intel and Microsoft recognized the seriousness of ROP attacks as well as the difficulty in developing the means to protect from ROP/JOP. Together, we considered over ten technology innovations to address these emerging threats over last 7 years and narrowed it down to the CET specification for x86/x64 architecture to make significant advances in addressing the ROP threat. Based on prior experience with defining instruction set extensions, and enabling challenges associated with a new ISA, we set goals to have an ISA for ROP/JOP prevention that is transparent to most well designed/implemented software requiring minimal to no changes; yet allow opt out capability for SW that requires changes. We also wanted to make sure that the solution is applicable to not just applications, but also to operating system kernels, and is beneficial to SW written using most programming languages. We also wanted to ensure that software enabled for CET works on legacy platforms without changes (albeit with no security benefits). Finally, and most importantly, we wanted to address all known ROP/JOP attacks.
While we include a brief description of CET here, there is no substitute for careful reading of the complete specification. Here we highlight two key aspects of ISA to get you started, namely, shadow stack and indirect branch tracking. It is the combination of these two that are designed to address both ROP and JOP class of attacks. […]”
“DRAMA Reverse-Engineering Tool and Side-Channel Tools
This repository contains several tools to reverse engineer the undocument DRAM addressing functions on Intel CPUs. These DRAM addressing functions uncovered a new side channel, enabling DRAMA (DRAM addressing) attacks. These attacks exploit the DRAM row buffer that is shared, even in multi-processor systems. Apart from that our attack improves Rowhammer attacks and enabled the first successful Rowhammer attacks on DDR4 memory.
The “DRAMA” paper by Pessl, Gruss, Maurice, Schwarz, and Mangard will be published at the Usenix Security Symposium 2016.”
There will be a part 5!
Practical Reverse Engineering Part 4 – Dumping the Flash
   Part 1 – Hunting for Debug Ports
   Part 2 – Scouting the Firmware
   Part 3 – Following the Data
In Parts 1 to 3 we’ve been gathering data within its context. We could sniff the specific pieces of data we were interested in, or observe the resources used by each process. On the other hand, they had some serious limitations; we didn’t have access to ALL the data, and we had to deal with very minimal tools… And what if we had not been able to find a serial port on the PCB? What if we had but it didn’t use default credentials? In this post we’re gonna get the data straight from the source, sacrificing context in favour of absolute access. We’re gonna dump the data from the Flash IC and decompress it so it’s usable. This method doesn’t require expensive equipment and is independent from everything we’ve done until now. An external Flash IC with a public datasheet is a reverser’s great ally. […]
More info:
http://jcjc-dev.com/2016/06/08/reversing-huawei-4-dumping-flash/
Pointers to 1-3 are also here:
The CHIPSEC team have tweeted about an upcoming 1.2.3 release with more Xen, Hyper-V, IOMMU, EPT support.
Also, Yuriy Bulygin of the Intel CHIPSEC team has posted some videos of their REcon training showing CHIPSEC usage:
https://github.com/chipsec/chipsec
It looks like their last checkin to the public git repo was in April:
https://github.com/chipsec/chipsec/commits/master
Christoph Hellwig has submitted multiple patches Linux’s existing NVMe support to enable ‘NVMe over Fabrics’ support. I’ve included his initial comments for each of the 4 patches:
—–
general preparation for NVMe over Fabrics support
This patch set adds some needed preparations for the upcoming NVMe over Fabrics support. Contains:
– Allow transfer size limitations for NVMe transports
– Add the get_log_page command definition required by the NVMe target
– more helpers in core code that can be used by various transports
– add some missing constants and identify attributes
—–
NVMe over Fabrics target implementation
This patch set adds a generic NVMe over Fabrics target. The implementation conforms to the NVMe 1.2b specification (which includes Fabrics) and provides the NVMe over Fabrics access to Linux block devices. The target implementation consists of several elements:
– NVMe target core:Â defines and manages the NVMe entities (subsystems, controllers, namespaces, …) and their allocation, responsible for initial commands processing and correct orchestration of the stack setup and tear down.
– NVMe admin command implementation: responsible for parsing and servicing admin commands such as controller identify, set features, keep-alive, log page, …).
– NVMe I/O command implementation: responsible for performing the actual I/O (Read, Write, Flush, Deallocate (aka Discard). It is a very thin layer on top of the block layer and implements no logic of it’s own. To support exporting file systems please use the loopback block driver in direct I/O mode, which gives very good performance.
– NVMe over Fabrics support: responsible for servicing Fabrics commands (connect, property get/set).
– NVMe over Fabrics discovery service: responsible to serve the Discovery log page through a special cut down Discovery controller.
The target is configured using configfs, and configurable entities are:
 – NVMe subsystems and namespaces
 – NVMe over Fabrics ports and referrals
 – Host ACLs for primitive access control – NVMe over Fabrics access control is still work in progress at the specification level and will be implemented once that work has finished.
To configure the target use the nvmetcli tool from http://git.infradead.org/users/hch/nvmetcli.git, which includes detailed setup documentation.
In addition to the Fabrics target implementation we provide a loopback driver which also conforms the NVMe over Fabrics specification and allows evaluation of the target stack with local access without requiring a real fabric.
Various test cases are provided for this implementation: nvmetcli contains a python testsuite that mostly stresses the configfs interface of the target, and we have various integration tests prepared for the kernel host and target which are available at:
   git://git.infradead.org/nvme-fabrics.git nvmf-selftests
   http://git.infradead.org/nvme-fabrics.git/shortlog/refs/heads/nvmf-selftests
This repository also contains patches from all the series posted today in case you prefer using a git repository over collecting patches.
NVMe over Fabrics RDMA transport drivers
This patch set implements the NVMe over Fabrics RDMA host and the target drivers. The host driver is tied into the NVMe host stack and implements the RDMA transport under the NVMe core and Fabrics modules. The NVMe over Fabrics RDMA host module is responsible for establishing a connection against a given target/controller, RDMA event handling and data-plane command processing. The target driver hooks into the NVMe target core stack and implements the RDMA transport. The module is responsible for RDMA connection establishment, RDMA event handling and data-plane RDMA commands processing. RDMA connection establishment is done using RDMA/CM and IP resolution. The data-plane command sequence follows the classic storage model where the target pushes/pulls the data.
generic NVMe over Fabrics library support
This patch set adds the necessary infrastructure for the NVMe over Fabrics functionality and the NVMe over Fabrics library itself. First we add some needed parameters to NVMe request allocation such as flags (for reserved commands – connect and keep-alive), also support tag allocation of a given queue ID (for connect to be executed per-queue) and allow request to be queued at the head of the request queue (so reconnects can pass in flight I/O). Second, we add support for additional sysfs attributes that are needed or useful for the Fabrics driver. Third we add the NVMe over Fabrics related header definitions and the Fabrics library itself which is transport independent and handles Fabrics specific commands and variables. Last, we add support for periodic keep-alive mechanism which is mandatory for Fabrics.
For more information, see the linux-(nvme,block,kernel) mailing lists.
http://lists.infradead.org/mailman/listinfo/linux-nvme
The other day I posted about The Journal of Open Engineering, which just started. It ends up there’s another existing similar journal called HardwareX:
“HardwareX is an open access journal established to promote free and open source designing, building and customizing of scientific infrastructure (hardware). HardwareX aims to recognize researchers for the time and effort in developing scientific infrastructure while providing end-users with sufficient information to replicate and validate the advances presented. HardwareX is open to input from all scientific, technological and medical disciplines. Scientific infrastructure will be interpreted in the broadest sense. Including hardware modifications to existing infrastructure, sensors and tools that perform measurements and other functions outside of the traditional lab setting (such as wearables, air/water quality sensors, and low cost alternatives to existing tools), and the creation wholly new tools for either standard or novel laboratory tasks. Authors are encouraged to submit hardware developments that address all aspects of science, not only the final measurement, for example, enhancements…”
The HSA Foundation have just released 1.1 versions of their specs:
“Heterogeneous System Architecture (HSA) Foundation is a not-for-profit industry standards body focused on making it dramatically easier to program heterogeneous computing devices. The consortium comprises various semiconductor companies, tools providers, software vendors, IP providers, and academic institutions that develops royalty-free standards and open-source software.”
http://www.hsafoundation.com/heterogeneous-systems-architecture-foundation-launches-hsa-1-1-specification-multi-vendor-architecture-support/
http://www.hsafoundation.com/hsa-foundation-launches-new-era-of-pervasive-energy-efficient-computing-with-hsa-1-0-specification-release/
http://www.hsafoundation.com/hello-hsa-foundation/
http://www.hsafoundation.com/members/
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.
Firmware Security 
You must be logged in to post a comment.