Category: Uncategorized

UEFI port of CHIP-8 game engine

~ hucktech ~ 1 Comment

There’s a CHIP-8 emulator written for most platforms, now including UEFI. The executable uc8.efi is built using the GNU-EFI toolchain, not the Tianocore toolchain.

“CHIP-8 emulator as an UEFI application”

Usage: uc8 FILE [ROM]

Follow the instructions on your screen. In case of trouble, press Z.

About CHIP-8, Wikipedia says: ”
There are a number of classic video games ported to CHIP-8, such as Pong, Space Invaders, Tetris, and Pac-Man. There’s also a random maze generator available. These programs are reportedly placed in the public domain, and can be easily found on the Internet.”

https://github.com/Reisse/uefi-chip8

https://en.wikipedia.org/wiki/CHIP-8

 

Linux Container hardening

~ hucktech ~ Leave a comment

https://twitter.com/jessfraz/status/827500850691969024

Mission Statement: This project will focus on hardening of Linux containers. It will help contribute patches to the Kernel Self Protection Project that evolve the primitives in the Linux kernel used by containers (namespaces, cgroups, etc) to be more secure. This will include brainstorming, designing and implementing ways to future proof namespaces et all in the kernel. This will benefit all container runtimes by keeping the focus on improving the kernel in the subsystems used by containers. We will strive to push the entire container ecosystem to be more secure by fixing the ground they are built upon. Much like the Kernel Self Protection Project we think of security beyond fixing bugs. Fixing bugs is important and we will do that as well but the main value will come from finding ways to future proof namespaces with features that will eliminate undisclosed vulnerabilities. At this point, it is no longer enough to try to fix all the bugs within namespaces, we must try to find ways to make them more secure from the very foundation. We will also work to help educate people on how to use the features of Capabilities, Seccomp, AppArmor, and SELinux to harden their containers. We will try to find ways to make them more accessible to more users.

https://containerhardening.org/

CHIPSEC talk at OPCDE 2017

~ hucktech ~ Leave a comment

Exploring Your System Deeper
 Oleksandr Bazhaniuk – Intel – United States

You wanted to explore deep corners of your system but didn???t know how? System boot firmware, ROMs on expansion cards, I/O devices and their firmware, microprocessors, embedded controllers, memory devices, low-level hardware interfaces, virtualization and hypervisors. You could discover if any of these have known vulnerabilities, configured insecurely or even discover new vulnerabilities and develop proof-of-concept exploits to test these vulnerabilities. Ultimately, you can verify security state of platform components of your system and how effective are the platform security defenses: hardware or virtualization based TEE, secure or trusted boot, firmware anti-tampering mechanisms, hypervisor based isolation… Or maybe you just want to explore hardware and firmware components your system has. CHIPSEC framework can help you with all of that. Since releasing it three years ago at CanSecWest 2014 significant improvements have been made in the framework – from making it easy to install and use to adding lots of new security capabilities. We’ll go over certain representative examples of what you can do with it such as finding vulnerabilities in SMM firmware, analyzing UEFI firmware vulnerabilities, testing hardware security mechanisms of the hypervisors, finding backdoors in UEFI images and more.

 

http://www.opcde.com/speakers.html

ACPI graph support

~ hucktech ~ Leave a comment

Sakari Ailus of Intel posted a patch to the Linux-ACPI list that enables ‘ACPI graph support’. Slightly edited version of announcement below:

I posted a previous RFC labelled set of ACPI graph support a while ago[1]. Since then, the matter of how the properties should be used as in ACPI _DSD was discussed in Ksummit and LPC, and a document detailing the rules  was written [1]. I’ve additionally posted v1 which can be found here[2]. This set contains patches written by Mika Westerberg and by myself. The patchset brings support for graphs to ACPI. The functionality achieved by these patches is very similar to what the Device tree provides: the port and the endpoint concept are being employed. The patches make use of the _DSD property and data extensions to achieve this. The fwnode interface is extended by graph functionality; this way graph information originating from both OF and ACPI may be accessed using the same interface, without being aware of the underlying firmware interface. The last patch of the set contains ASL documentation including an example. The entire set may also be found here (on mediatree.git master, but it also applies cleanly on linux-next)[3]. The resulting fwnode graph interface has been tested using V4L2 async with fwnode matching and smiapp and omap3isp drivers, with appropriate changes to make use of the fwnode interface in drivers. The V4L2 patches can be found here. The fwnode graph interface is used by the newly added V4L2 fwnode framework which replaces the V4L2 OF framework, with equivalent functionality.[4]

[1] http://www.spinics.net/lists/linux-acpi/msg69547.html
[2] http://www.spinics.net/lists/linux-acpi/msg71661.html
[3] https://git.linuxtv.org/sailus/media_tree.git/log/?h=acpi-graph
[4] https://git.linuxtv.org/sailus/media_tree.git/log/?h=v4l2-acpi

Full announcement — including changes for v1 — is on the linux-acpi list:
http://vger.kernel.org/majordomo-info.html
http://www.spinics.net/lists/linux-acpi/

Olimex releases TERES I, open source hardware ARM laptop

~ hucktech ~ Leave a comment

We are proud to announce that our TERES I laptop is complete. We have assembled units and now working on the software. The building instructions are uploaded here and you can see that it’s pretty easy to build one yourself. This weekend in Bruxell at FOSDEM we will have table in Hall AW where every one could touch and play with the very first built laptops. All spare parts are uploaded at the web. Hardware CAD files and Linux build scripts are on GitHub. TERES I is completely designed with KiCAD FOSS so everyone can download and learn, study, edit, modify. Hardwarewise everything is OK and works, the software need some care to be completed, power supply management, Linux distribution, and few more details need attention, but we hope everything to be complete till Friday!

TERES I was the first king of the Odrysian state of Thrace where Plovdiv is also located.

One of the files on github mentions:

In progress
To Do
[…]
* Clean binary blobs if possible
[…]

https://www.olimex.com/Products/DIY%20Laptop/KITS/
https://github.com/OLIMEX/DIY-LAPTOP

TERES I Do It Yourself Open Source Hardware and Software Hacker’s friendly laptop is complete

PCI-Expansion-ROM-OS moves to github

~ hucktech ~ Leave a comment

Quoting the post:

Experimental PCI Expansion ROM “OS” Code Migrated to GitHub
The code for the experimental PCI Expansion ROM “OS” explained in the Building a “Kernel” in PCI Expansion ROM article is now in GitHub: https://github.com/pinczakko/PCI-Expansion-ROM-OS. I made some changes to make it compile-able in current version of Nasm and GCC. I’ve only tested the compilation in Arch Linux (x86-64). I’m not sure it will work in other Linux distros. Give it a try ;-). Quick skim over the resulting binary seems to indicate the result is OK. I’m going to check it with a disassembler later on. If anyone wants to help me with that, please do so and post your result in the comment section below.  Many of you might be aware that the code has been modified into pure GCC-only code in the Low Cost Embedded x86 Teaching Tool article. I need to migrate that code as well. But, I’m quite sure it will require special GCC version to be able to emit the correct binary, akin to the one used by Coreboot. I’ll post an update once I’ve updated that one as well.  Anyway, it’s rather surprising to me that using Nasm + GCC is more future-proof compared to using GCC alone. It shows that you can’t be really sure about the future-proof-ness of the toolset you used for software development.

http://bioshacking.blogspot.com/2017/01/experimental-pci-expansion-rom-os-code.html

https://github.com/pinczakko/PCI-Expansion-ROM-OS

https://sites.google.com/site/pinczakko/building-a-kernel-in-pci-expansion-rom

https://sites.google.com/site/pinczakko/low-cost-embedded-x86-teaching-tool-2

DMTF releases DASH Conformance Test Suite 2.0

~ hucktech ~ Leave a comment

DMTF has just released version 2.0 of the Conformance Test Suite (CTS) for its Desktop and mobile Architecture for System Hardware (DASH) standard.  DASH provides secure out-of-band and remote management of desktop and mobile systems. The DASH CTS serves to improve interoperability by validating conforming implementations. The new DASH CTS 2.0 includes the necessary updates, policies and procedures to test the latest DASH specifications, which address current requirements for managing modern hardware in a networked environment. With DASH CTS 2.0, companies can continue to self-test their implementations and submit digitally signed results to the DASH Conformance Program Administrator (an independent third party) for validation. Once validated, participants can have their submission information included in the DMTF Certification Registry.[…]

ttps://www.dmtf.org/content/dmtf-releases-dash-conformance-test-suite-20

https://www.dmtf.org/standards/dash
http://www.dmtf.org/conformance/dash
http://www.dmtf.org/join/smf

 

Utimaco firmware reversing tools

~ hucktech ~ Leave a comment

Utimaco Firmware Tools: These are a couple of tools for reverse engineering the Utimaco Firmware, plus an exploit for a simple vulnerability. All of these tools were presented at my Recon Brussels 2017 talk. You can find the presentation at my website.Tools:
* fwtools/ : Firmware tools
* exploit/ : A simple exploit
* tms320c64x/ : Various files regarding the TMS320C64x architecture
https://github.com/fotisl/utimaco
https://fotisl.com/reverse/utimaco/recon2017/#/
https://recon.cx/2017/brussels/talks/hackable_security_modules.html

2017 NetFPGA open source design challenge

~ hucktech ~ Leave a comment

“We are pleased to announce the 2017 NetFPGA Design Challenge! NetFPGA platforms are used by the networked systems community for close to a decade. The platforms enable researchers and instructors to build high-speed, hardware-accelerated networking systems. The platforms can be used by researchers to prototype advanced services for next-generation networked systems. By using Field Programmable Gate Arrays (FPGAs), NetFPGA enables new types of packet routing circuits to be implemented and detailed measurements of network traffic to be obtained. The NetFPGA 2017 contest is a design challenge. The design teams are to produce a working implementation employing any HW and SW design methodology and targeting the NetFPGA SUME platform. The deadline for submissions is April 13th, 2017. The winners will be announced at the NetFPGA Developers Summit (Thursday 20th – Friday, 21st April, 2017 Cambridge, UK).  […]

http://www.cl.cam.ac.uk/research/srg/netfpga/challenge2017
http://www.netfpga.org

LUV gets telemetrics

~ hucktech ~ Leave a comment

Megha Dey of Intel just submitted a 4-part patch to LUV, adding telemetrics. Below is slightly-edited comments from patch, some build instructions omitted. For full text see email, URL at end.

[Luv] [PATCH V1 0/4] Introduce telemetrics feature in LUV

This patchset consists of all the patches needed to enable the telemetrics feature in LUV. LUV brings together multiple separate upstream test suites into a cohesive and easy-to-use product and validates UEFI firmware at critical levels of the software stack. It may be possible that one of the test suites crashes while running. It may be even possible that a kernel panic is observed. Under these scenarios, it would be useful for LUV to call home and submit forensic data to analyze and address the problem. The telemetrics feature will do just this.  Of course, this will be an opt-in feature(command line argument telemetrics.opt-in) and users will get clear indication that data is being collected. We have used the telemetrics-client code developed by the clear-linux team and tried to incorporate it in LUV. It has support for crashprobe (invoked whenever a core dump is created), oopsprobe(invoked when there is a kernel oops observed) and pstore-probe(invoked when there is a kernel panic and system reboots). In any of these scenarios, telemetrics records will be sent to the server, currently residing at(one used by clear linux):
 http://rnesius-tmdev.jf.intel.com/telemetryui/
The build ID 122122 can be used to filter the LUV telemetrics records which can be further analysed. In due course, we will have to implement a server of our own to handle this. For telemetrics to work in LUV, the following changes were needed:

1. Migrate to SystemD: LUV currently uses the SystemV init manager but since telemetrics-client repo and the latest yocto have updated on to SystemD, LUV also needs to migrate to SystemD. Since Systemd will not work with the existing psplash graphical manager, we have disabled the splash screen

2.    Migrate to Plymouth: LUV currently uses the psplash graphical manager, but since SystemD is compatible with only Plymouth graphical manager, we have migrated to Plymouth. PLEASE NOTE: Before migrating to plymouth, we have to merge the morty branch of the meta-oe layer provided by open embedded into the LUV repo and add the meta-oe layer to the build/conf/bblayers.conf file. Here are the steps to do this: <omitted> The loglevel has been set to 0 else there are lots of kernel messages overwriting the plymouth screen. Hence, details about the individual tests in the testsuites will not appear when the splash screen is set to false when using plymouth. If the user wants the test details to be shown, they would have to remove the ‘quiet’ and ‘loglevel=0’ kernel command line parameters.

3. Enable networking: After shifting to systemD, the LUV image is not being assigned an IP on boot. This is because it is still using a systemV startup script to do the same. Since systemD names its interfaces differently, we could not see any interfaces with a valid IP. This patch adds the networkd package, introduces a network config file which starts dhcp by default for all interfaces whose names start with en(pci devices which get renamed by udev) or eth(backward compatible) and a service file (networking.service) which will bring up the network and make sure an IP is assigned during boot. It refers:
    https://wiki.archlinux.org/index.php/systemd-networkd

4. Enable telemetrics in LUV: A yocto recipe which fetches the clear-linux telemetrics-client repo, builds it and installs all the necessary service files, daemons and probes has been added. Also, Add a kernel line parameter which lets the user opt-in to the telemetrics feature (telemetrics.opt-in). By default, this feature is disabled. Currently, the telemetrics records can be found here: http://rnesius-tmdev.jf.intel.com/telemetryui/

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

CVE-2016-8226, Lenovo UEFI DoS

~ hucktech ~ Leave a comment

CVE Identifier: CVE-2016-8226
Access Vector: Network exploitable
Access Complexity: Low
Original release date: 01/26/2017

The BIOS in Lenovo System X M5, M6, and X6 systems allows administrators to cause a denial of service via updating a UEFI data structure.

 

Lenovo Security Advisory: LEN-11306
Denial of service attack on Lenovo System X M5, M6, and X6 systems
 
A vulnerability was identified in the BIOS of Lenovo System X M5, M6, and X6 systems. An attacker with administrative access to a system can cause a denial of service attack on the system by updating a UEFI data structure. After this occurs, the system will not complete POST (Power-On Self-Test) , hang at the Lenovo splash screen, and fail to boot. This issue was inadvertently encountered in an update to Microsoft Windows Server 2012, Windows Server 2012R2 and Windows Server 2016 (see https://support.lenovo.com/us/en/solutions/ht502912 for details). However, systems running any operating system are vulnerable. Lenovo strongly recommends installing this update. Mitigation Strategy for Customers (what you should do to protect yourself):[…]
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-8226

https://support.lenovo.com/us/en/solutions/LEN-11306

 

Schneier: avoid Intel/AMD hardware, Intel ME, and UEFI

~ hucktech ~ 1 Comment

[[UPDATE: See comment from one reader, I mistakingly took below quote to be from Bruce, where it is apparently from someone else. Oops.]]

Bruce Schneier has a new blog post on citizen cybersecurity, including advice for non-US citizens to avoid blobs in firmware.

I hope Intel and AMD are reading this. Are the patents in the IP you’re protecting in your FSP and AGESA binaries really worth the security risks you’re enabling for attackers to all of your systems? Open-sourcing your blobs will reduce this attack vector and make your products more trustworthy, and reduce the potential market loss to RISC-V and OpenPOWER, which by contrast to Intel/AMD have blob-free firmware potential.  In addition to criminal use by cybercriminals, backdoors can be “legally” misused by tyrants, bigly. Hidden backdoor management processes like Intel ME should be owner-controllable, including the ability to remove/disable it. How can I use NIST 147 guidance to check the hashes of the hundreds of blobs within the FSP/AGESA packages? The are numerous supply-chain opportunities for firmware attackers to subvert these blobs, at the IHV, OEM, ODM, IBV, some of which also have source access to these packages and modify them (for example Purism modifies FSP for their laptops, but they can’t publish their code, due to Intel NDA).

New Rules on Data Privacy for Non-US Citizens”
[…]
“- build firewalls everywhere, if possible based on non-Intel, non-AMD too, hardware platforms or at least supporting old, non-Intel ME and non-UEFI, firmware;”

I

New Rules on Data Privacy for Non-US Citizens

 

See-also:

ITL’s Stateless Laptop proposal

faking virtual firmware to thwart malware authors

~ hucktech ~ Leave a comment

Thomas Roccia write a new blog post on watching how malware detects VM’s virtualized hardware/firmware resources, including a defensive POC and a pointer to a similar tool.

Stopping Malware With a Fake Virtual Machine
As we explained in a previous post, some advanced malware can detect a virtual environment such as a sandbox to avoid detection and analysis. Some threats can also detect monitoring tools used for malware analysis. Often such malware will not execute or change their behavior to appear harmless. Because some malware uses these tactics, planting fake virtual machine artefacts or fake analysis tools on a system could stop their malicious behavior. We have created a quick proof of concept (POC) to demonstrate this defensive tactic. […] A lot of registry keys are created by specific tools or by sandbox emulation. Using the Windows API RegCreateKeyEx we can create all the (fake) keys normally created by a virtual hypervisor. The following list shows of few of the potential registry keys that malware can detect:
    HKLM\HARDWARE\DEVICEMAP\Scsi\Scsi Port 0\Scsi Bus 0\Target Id 0\Logical Unit Id 0\“Identifier”;“VMWARE”
    HKLM\SOFTWARE\VMware, Inc.\VMware Tools
    HKLM\HARDWARE\Description\System\ “SystemBiosVersion”;”VMWARE”
    HKLM\HARDWARE\Description\System\”SystemBiosVersion”;VBOX
    HKLM\SOFTWARE\Oracle\VirtualBox Guest Additions
    HKLM\HARDWARE\ACPI\DSDT\VBOX__

https://securingtomorrow.mcafee.com/mcafee-labs/stopping-malware-fake-virtual-machine/

https://github.com/fr0gger/RocProtect-V1

 

 

SHDesigns Rabbit ICS boards don’t authenticate firmware downloads

~ hucktech ~ Leave a comment

Vulnerability Note VU#167623
SHDesigns Resident Download Manager does not authenticate firmware downloads
CWE-494: Download of Code Without Integrity Check – CVE-2016-6567
SHDesigns’ Resident Download Manager (as well as the Ethernet Download Manager) does not authenticate firmware downloads before executing code and deploying them to devices. SHDesigns’ Resident Download Manager provides firmware update capabilities for Rabbit 2000/3000 CPU boards, which according to the reporter may be used in some industrial control and embedded applications. The Resident Download Manager does not verify that the firmware is authentic before executing code and deploying the firmware to devices. A remote attacker with the ability to send UDP traffic to the device may be able to execute arbitrary code on the device. According to SHDesigns’ website, the Resident Download Manager and other Rabbit Tools have been discontinued since June 2011.

http://www.kb.cert.org/vuls/id/167623
http://shdesigns.org/rabbit/

guestrace: VM guess whole-system-call tracer

~ hucktech ~ Leave a comment

guestrace: A whole-system system-call tracer for VM guests
Ryan Johnson began writing guestrace as a prototype for a research project. Since then, we have packaged guestrace as a stand-alone utility. A properly-configured guestrace will print as they occur the system calls which processes invoke within a guest host. The guestrace utility relies on libvmi to perform virtual-machine introspection. Guestrace also provides a library, libguestrace, which gives programmers access to the guestrace engine. This is useful for programs which must trace system calls and do more than merely print them. […]

https://www.flyn.org/projects/guestrace/index.html

aboot-parser: Android bootloader parser

~ hucktech ~ Leave a comment

Script to parse Android bootloader (aboot) images, extract certificates and verify image signature. May not work on aboot from latest devices. Signature verification follows the ‘Secure Boot and Image Authentication Technical Overview’ whitepaper by Qualcomm. Cf.  https://www.qualcomm.com/documents/secure-boot-and-image-authentication-technical-overview/ Aboot header format as described in  http://newandroidbook.com/Articles/aboot.html See above article for more details about aboot. Inspired by https://github.com/kayrus/kc_s701_break_free
[…]

https://github.com/nelenkov/aboot-parser