Category: Uncategorized

Debugging Tools for Windows 10

~ hucktech ~ Leave a comment

It looks like Microsoft has updated Windbg for Windows 10, one of the new features is support of Visual Studio’s NatVis expression model:

 dx (Display NatVis Expression) – Describes the new dx debugger command, which displays object information using the NatVis extension model and LINQ support.
New commands that work with the NatVis visualization files in the debugger environment.

    .nvlist (NatVis List)
    .nvload (NatVis Load)
    .nvunload (NatVis Unload)
    .nvunloadall (NatVis Unload All)

https://msdn.microsoft.com/en-us/library/windows/hardware/mt219728%28v=vs.85%29.aspx

The Car Hacker’s Handbook

~ hucktech ~ Leave a comment

No Starch Press has an interesting book coming out (parts already out online) on car hacking:

Chapter list below. Chapters 2,3,4,5,7,8,9 are available now.

1: Policies and Guidelines
2: Understanding Attack Surfaces
3: Utilizing the Linux SocketCAN Interface
4: Bus Protocols
5: Diagnostic Communications
6: CAN Bus RE
7: ECU Hacking
8: Building and Using ECU Test Benches
9: In-Vehicle Infotainment Systems
10: Vehicle-to-Vehicle
11: Weaponizing
12: TPMS
13: KeySystems
14: Hotwiring
15: Embedded System Attack
16: Performance Tuning
Appendix A: Open Garages
Appendix B: Tools

https://www.nostarch.com/carhacking

In addition to this NEW book, there’s a 2014 edition of a free car hacking book by Open Garages:

http://opengarages.org/handbook/

ARMv8-M announced

~ hucktech ~ Leave a comment

Lots of sites have stories on the new ARMv8-M announced this week at TechCon 2015:

http://www.businesswire.com/news/home/20151110005179/en/ARMv8-M-Architecture-Simplifies-Security-Smart-Embedded-Devices

http://www.theregister.co.uk/2015/11/10/arm_trustzone_armv8m_mbed_os/
http://www.eweek.com/security/arm-brings-trustzone-security-technology-to-iot-devices.html
http://www.anandtech.com/show/9775/arm-announces-armv8m-instruction-set
http://hexus.net/tech/news/industry/87980-armv8-m-architecture-launched/

 

Apple acquires LegbaCore!!

~ hucktech ~ Leave a comment

WOW, LegbaCore closes down, Xeno and Corey join Apple!!!!

https://twitter.com/XenoKovah/

I expect Apple will shortly have MUCH MORE secure firmware/hardware systems, with their help! Other OEMs should be a little scared today.

 

EFI updates in latest Yocto release

~ hucktech ~ Leave a comment

Elizabeth Flanagan of Intel’s Yocto Project has announced the release of Yocto 1.7.3. Yocto is the Intel-backed embedded Linux system based on OpenEmbedded. Intel’s LUV (Linux UEFI Validation) distro, as in LUV-live, is Yocto-based. There are 3 UEFI-related updates that I can see:

 * grub-efi: Add backslash lost from previous commit
 * grub-efi: Use the backport patch from grub
 * init-install-efi.sh: fix gummiboot entry installation

https://lists.yoctoproject.org/listinfo/yocto-announce
http://yoctoproject.org/
https://wiki.yoctoproject.org/wiki/Ww41_-_2015-10-08_-_Full_Pass_1.7.3.rc1
http://mirrors.kernel.org/yocto/yocto/yocto-1.7.3/

Hmm, isn’t Gummiboot dead, replaced by the SystemD boot loader? If so, why is it still actively-maintained in Yocto?

Gummiboot: RIP

And what about tummiboot, an Intel TXT-based fork of Gummiboot, shouldn’t Intel make that active? I haven’t checked, I hope tboot is available under Yocto, for BIOS today, and UEFI someday soon.
https://github.com/todorez/tummiboot
(I’d swear I did a blog post on tummiboot, but WordPress’s search abilities suck, and I suck at tagging, can’t find the post at the moment.)

Teddy Reed on bypassing Linux Secure Boot

~ hucktech ~ Leave a comment

Teddy Reed has a second article on UEFI, MinnowboardMax and Linux! This one is called “Minnowboard Max: Booting Linux Securely”, and talks about how the Linux shim is used, and enumerates the various ways this boot security can be bypassed.

[…] I say ‘more-or-less’ because there are tons of places where the verification can be subverted. Unfortunately, if you start examining the implementation and configuration details of the streamlined Secure Boot support, you’ll find plenty of bypasses. Let’s talk briefly about each bypass and conclude with a simple way to use Secure Boot and enforce a signed kernel execution on Ubuntu. To be clear, there are no vulnerabilities here as there is no documented intention to boot Linux securely (e.g., BUG/1401532), only to support a Secure Boot and boot Linux. […]

http://prosauce.org/blog/2015/10/31/booting-linux-securely

Teddy Reed research on Minnow firmware

Secure Boot strength varies by Linux implementation

Broken, Abandoned, Firmware code part 14/14

~ hucktech ~ Leave a comment

Zachary Cutlip has posted his FINAL part of the 14-part post on router firmware security, “Broken, Abandoned, and Forgotten Code, Part 14”:

“In the previous post, we walked through building a stage 1 firmware image that can be flashed to the Netgear R6200 by exploiting the hidden SetFirmware SOAP action in upnpd. Due to an undersized memory allocation, we aren’t able to flash a full sized image using this exploit. Whereas a stock firmware is nearly 9MB, the buffer upnpd base64 decodes into is 4MB, leading to a crash. As a result we have to load our trojanized firmware in two stages. The first stage is stripped down to bare essentials and contains an agent that downloads and flashes a full sized second stage providing persistent remote access. In this part, we conclude the series with a discussion of how to prepare the stage 2 and what it should contain.” […]

http://shadow-file.blogspot.com/2015/11/abandoned-part-14.html

Broken, Abandoned, and Forgotten firmware Code

EDK2 supports, multiple workspaces

~ hucktech ~ Leave a comment

The Tianocore.org RSS feed reports that the EDK2 now supports multiple workspaces:

http://www.tianocore.org/news/2015/11/04/Mult_workspaces.html

“An update to the EDKII build tools now allows the setting of multiple paths that will be searched when attempting to resolve the location of packages. This new feature allows for more flexibility when designing a tree layout or combining sources from different sources. The new functionality is enabled through the addition of a new environment variable (PACKAGES_PATH). The PACKAGES_PATH variable is an ordered list of additional search paths using the default path separator of the host OS between each entry. The first path in the list has the highest priority and the last path has the lowest priority. The path specified by the WORKSPACE variable always has the highest search priority over any PACKAGE_PATH entries. To use this feature, the PACKAGES_PATH environment variable must be set prior to running the edksetup script. The reason for this is that the edksetup script determines the location of the Conf and BaseTools directory location based on the values of the WORKSPACE and PACKAGES_PATH environment variables. The use of the PACKAGES_PATH environment variable is optional and if it is not defined the build will function like it has in the past.”

So, check PACKAGES_PATH for any strange entries from attackers trying to insert evil modules in to your builds, from now on. 🙂

https://github.com/tianocore/tianocore.github.io/wiki/Multiple_Workspace

firmware humor

~ hucktech ~ Leave a comment

Sometimes I look for news using things like #firmware on Twitter, and usually ignore the humor, just looking for news. So, for a change, here’s a few of recent firmware-related Twitter posts:

https://twitter.com/r0h1n/status/663032559895502848

https://twitter.com/JZdziarski/status/658972553394978816
https://twitter.com/Savagedlight/status/657542228781436928

https://twitter.com/tyy_tyy3/status/663347101326266368

sysadmins: server firmware update poll

~ hucktech ~ Leave a comment

[UPDATE: WordPress seems to render Twitter URLs non-deterministicly. Here is the link to the survey: URL ]

If you have a Twitter account, please  help Stacey Carter, she has an interesting poll:

Server Admin poll:  
How often do you update firmware and drivers on servers in your environment?  
Reason?
What hardware vendor?

If you don’t have a Twitter account, please feel free to leave a Comment here (see left).

PS: I have just learned something about posting comments to this wordpress.com-hosted blog works, I have to ‘approve’ Comments. And wow, there’s a lot of blog spam… The good news is that you only have to be approved once, all future posts do not need approval. So please say something un-spam-like in the first sentence of the reply. Thanks.

new Linux kernel NVDIMM IOCTL pass thru patch

~ hucktech ~ Leave a comment

Jerry Hoemann of HP (now HPE) posted a message to the linux-nvdimm@lists.01.org, linux-acpi, and linux-kernel lists with new patch to the Linux 4.3 kernel with a new ioctl inteface for NVDIMM DSMs:

nvdimm: Add an IOCTL pass thru for DSM calls

The NVDIMM code in the kernel supports an IOCTL interface to user space based upon the Intel Example DSM:
http://pmem.io/documents/NVDIMM_DSM_Interface_Example.pdf

This interface cannot be used by other NVDIMM DSMs that support incompatible functions. This patch set adds a generic “passthru” IOCTL interface which is not tied to a particular DSM. A new IOCTL type “P” is added for the pass thru call. The new data structure ndn_pkg serves as a wrapper for the passthru calls.  This wrapper supplies the data that the kernel needs to make the _DSM call. Unlike the definitions of the _DSM functions themselves, the ndn_pkg provides the calling information (input/output sizes) in an uniform manner making the kernel marshaling of the arguments straight forward. This shifts the marshaling burden from the kernel to the user space application while still permitting the kernel to internally calling _DSM functions. To make the resultant kernel code easier to understand the existing functions acpi_nfit_ctl and __nd_ioctl were renamed to .*_intel to denote calling mechanism as in 4.2 tailored to the Intel Example DSM. New functions acpi_nfit_ctl_passthru and __nd_ioctl_passthru were created to supply the pass thru interface.

 drivers/acpi/nfit.c        |  91 ++++++++++++++++++++++++++++++++–
 drivers/nvdimm/bus.c       | 118 +++++++++++++++++++++++++++++++++++++++++—-
 drivers/nvdimm/dimm_devs.c |   6 +–
 include/linux/libnvdimm.h  |   3 +-
 include/uapi/linux/ndctl.h |  20 +++++++-
 5 files changed, 220 insertions(+), 18 deletions(-)

For more information, see the posting on the linux-nvdimm@lists.01.org mailing list archives.

http://pmem.io/documents/

Android attestation API

~ hucktech ~ Leave a comment

Shawn Willden of Google recently posted a message to the Android Security Discussions group. Someone had asked if, like a PC, Android smartphones have a TPM or Trusted Execution Environment (TEE), and if this included a public remote attestation API. Shawn’s response:

“One of the features I’m working on adding to Android TEEs for N is an attestation API. It will be implemented in our TEE, Qualcomm’s, Trustonic’s, etc. However, that will only assure the relying party that the device attesting has an officially-blessed TEE, and that the Android OS that was booted was an officially-blessed image as well. It can’t say anything about the state of Android, whether or not it has been compromised in some way that doesn’t involve modifying the boot images. The SafetyNet attestation can theoretically provide some level of assurance that the device is not compromised, though at the moment I believe it really only validates that the device is not an emulator and that it hasn’t been rooted in an obvious way.”

For more information: see the October 25th posting from Shawn on:
http://groups.google.com/group/android-security-discuss

coreboot update

~ hucktech ~ Leave a comment

Last week Patrick Georgi posted a new entry to the coreboot blog.

There is support for 4 new boards: 2 Google boards, google/chell and google/lars, and 2 Asus boards, KFSN4-DRE and KGPE-D16. There were improvements to cbfstool, libpayload, superio and i2c chip drivers. The project has udpated their automated testing, and related code cleanup. There is a new lint tool for Kconfig files, see util/lint/kconfig_lint. It appears there is some fuzzing infrastructre being setup, including afl support! Some unmaintained, untested driver code was removed, and there is a maintainer-related script to help, see util/scripts/maintainers.go.

“The ongoing effort to support booting in long mode (64 bit) on AMD64 progressed by the integration of changes to make SMM handling and AMD chipset drivers 64bit clean.”

“Sandybridge now initializes CPUs serially for robustness reasons, and Intel FSP supports loading microcode from coreboot.”

“All related chipsets also saw significant improvements, of which the still ongoing effort to provide non-AGESA implementations for the Fam15h CPU, as well as a ton (metric, in case you’re curious) of bugfixes and feature developments (for example Suspend to RAM) for all AMD CPUs starting with K8 is particularly notable.”

Full blog post:

coreboot changelog

ACPI debugger for Linux kernel

~ hucktech ~ Leave a comment

Last Friday, Lv Zheng of Intel sent a 5-part patch to the linux-acpi and linux-kernel mailing lists. Below is documentation excerpt from initial patch:

ACPICA / debugger: Add in-kernel AML debugger support

This patchset enables ACPICA debugger for Linux kernel and implements a userspace utility to access it.

A. Build the AML debugger
In order to build the kernel support of AML debugger, the following kconfig items should be enabled:
 CONFIG_ACPI_DEBUG=y
 CONFIG_ACPI_DEBUGGER=y
 CONFIG_DEBUG_FS=y
 CONFIG_ACPI_DEBUGGER_USER=m
The userspace tool can be found at tools/power/acpi/tools/acpidbg. To build this utility, staying in tools folder and type “make acpi”.

B. Load the AML debugger during runtime
In order to use the in-kernel AML debugger, the following command should be executed using root user:
 # modprobe acpi_dbg
 # mount -t debugfs none /sys/kernel/debug
 # acpidbg

C. Batch mode
In order to support scripts, the userspace utility also supports single command batch mode:
 # acpidbg -b “help”
 # acpidbg -b “tables”
 # acpidbg -b “find _LID”
 # acpidbg -b “execute \_SB.LID0._LID”
You can find the documentation about the ACPICA debugger commands in:
 https://acpica.org/sites/acpica/files/acpica-reference_17.pdf
 (The latest document can be found at https://acpica.org/documentation)
And refer to the chapter – ACPICA debugger reference to obtain the full description of the debugger commands. Note that not all commands are supported by an in-kernel AML debugger.

D. Unload the AML debugger during runtime
After terminating all acpidbg instances, the following command can be executed to remove the AML debugger from kernel:
 # rmmod acpi_dbg

The following tasks are not completed:
1. .flush() support in the kernel debugger IO driver.
2. multi-commands batch mode.
3. upstream the userspace acpidbg to the ACPICA upstream.

For more information, see the threads on the linux-kernel and linux-acpi mailing lists, run at vger.kernel.org.

Steve Grobman on HW/FW vulnerability tools

~ hucktech ~ Leave a comment

Steve Grobman of Intel has written a blog post “Hardware.Next: Hardware and firmware vulnerabilities provide tools to attackers and defenders.” Steve Grobman is the CTO for Intel Security Group at Intel Corporation.

The post mentions Intel SGX — which may’ve been updated with DXL support, not sure what DXL is yet — and other Intel and related security technologies, including CHIPSEC.

https://blogs.mcafee.com/executive-perspectives/hardware-next-hardware-firmware-vulnerabilities-provide-tools-attackers-defenders/

http://newsroom.intel.com/community/intel_newsroom/bios?n=Steven%20L.%20Grobman&f=searchAll

CHIPSEC 1.2.2 released!

~ hucktech ~ Leave a comment

After nearly a quarter without an update, CHIPSEC 1.2.2 has been released!!

This release includes multiple new VMM tests — including new fuzzers — hinted at DEF CON and elsewhere, a VENOM test, some S3 tests, support for more Intel CPUs,  as well as a bunch of new/updated features:

NEW modules:
 * tools.vmm.cpuid_fuzz to test CPUID instruction emulation by VMMs
 * tools.vmm.iofuzz to test port I/O emulation by VMMs
 * tools.vmm.msr_fuzz to test CPU Model Specific Registers (MSR) emulation by VMMs
 * tools.vmm.pcie_fuzz to test PCIe device memory-mapped I/O (MMIO) and I/O ranges emulation by VMMs
 * tools.vmm.pcie_overlap_fuzz to test handling of overlapping PCIe device MMIO ranges by VMMs
 * tools.vmm.venom to test for VENOM vulnerability

Updated modules:
 * tools.smm.smm_ptr to perform exhaustive fuzzing of SMI handler for insufficient input validation pointer vulnerabilities
 * smm_dma to remove TSEGMB 8MB alignment check and to use XML “controls”. Please recheck failures in smm_dma.py with the new version.
 * common.bios_smi, common.spi_lock, and common.bios_wp to use XML “controls”
 * common.uefi.s3bootscript which automatically tests protections of UEFI S3 Resume Boot Script table
 * tools.uefi.s3script_modify which allows further manual testing of protections of UEFI S3 Resume Boot Script table

NEW functionality:
 * hal.cpu component to access x86 CPU functionality. Removed hal.cr which merged to hal.cpu
 * hipsec_util cpu utility, removed chipsec_util cr
 * S3 boot script opcodes encoding functionality in hal.uefi_platform
 * hal.iommu, cfg/iommu.xml and chipsec_util iommu to access IOMMU/VT-d hardware
 * chipsec_util io list to list predefined I/O BARs
 * support for Broadwell, Skylake, IvyTown, Jaketown and Haswell Server CPU families
 * ability to define I/O BARs in XML configuration using register attriute similarly to MMIO BARs
 * UEFI firmware volume assembling functionality in hal.uefi
 * Implemented alloc_phys_mem in EFI helper

See the full readme on the github page, which also includes short lists of bugfixes and known-issues:

https://github.com/chipsec/chipsec

If you haven’t been following current security research by Intel’s ATR team, who produces CHIPSEC, watch this video to see why you need to run this new version of CHIPSEC on any machine — after reading CHIPSEC’s warning.txt first — that runs a VMM:

[Hopefully we’ll see Intel LUV team add this release to their project, including LUV-live, soon. There has been a recent patch to LUV that may fix CHIPSEC’s usage in LUV-live, a second important reason to update your LUV-live images.]

Anandtech OpenPOWER update

~ hucktech ~ Leave a comment

From Vincent Zimmer’s twitter feed, Johan De Gelas has a story on Anandtech, discussing IBM’s OpenPOWER8.

So what caused us to investigate the IBM POWER8 as a viable alternative to the mass market Xeon E5s and not simply the high-end quad (and higher) socket Xeon E7 parts? A lot. IBM sold its x86 server division to Lenovo. So there is only one true server processor left at IBM: the POWER family. But more importantly, the OpenPOWER fondation has a lot of momentum since its birth in 2013. IBM and the OpenPOWER Foundation Partners like Google, NVIDIA, and Mellanox are all committed to innovating around the POWER processor-based systems from the chip level up through the whole platform. The foundation has delivered some tangible results:

 * Open Firmware which includes both the firmware to boot the hardware (similar to the BIOS) …
 * … as OPAL (OpenPOWER Abstraction Layer) to boot and launch a hypervisor kernel.
 * OpenBMC
 * Cheaper and available to third parties (!) POWER8 chips
 * CAPI over PCIe, to make it easier to link the POWER8 to GPUs (and other PCIe cards)
 * And much more third party hardware support (Mellanox IB etc.)
 * A much large software ecosystem (see further)

The impact of opening up firmware under the Apache v2 license and BMC (IBM calls it “field processor”) code should not be underestimated. The big hyperscale companies – Google, Amazon, Microsoft, Facebook, Rackspace – want as much control over their software stack as they can.
[…]

Full article:
http://www.anandtech.com/show/9567/the-power-8-review-challenging-the-intel-xeon-/2