Uncategorized

TI on embedded SoC security

Where to Start with Embedded Processor Security
July 17th, 2017
By Amrit Mundra, Texas Instruments
The world runs on data, and every bit or byte is a potential target for attack. At the same time, both software and hardware systems are becoming much more complex, connected, and interdependent. And with complexity comes vulnerabilities. The billions or trillions of lines of code and interrelated hardware modules, subsystems, and partitions—all crammed on tiny slices of silicon—are a hacker’s delight.[…]

Figure 1: Security pyramid

 

 

http://eecatalog.com/chipdesign/2017/07/17/where-to-start-with-embedded-processor-security/

Standard
Uncategorized

On the security of signed code…

 

https://hackernoon.com/a-collision-too-perfect-279a47fb5d42

https://firmwaresecurity.files.wordpress.com/2017/07/922fb-0cqj7habpoijzl7zr.png?w=696

Standard
Uncategorized

Quarkslab’s vulnerabilitries in NXP i.MX secure boot

 

Vulnerabilities in High Assurance Boot of NXP i.MX microprocessors
By Guillaume Delugré Iván Arce

This blog post provides details about two vulnerabilities found by Quarkslab’s researchers Guillaume Delugré and Kévin Szkudłapski in the secure boot feature of the i.MX family of application processors [1] built by NXP Semiconductors. The bugs allow an attacker to subvert the secure boot process to bypass code signature verification and load and execute arbitrary code on i.MX application processors that have the High Assurance Boot feature enabled. These bugs affect 12 i.MX processor families. The vulnerabilities were discovered and reported to the vendor in September 2016 and the technical details included in this blogpost were disclosed in a joint Quarkslab-NXP presentation at the Qualcomm Mobile Security Summit 2017 [2] in May 19th, 2017. National computer emergency response teams (CERTs) from 4 countries were informed about the issues in March, 2017. NXP has issued an Engineering Bulletin and two Errata documents (EB00854, ERR010872 and ERR0108873 respectively) [3] providing a brief description of both vulnerabilities, the list of affected processor models along with resolution plans and possible mitigations. In the rest of the blogpost we describe the relevant features in i.MX processors and the vulnerabilities affecting them.[…]InversePath, vendor of USB Armory [6], an affected device confirmed the vulnerabilities and developed proof of concept programs to demonstrate them.[…]

https://blog.quarkslab.com/vulnerabilities-in-high-assurance-boot-of-nxp-imx-microprocessors.html

Break your own product, and break it hard

https://github.com/inversepath/usbarmory/blob/master/software/secure_boot/Security_Advisory-Ref_QBVR2017-0001.txt

Standard
Uncategorized

OSX Book: Vol1 Update (and Vol3 on security)

http://newosxbook.com/2ndUpdate.html

In addition to update of Vol1, I just noticed there’s a Volume 3 on security:
http://newosxbook.com/toc3.html

https://www.amazon.com/gp/product/0991055535/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=0991055535&linkCode=as2&tag=newosxbookcom-20&linkId=da379822ff6f1352b5db7b25abb8a3c6

 

Standard
Uncategorized

Inception: hacking tool exploiting PCI-based DMA

Inception has been around since at least 2014, but I just noticed it. 😦

Inception is a physical memory manipulation and hacking tool exploiting PCI-based DMA. The tool can attack over FireWire, Thunderbolt, ExpressCard, PC Card and any other PCI/PCIe interfaces. Inception aims to provide a relatively quick, stable and easy way of performing intrusive and non-intrusive memory hacks against live computers using DMA. Inception’s modules work as follows: By presenting a Serial Bus Protocol 2 (SBP-2) unit directory to the victim machine over a IEEE1394 FireWire interface, the victim operating system thinks that a SBP-2 device has connected to the FireWire port. Since SBP-2 devices utilize Direct Memory Access (DMA) for fast, large bulk data transfers (e.g., FireWire hard drives and digital camcorders), the victim lowers its shields and enables DMA for the device. The tool now has full read/write access to the lower 4GB of RAM on the victim. Once DMA is granted, the tool proceeds to search through available memory pages for signatures at certain offsets in the operating system’s code. Once found, the tool manipulates this code. For instance, in the unlock module, the tool short circuits the operating system’s password authentication module that is triggered if an incorrect password is entered. […] However, vendors generally dismiss DMA attacks as a non-issue, which I hope that the awareness that this tool generates will change. Users deserve secure devices, even when attackers gain physical access.[…]

https://github.com/carmaa/inception
http://www.breaknenter.org/projects/inception/
http://www.breaknenter.org/2014/09/inception-metasploit-integration/

Standard
Uncategorized

Triton 0.5 released

Triton is a Dynamic Binary Analysis (DBA) framework. It provides internal components like a Dynamic Symbolic Execution (DSE) engine, a Taint Engine, AST representations of the x86 and the x86-64 instructions set semantics, SMT simplification passes, an SMT Solver Interface and, the last but not least, Python bindings.

https://github.com/JonathanSalwan/Triton/milestone/8
https://github.com/JonathanSalwan/Triton
https://triton.quarkslab.com/
https://triton.quarkslab.com/documentation/doxygen/

Triton's architecture

Standard
Uncategorized

ARM IETF ID on IoT firmware update architecture

IETF Internet draft: draft-moran-fud-architecture-00:

A Firmware Update Architecture for Internet of Things Devices
July 18, 2017
Brendan Moran, Milosch Meriac, Hannes Tschofenig
ARM Limited

Vulnerabilities with IoT devices have raised the need for a solid and secure firmware update mechanism that is also suitable for constrained devices. Incorporating such update mechanism to fix vulnerabilities, to update configuration settings as well as adding new functionality is recommended by security experts. This document specifies requires and an architecture for a firmware update mechanism aimed for Internet of Things (IoT) devices. The architecture is agnostic to the transport of the firmware images and associated meta-data. This version of the document assumes asymmetric cryptography and a public key infrastructure. Future versions may also describe a symmetric key approach for very constrained devices.

There’s a mailing list for FUD:

https://www1.ietf.org/mailman/listinfo/fud

https://tools.ietf.org/html/draft-moran-fud-architecture-00

Standard