Copperhead OS blocked by missing Google Nexus blobs

Copperhead OS is a hardened verison of Android, including PaX and other security features beyond ASOP, mainly targetting Google Nexus devices. It appears they’re having some problems with availability of ASOP blobs from Google on some new Nexus devices:

https://copperhead.co/android/
https://copperhead.co/docs/technical_overview
https://github.com/copperheados

Hardware Club’s resource directory

The Hardware Club is a site for hardware startups. They have a resource directory that has a few interesting links.

http://directory.hardwareclub.co/

Contents:

    / Prototyping
    / Design_Agencies
    / Accelerators
    / Crowdfunding
    / Crowdfunding_Agencies
    / Video_Agencies
    / PR_Agencies
    / Manufacturing
    / Logistics
    / Distribution
    / Trade_Shows
    / Venture_Capital_Firms
    / Good_Reads

AVR reversing

There’s a new presentation on AVR reversing available!

 

Strange, WordPress seems to normally render slideshare.net-based URLs to show the first slide of the slide deck. WordPress is instead showing a blank rectangle, with an URL below it….

Why no ExitRunTimeServices() for UEFI?

The other week, at the 3rd RISC-V Workshop, there were 2 firmware presentations, coreboot and UEFI, pitching their solution for the new RISC-V chip.

One point mentioned in the coreboot presentation that seems worth raising here on a firmware security blog: the distinction between firmware that fully exits -vs- firmware that stays resident while the operating system runs. An interesting way to frame it.

Click to access Tues1345%20riscvcoreboot.pdf

Starting with the IBM PC’s BIOS, Intel systems have had firmware that runs in the background. The OS or an ap would issue a BIOS (or DOS) interrupt, and the BIOS responded to low-level interrupts, like Int 13h for disk, 10h for video, etc. On original PCs, IHVs extended BIOS via Option ROMs via the same extensibility method that IBM PC-DOS ‘services’ (TSRs, ‘terminate and stay resident’) used: hook an interrupt and replace it with yours. So, BIOS is kind of a ‘terminate and stay resident’ firmware.

UEFI uses the same model, presuming firmware to be present in background for OS to call, the resident portion are called UEFI RunTime Services. Once the operating system initializes, it calls UEFI’s ExitBootServices() function, which terminate most — but not all — of UEFI, discarding the init code and only keeping the runtime service code.

http://wiki.phoenix.com/wiki/index.php/EFI_BOOT_SERVICES#ExitBootServices.28.29

Coreboot — and U-Boot — initialize the hardware, but do not stay resident. However, on Intel systems, use of a BIOS payload in coreboot, eg, SeaBIOS, will result in that BIOS payload staying resident, responding to BIOS interrupts that the OS (or an app) may call.

So, the resident -vs- nonresident firmware seems to be tied to Intel -vs- non-Intel: coreboot on ARM for example has no SeaBIOS payload, and RISC-V likey won’t use an Intel-centric BIOS payload.

As the coreboot presentation points out, the resident firmware is an additional attack vector, UEFI has a larger surface than coreboot — or U-Boot — due to UEFI Runtime Services. UEFI currently only  has the option to terminate Boot Time Services — via ExitBootServices(). I wonder if UEFI could have an additional mode, with an ExitRuntimeServices(), that could make UEFI competitive with coreboot/U-Boot w/r/t attack surface? That could be interesting.

EDK-II upcoming Github changes

Laurie Jarlstrom of Intel announced on the EDK-II list about upcoming Sourceforge to Github hosting changes:

This message is an update on the transition from SourceForge to GitHub for EDK II development.  The schedule is currently targeting the last week of January or the first week of February to perform the transition.  The transition process should only take one to two days to complete.  A notification message will be sent the week prior to the actual dates that the repositories will be impacted.  This should provide adequate notification for the scheduled down time. As part of this transition some documentation and process changes have been required.  The updated process as well as other GitHub specific information can be found on the tianocore Wiki at the link provided below.  Feedback on this documentation is welcome and needed to make sure the transition is as smooth as possible.

https://github.com/tianocore/tianocore.github.io/wiki/SourceForge-to-Github-Quick-Start

Full message:
http://article.gmane.org/gmane.comp.bios.edk2.devel/6616

SeaBIOS gets TPM2 security

BIOS was designed in the era of the initial IBM PC, running IBM PC-DOS — when DOS meant Disk Operating System not Denial of Service — back when there was no security in any hardware, firmware, or software designs. 🙂 As  UEFI documentation likes to mention, BIOS has no security, unlike UEFI (well, at least v2, EFI v1 had much less security). But SeaBIOS, the open source BIOS implementation, has had TPMv1 support for BIOS (and ACPI) since 2011, and today it just got TPMv2 support! It appears that initial TPMv1 support was added to SeaBIOS in 2011 by Stefan Berger of IBM, including TPM support for ACPI; excerpt from his patch email:


The following set of patches add TPM and Trusted Computing support to SeaBIOS. In particular the patches add:

– a TPM driver for the Qemu’s TPM TIS emulation (not yet in Qemu git)
– ACPI support for the TPM device (SSDT table)
– ACPI support for measurement logging (TCPA table)
– Support for initialzation of the TPM
– Support for the TCG BIOS extensions (1ah handler [ah = 0xbb]) (used by trusted grub; http://trousers.sourceforge.net/grub.html)
– Static Root of Trusted for Measurement (SRTM) support
– Support for S3 resume (sends command to TPM upon resume)
– TPM-specific menu for controlling aspects of the TPM
– [An optional test suite for the TIS interface]

All implementations necessarily follow specifications.

When all patches are applied the following services are available
– SSDT ACPI table for TPM support
– initialization of the TPM upon VM start and S3 resume
– Static root of trust for measurements (SRTM) that measures (some) data of SeaBIOS in TCPA ACPI table
– 1ah interrupt handler offering APIs for measuring and sending commands to the TPM (trusted grub uses them)
– User menu for controlling aspects of the state of the TPM

Full message:
http://www.seabios.org/pipermail/seabios/2011-April/001609.html
https://lists.gnu.org/archive/html/qemu-devel/2011-08/msg03835.html

Steven has an article on the QEMU wiki on SeaBIOS TPMv1 support. And Stephan has a SeaBIOS-TPM project on Github, I’m unclear how this relates to SeaBIOS source tree:
http://wiki.qemu.org/Features/TPM
https://github.com/stefanberger/seabios-tpm

So, that was the old 2011 TPMv1 news, that I am catching up to…. Today, Stephan has a new TPM2 patch for SeaBIOS, excerpt of announcement:

This series of patches adds TPM 2 support to SeaBIOS in the way previously proposed. TPM 2 support also changes the log entry format, which I have not addressed at all so far, and would append to the end of the series.

  tpm: Extend TPM TIS with TPM 2 support.
  tpm: Factor out tpm_extend
  tpm: Prepare code for TPM 2 functions
  tpm: Implement tpm2_startup and tpm2_s3_resume
  tpm: Implement tpm2_set_timeouts
  tpm: Implement tpm2_prepboot
  tpm: Implement tpm2_extend
  tpm: Implement tpm2_menu
  tpm: Implement TPM 2’s set_failure

Full message:
http://www.seabios.org/mailman/listinfo/seabios

Also search the recent checkins for other interesting TPM checkins, eg, Physical Presence API, etc.

I asked on the SeaBIOS list if there was a security roadmap for me to point to, and what consumer devices have TPM support; Kevin O’Connor replied, mentioning the addition of TPMv2, and:

I’m not aware of any new consumer devices shipping with the support, and I understand that KVM/QEMU have had TPM support for some time already.

I think some Google Chromebooks come with coreboot-based TPM-enabled SeaBIOS, and TPM is used to store developer mode state instead of CMOS. I haven’t found canon spec in ChromeOS site, but there are a few online references such as this:
https://news.ycombinator.com/item?id=9185719

I’m not aware of any new consumer devices shipping with the support. If you have a new system, check with the vendor to see if it supports TPM or not. If your BIOS is not SeaBIOS-based, check if it has TPM support; if not, ask the vendor why not.

It would be interesting for a security researcher to compare the BIOS security measures in currently-available consumer devices, SeaBIOS-based and other BIOS codebases. I am not sure how many different BIOS codebases there are, these days. Perhaps AMI and Phoenix have one, and some OEMs? I should research that more. Ralph Brown: help! 🙂

http://www.seabios.org/

Subgraph OS alpha announced

The new Subgraph operating system is expected to have Alpha release in March, excerpt of latest blog post is below:

Subgraph OS Announcement

We are happy to announce that Subgraph is to receive support for 12 months of Subgraph OS development from the Open Technology Fund.

This means that we will be able to focus our efforts over the next year on development exclusively.

Our current areas of focus are:

    Oz, our framework for application isolation

    Tooling and automation for builds and tests of Subgraph OS packages as well as for the base OS image. We are working towards a downloadable ISO as soon as possible.

All of our code is to be hosted on Github, though for now everything there is very alpha. We invite the community to check it out.

https://subgraph.com/blog/index.en.html

https://subgraph.com/

Dan Luu on CPU bugs

We Saw Some Really Bad Intel CPU Bugs in 2015, and We Should Expect to See More in the Future

2015 was a pretty good year for Intel. Their quarterly earnings reports exceeded expectations every quarter. They continue to be the only game in town for the serious server market, which continues to grow exponentially; from the earnings reports of the two largest cloud vendors, we can see that AWS and Azure grew by 80% and 100%, respectively. That growth has effectively offset the damage Intel has seen from the continued decline of the desktop market. For a while, it looked like cloud vendors might be able to avoid the Intel tax by moving their computation onto FPGAs, but Intel bought one of the two serious FPGA vendors and, combined with their fab advantage, they look well positioned to dominate the high-end FPGA market the same way they’ve been dominating the high-end server CPU market. Also, their fine for anti-competitive practices turned out to be $1.45B, much less than the benefit they gained from their anti-competitive practices1. […]”

http://danluu.com/cpu-bugs/

UEFI-Paging: turns on page fault int handler on 32-bit systems

Szymon Kłos has created UEFI-Paging, a new project on Github, which “turns on paging in the 32-bit UEFI, Page Fault interrupt handler.” Not much documentation, a 1-line readme (in quotes in last sentence); Paging.c has the help for the interactive commands:

help – show help
write – write bytes to memory {hex}
read – read bytes from memory
map – map logical address
notpresent – set pae as not present
exit

Tunring on paging in the 32-bit UEFI, Page Fault interrupt handler

https://github.com/eszkadev/UEFI-Paging/blob/master/Paging.c

https://github.com/eszkadev/UEFI-Paging

DMTF Open Software Defined Data Center (OSDDC)

The DMTF has released a new spec, for the software-defined data center, and the spec has firmware implications (eg, firmware updates).

The Open Software Defined Data Center (OSDDC) Incubator recently released the white paper,  “Software Defined Data Center Definition 1.0,”  reviewing industry standards for the Software Defined Data Center (SDDC). The paper outlines use cases, definitions, and identifies existing standards gaps, as well as possible architectures for the various implementations of SDDC.

Click to access DSP-IS0501_1.0.0.pdf

https://www.dmtf.org/standards/osddci

Click to access OSDDC_Incubator_Charter_2013-3-29.pdf

Win10 for ARM?

It sounds like non-embedded Windows may end up being available for platforms outside Intel again. Long ago, Microsoft Windows NT supported MIPS, Alpha, PowerPC, Itanium, as well as x86/x64. Embedded Windows supported many other processors, including ARM. And Microsoft already has ARM-based Surface devices, and Windows 10 for ARM-based RPI2.

http://www.winbuzzer.com/2016/01/14/rumor-microsoft-to-offer-windows-10-desktop-edition-for-arm-architecture-xcxwbn/
https://twitter.com/h0x0d/status/687501104947400704
https://msdn.microsoft.com/en-us/windows/hardware/dn940797%28v=vs.85%29.aspx
http://www.ubergizmo.com/2016/01/microsoft-might-be-developing-windows-10-for-arm-based-processors/
http://www.windowscentral.com/desktop-version-windows-10-arm-based-chips-might-be-development

 

 

RET-Sync: multi-debugger tool for IDA Dissassembler

ret-sync stands for Reverse-Engineering Tools synchronization. It’s a set of plugins that help to synchronize a debugging session (WinDbg/GDB/LLDB/OllyDbg2/x64dbg) with IDA disassembler. The underlying idea is simple: take the best from both worlds (static and dynamic analysis).

From debuggers and dynamic analysis we got:

    local view, with live dynamic context (registers, memory, etc.)
    built-in specialized features/API (ex: Windbg’s !peb, !drvobj, !address, etc.)

From IDA and static analysis we got:

    macro view over modules
    code analysis, signatures, types, etc.
    fancy graph view
    persistent storage of knowledge within IDBs

Keys features:

    Pass data (comment, command output) from debugger to disassembler (IDA)
    Multiple IDBs can be synced at the same time allowing to easily trace through multiple modules
    No need to deal with ALSR, addresses are rebased on-the-fly
    IDBs and debugger can be on different hosts

ret-sync is a fork of qb-sync that I developed and maintained during my stay at Quarkslab.

https://github.com/bootleg/ret-sync
https://github.com/quarkslab/qb-sync

FWTS 10.01.00 released

Ivan Hu of Canonical announced the 10.01.00 release of FWTS, the FirmWare Test Suite, which uses a fresh ACPIC, and includes with some new ACPI and UEFI test features, including supporting some new UEFI 2.5 variables.

Significant Updates:
* ACPICA: Update to version 20160108 (LP: #1532268)

New Features:
* acpi: method: add _PTC test
* sync with uefi 2.5 global variables
* uefidump: add dumping global variabl AuditMode
* uefidump: add dumping global variabl DeployedMode
* uefidump: add dumping global variable OsRecoveryOrder
* uefidump: add dumping global variable PlatformRecovery####
* uefidump: add dumping global variable SysPrepOrder
* uefidump: add dumping global variable SysPrep####
* ACPICA: Update to version 20151218 (LP: #1527733)
* esrtdump: add dumping for esrt table (LP: #1532103)

See full changelog for list of bugs fixed.

http://fwts.ubuntu.com/release/fwts-V16.01.00.tar.gz
https://launchpad.net/~firmware-testing-team/+archive/ubuntu/ppa-fwts-stable
https://wiki.ubuntu.com/FirmwareTestSuite/ReleaseNotes/16.01.00
https://launchpad.net/ubuntu/+source/fwts
https://lists.01.org/pipermail/luv/2016-January/000777.html

new Linux/SeaBIOS version of SMM rootkit, The Watcher

https://twitter.com/scumjr_/status/687449895779856384

From SMM to userland in a few bytes

In 2014, @coreykal, @xenokovah, @jwbutterworth3 @ssc0rnwell gave a talk entitled Extreme Privilege Escalation on Windows 8/UEFI Systems at Black Hat USA. They introduced the idea of a SMM rootkit called The Watcher slides (57 to 63). To sum it up:

        The Watcher lives in SMM (where you can’t look for him)
        It has no build-in capability except to scan memory for a magic signature
        If it finds the signature, it treats the data immediately after the signature as code to be executed
        In this way the Watcher performs arbitrary code execution on behalf of some controller.

This idea is awesome, and I wanted to try to implement it on Linux. Actually, it was far more easier than expected, thanks to QEMU and SeaBIOS.

[…]

Conclusion

The idea of The Watcher is practical on Linux: it’s pretty straightforward to execute code in userland from SMM reliably, thanks to VDSO. The code of SeaBIOS is modified to include a malicious SMI handler, and the memory of the OS is never altered until the attacker manages to put the payload in memory. The payload size is no longer than 1084 bytes, and can be injected through the network even if not port is open. Nevertheless, SeaBIOS’ SMM support is basic, and I didn’t find a way to automatically install The Watcher at the boot of the machine (there should be a more elegant way than a bootkit). At present, a SMI must be issued (outb(0xXY, 0xb2)) to start The Watcher. The code of this proof-of-concept is available on github: the-sea-watcher.

https://scumjr.github.io/2016/01/10/from-smm-to-userland-in-a-few-bytes/

also, check out the earlier blog post:

https://scumjr.github.io/2016/01/04/playing-with-smm-and-qemu/

AMD, Zen, and coreboot

There is speculation about AMD support of coreboot on Zen systems:

http://techfrag.com/2016/01/11/exclusive-amd-wont-support-coreboot-for-new-zen-processors/

“However, one thing we’re still confused about is whether the next-gen platform will support Coreboot as an optional open-source firmware to replace the proprietary UEFI/BIOS.”

http://www.phoronix.com/scan.php?page=news_item&px=AMD-Zen-Will-It-Coreboot

“More worrying about the prospects for Coreboot on future hardware is that since the end of 2014, AMD stopped providing open-source AGESA code. AGESA releases by AMD are now binary-only, with this being the bootstrap protocol needed to initialize AMD processor cores, memory, and HyperTransport. Binary AGESA is similar to Intel not opening up their firmware support packages.”

From an email-based interview I did with AMD’s firmware engineer, I get the impression that AMD has chosen UEFI as it’s main firmware, and coreboot is part of the AMD embedded team’s options:

AMD clarifies firmware strategy

AMD’s evolution from legacy BIOS to UEFI has happened over the last ten years in sync with the schedules of our industry partners (IBV’s, OEM’s) and their code bases.  We’re not seeing any demand for legacy BIOS enablement anymore, so we no longer focus any effort there.  Coreboot is the only remaining legacy code base we enable.  Coreboot enablement is provided by AMD’s embedded group for a market-appropriate subset of our chips.

 

IBV Sage Engineering

A while ago, the web site for Sage Electronic Engineering LLC went down.

I notice in recent Phoronix post it mentions that Sage went out of business:

https://www.phoronix.com/scan.php?page=news_item&px=AMD-Zen-Will-It-Coreboot

I’m unclear when they stopped operations, perhaps last July, when Jeff left?

Jeff Thomas leaves Sage Engineering

This is a damn shame, they were a very open source-friendly IBV, now there are none. I had the chance to meet their CTO when they were at the Intel Minnowboard booth at LinuxFestNorthWest.org. I hope they re-emerge and continue providing open source-friendly IBV services.

https://www.linkedin.com/company/sage-electronic-engineering

http://iotsolutionsalliance.intel.com/member-roster/sage-electronic-engineering-llc

http://wiki.minnowboard.org/SageBIOS

http://web.archive.org/web/*/http://www.se-eng.com/

Open Hardware Summit 2016 date announced

The date/location for the 2016 Open Hardware Summit has been announced:

October 7, 2016

Portland, Oregon

Here’s their definition of Open Source Hardware:

Definition (English)

Drew has a new blog post on why OSH matters:

Open Source Hardware (OSHW), why it matters and what is pseudo OSHW

I wonder why (OSHWA, Linux Foundation, FreeBSD Foundation, Free Software Foundation) isn’t involved with local communities like Hackster, focusing on OSH subset of hardware (and the FSF definition of Free Hardware), and work on crowdfunding of new devices with these projects, perhaps as Open Compute Projects, not just random ‘blinky lights’ artsy ‘open hardware’. Maybe the enterpreneurs that run Hackster should get involved, projects for them, and may be able to help with this cat herding problem with their platform, perhaps in conjunction with CrowdSupply…

https://www.hackster.io/

Whole Library (or Program) LLVM

Tristan Ravitch has a nice tool on github called Whole Program LLVM, or WWLVM (Whole Library LLVM), and talks about it in a recent blog post, using it to find defects in libOTR. From the github readme:

“WLLVM provides tools for building whole-program (or whole-library) LLVM bitcode files from an unmodified C or C++ source package. It currently runs on *nix platforms such as Linux, FreeBSD, and Mac OS X. WLLVM provides python-based compiler wrappers that work in two steps. The wrappers first invoke the compiler as normal. Then, for each object file, they call a bitcode compiler to produce LLVM bitcode. The wrappers also store the location of the generated bitcode file in a dedicated section of the object file. When object files are linked together, the contents of the dedicated sections are concatenated (so we don’t lose the locations of any of the constituent bitcode files). After the build completes, one can use an WLLVM utility to read the contents of the dedicated section and link all of the bitcode into a single whole-program bitcode file. This utility works for both executable and native libraries. Currently, WLLVM works with either clang or the gcc dragonegg plugin. This two-phase build process is necessary to be a drop-in replacement for gcc or g++ in any build system. Using the LTO framework in gcc and the gold linker plugin works in many cases, but fails in the presence of static libraries in builds. WLLVM’s approach has the distinct advantage of generating working binaries, in case some part of a build process requires that. […]”

Hacking for Charity: Automated Bug-finding in LibOTR

https://github.com/travitch/whole-program-llvm

This project is not new, I just noticed it. 🙂 It isn’t Avatar/S2E, but it also interesting. I wonder if anyone is using this to test virtualized versions of coreboot, U-Boot, UEFI, SeaBIOS, and other firmware code?

User Mode Linux: security improvements

Nice to see UML getting more security!

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4f31d774dd5239e563f22ffe1403292414e6f779

http://user-mode-linux.sourceforge.net/

https://git.kernel.org/cgit/linux/kernel/git/rw/uml.git/log/?h=linux-next

Google Ubiquity and IoT security

Google’s Ubiquity Dev Summit just ended, some of the video is online. There is one talk on IoT security:

https://ubiquity.withgoogle.com/

https://ubiquity.withgoogle.com/stream

https://ubiquity.withgoogle.com/schedule

“Brillo has a defense-in-depth strategy to device security built around verified boot, software fault isolation, and field updates of devices. Paul Covell explains the architecture of each of these mechanisms and how they work together to help Brillo devices be more resistant to exploit and create mechanisms for recovery if an exploit occurs.