Purism Librem-13 gets 100% funded

According to this tweet, Purism got their Librem13 laptop funded. Congratulations!

Looking at the above ‘thread’, it mentions two other items of Purism news.

It sounds like that after Notebooks, they’re going to target Tablets, then Smartphones.

“First privacy respecting Librem notebooks. Next: Tablets. And then: Smartphone.”

Also, it looks like they’ll have some more news on their firmware efforts, specifically related to their efforts fighting the Intel Management Engine (ME):

“we have big news soon on freeing the ME. All firmware updates will be provided”

The already have semi-regular posts on their blog by their firmware developer, with some more news that I’ve not covered. I’m not sure what the second sentence above means. Other OEMs currently provide firmware updates to ME already. Providing full source updates would be impressive, but I doubt they meant that.

https://www.crowdsupply.com/purism/librem-13

Purism gets a bit of criticism from some people because their marketing department claims that their BIOS is “almost free”, but they’re using a modern Intel system, which has many blobs and out-of-band activities. Other documentation from Purism clarifies that the “BIOS is not yet free”. Use of FSP is not a 100% requirement for modern Intel systems, it isn’t clear what the mainstream BIOS vendors are using it or alternate code. One recent BIOS vendor, I forget their name, they’re based in Sweden, released a BIOS solution for the Intel Minnowboard, which was not based on FSP. I presume, but am not sure, that anyone who does a FSP alternative codebase would still need some NDA for some specifications from Intel.

The Purism web site says:

While the BIOS is not yet free, the Librem will be the first laptop ever manufactured to ship a modern Intel CPU fused to run unsigned BIOS code, allowing for a future where free software can replace the proprietary, digitally signed BIOS binaries. This marks one of the largest hurdles to a BIOS that runs 100% free software and firmware. Recognizing the importance of this critical step toward consumer freedom, Dr. Richard M. Stallman, president of the Free Software Foundation (FSF), states:

    “Getting rid of the signature checking is an important step. While it doesn’t give us free code for the firmware, it means that users will really have control of the firmware once we get free code for it.” – Dr. Richard M. Stallman

There are also hardware components, like the HD or SSD, that are flashable, and therefore upgradeable, but that currently run firmware that is not yet freed. We are working to get freed versions of this firmware! Being the first manufacturer to care about privacy, security, and freedom, we are pushing this message upstream.

Bluntly, I’m not I understand or agree with RMS’s above statements, unclear of the context. Offhand, it seems to me that RMS isn’t considering security at all, only personal freedoms. I want both, and I don’t see why I need to chose just one. I want code to be checked, but I want to be able to control what is run. I get a little worried about some privacy enthusiasts, they sometimes only focus on technology choices that give them personal freedom, and completely ignore the use case of an attacker, who doesn’t care if the binaries were backed by open source or not.

[I want a box with a kill switch, like Purism has. And two-factor authentication required to boot firmware, locally or remotely. And a Developer Mode, like Google ChromeBook Pixel has, to override BIOS and let me do what I want. I want a metal enclosure that covers all ports (Thunderbolt, etc.) when closed, and I want a quality lock integrated into system, to deter Evil Maid from accessing ports or developer mode firmware override. I expect a good key won’t be viable, TSA checkpoints will want the ability to Evil Maid people and a good lock may slow them down.]

This quote from Joanna of Invisible Things Lab summarizes my trust of Purism exactly:

“I agree there are redflags in the @Puri_sm marketing lang. There are also positives, such as @ioerror being on board.”

Purism has a tough job trying to remove blobs from firmware, make system flexible enough for users to install new boot-time software, yet prevent attackers from attacking system, while removing protections that Intel has been adding to deter attackers. With some AMD systems, they may have less firmware to worry about blobs, but will have entirely new silicon attacks, and unlike Intel, ARM doesn’t provide any firmware vulnerability assessment tools. I’m unclear about AMD64 firmware and their AGESA, which is somewhat similar to Intel’s FSP; unclear about blob-removable potential by Purism. Also, AMD, like ARM systems, doesn’t have CHIPSEC or similar tools. Overly slick marketing aside, they’re the only OEM that’s trying to solve this problem — arguably the 2nd, after Bunnie, perhaps — which is nice to see.

It’ll be interesting to see what ISA they choose for their tablet and smartphone devices!

Android Vulnerability Test Suite

https://twitter.com/revskills/status/643875969896456192

Wow, this is first I’ve heard of this tool! The readme mentions prior art, at least one related tool, as well.

Excerpt from the blog:
Announcing Android Vulnerability Test Suite
Today, NowSecure is releasing to the public an open source Android Vulnerability Test Suite (Android VTS). Ryan Welton (@fuzion24) has worked particularly hard to produce a tool that can be used by researchers and users alike to determine the vulnerability status of their devices. In the spirit of open data collection, and with the help of the Android CTS, we are opening Android VTS to the public and the mobile security research community with the hope that together we can take an accurate pulse on the state of Android security. In time, NowSecure’s research team will add patches to the VTS to introduce an opt-in module for anonymized results to be shared to a central server for the purpose of open security research. With this release we provide the code and compiled APK to begin checking the vulnerabilities immediately. Pull requests welcome!

Excerpt from the code’s readme:

Implementation
Vulnerabilities in a device can exist at many layers inside of Android. For example, a bug can exist in the kernel (Towelroot, for example) or it can exist in the Android specific framework (Android Masterkeys/FakeID). Some of the kernel bugs can sometimes be difficult to check for without potentially causing system instability. This implementation takes care to not include checks that could cause instability problems for the end user and therefore may omit checks that could cause these types of issues. The framework is very thin at the current time and consists of a vector of vulnerability checks. Their concrete implementations vary wildly depending on the bug. A list of current bug checks:

    ZipBug9950697
    Zip Bug 8219321 / Master keys
    Zip Bug 9695860
    Jar Bug 13678484 / Android FakeID
    CVE 2013-6282 / put/get_user
    CVE_2011_1149 / PSNueter / Ashmem Exploit
    CVE_2014_3153 / Futex bug / Towelroot
    CVE 2014-3847 / WeakSauce
    StumpRoot
    Stagefright bugs
    x509 Serialization bug
    PingPong root – CVE-2015-3636

More Information:

https://github.com/nowsecure/android-vts

https://www.nowsecure.com/blog/2015/09/14/announcing-android-vulnerability-test-suite/

Microsoft Device Guard

Thanks to Matt Graeber’s Twitter post, I became aware of Microsoft’s new documentation for Device Guard, a security technology for Microsoft Windows.

https://twitter.com/mattifestation/status/643817965620588544

Microsoft Device Guard is a feature set that consists of both hardware and software system integrity hardening features that revolutionize the Windows operating system’s security. Windows 10 employs Device Guard as well as code integrity and advanced hardware features such as CPU virtualization extensions, Trusted Platform Module, and second-level address translation to offer comprehensive modern security to its users. This guide explores the individual features in Device Guard as well as how to plan for, configure, and deploy them. […]

https://technet.microsoft.com/en-us/library/mt463091%28v=vs.85%29.aspx

DbgKit 1.3 released

Andrey Bazhan has released version 1.3 of DbgKit, a GUI extension to WinDbg, the Microsoft Windows system debugger, included in the “Debugging Tools for Windows” package. Given that most Windbg extensions are command line, a GUI extension to Windbg is fairly impressive!

“DbgKit is the first GUI extension for Debugging Tools for Windows (WinDbg, KD, CDB, NTSD). It will show you hierarchical view of processes and detailed information about each process including its full image path, command line, start time, memory statistics, vads, handles, threads, security attributes, modules, environment variables and more.”

http://www.andreybazhan.com/dbgkit.html

Qualcomm Snapdragon updates

Qualcomm announces ARM-based Snapdragon 430 and 617, and Snapdragon 820 with X12 LTE modem:

Over the past several weeks, we have been revealing details about the incredible features of the Qualcomm Snapdragon 820 processor. And today we are revealing the final piece of the puzzle. The Snapdragon 820 is the most powerful mobile processor we’ve ever made. […]

Qualcomm Technologies is building up the Snapdragon line-up with two new products and several firsts. The Qualcomm Snapdragon 617 and 430 processors are designed to deliver high-end performance and experiences in affordable, high- and mid-tier devices. […]

https://www.qualcomm.com/news/snapdragon/2015/09/14/snapdragon-617-and-430-build-mid-tier-high-end-features
https://www.qualcomm.com/news/snapdragon/2015/09/14/snapdragon-820-countdown-breakthrough-lte-and-wi-fi-x12-lte-modem

Intel announces Automotive Security Review Board and Security Best Practices

Intel just created “Automotive Security Review Board (ASRB)“. You can apply to get on the board on the below URL. Their initial best practices paper is also published at below URL. Free car to best security research!

To help mitigate cyber-security risks associated with connected cars while also encouraging technological progression and innovation, Intel today announced the creation of the Automotive Security Review Board (ASRB) made of automotive security experts. ASRB researchers will conduct cyber-security research for Intel’s automotive platform. The member with the most impactful contribution will be awarded a new car. The Automotive Security Review Board will bring together top security industry talent from around the world who have expertise in particular areas of cyber-physical systems. ASRB researchers will perform ongoing security tests and audits intended to codify best practices and design recommendations for advanced cyber-security solutions and products to benefit the automobile industry and drivers. To motivate the ASRB researchers, Intel will award a new car to the member who provides the most significant and impactful cybersecurity contribution that can be implemented on Intel’s automotive platform. All details related to the Intel development platform and areas of security audit focus will be provided at the inaugural ASRB meet-up next month.

The new Intel white paper “Automotive Security Best Practices: Recommendations for Security and Privacy in the Era of the Next-Generation Car,” analyzes risks associated with the next generation of connected automobiles and provides specific security recommendations for the automotive industry. Intel is inviting industry experts to comment on the white paper and will publish revisions based upon feedback and ASRB findings.

https://www-ssl.intel.com/content/www/us/en/automotive/automotive-security-review-board.html
http://newsroom.intel.com/community/intel_newsroom/blog/2015/09/14/chip-shot-intel-looks-to-secure-connected-cars
http://newsroom.intel.com/community/intel_newsroom/blog/2015/09/13/intel-commits-to-mitigating-automotive-cybersecurity-risks
http://www.mcafee.com/autosecuritywp
http://www.intel.com/automotive/asrb

Intel ATR demo videos from Blackhat

Yuriy Bulygin of the Intel Advanced Threat Research (ATR) team, who includes the CHIPSEC team, has released some videos of their Blackhat demos:

I’m looking forward to that new CHIPSEC s3 security test that is supposed to be in the works as a result of some of the Intel ATR talk at Blackhat!

JTAGsploitation

Joe Fitzpatrick (@securelyfitz) has released the slides and samples for the recent 44Con talk on “JTAGsploitation”.

Quoting the *entire* 1-line readme here:

jtagsploitation: scripts and examples for using JTAG debug tools to gain root access

More information:
https://github.com/syncsrc/jtagsploitation

Rekall forensics of XEN

There’s a nice blog in the Rekall forensics blog about memory forensics of XEN systems:

If you’ve ever taken a memory image of a Linux virtual machine that’s running under XEN in paravirtualization mode and you’ve tried to analyze it you’ll have noticed most of your plugins don’t work (if any). The reason is that XEN’s page tables are funky. XEN uses a technique known as direct mapping which significantly differs from how memory management is done in many other virtualization solutions.

More Information:
http://rekall-forensic.blogspot.com/2015/08/xen-paravirtualization-support-in-rekall.html
http://www.rekall-forensic.com/
https://github.com/google/rekall

The Most Hackable Cars

PT&C|LWG, a forensics service, has released a guide to the most vulnerable smartcards

The Most Hackable Cars on the Road
August 19, 2015

Modern automobiles are becoming more reliant on technology for infotainment, operational, security, and safety features that make up the core functionality of the vehicle. These advances use much of the same technology that is used for our personal wireless devices, computers, software applications, and more. Today’s modern automobile uses between 20 and 70 computers, each with its own specialized use, that make up the overall functionality of the vehicle.

The article has information about the Most hacked cars, the Least hacked ones, and more information about car hacking. The paper had the help of a skilled graphic artist, not just a writer, who contributed some nice graphics.

More Information:

http://www.ptclwg.com/news/the-most-hackable-cars-on-the-road-1

http://www.ptclwg.com/

Verifiedworthy Computing

I dislike Twitter, it’s a pain in to comment on in a WordPress blog. It appears that WordPress doesn’t always embed the HTML table, sometimes leaving an empty page.

Regardless of how much of pain it is to deal with Twitter-based content, below are two interesting Twitter-based conversations from Joanna of ITL, in two separate but related ‘threads’. I hope some of the vendors she’s thinking of are reading her comments. 🙂 Please click on both of the below Twitter URLs to get the full conversation.

https://twitter.com/rootkovska/status/643409975105191941

OpenBSD UEFI progress

Progress appears to be continuing at the OpenBSD project w/r/t UEFI support, with multiple devices!

Jaspar has a new blog post with information on using OpenBSD on UEFI-based systems.

http://blog.jasper.la/openbsd-uefi-bootloader-howto/

http://undeadly.org/cgi?action=article&sid=20150902074526&mode=expanded&count=6

RehabMan’s ACPI tools for OSX

I just noticed the project Laptop-DSDT-Patch, by RehabMan. It contains “Common DSDT patches for Ivy/Sandy/Haswell laptops for running OS X“, so it’s for ‘hackintosh’ hackers using non-Apple hardware to run Apple’s OS, OS X, and have to deal with non-Apple hardware/firmware, particularly ACPI’s DSDT table, a nice example of how the modding community generates some interesting firmware tools, if nothing else.

Quoting from from the beginning of RehabMan’s HP-ProBook-4x30s wiki on How to patch your DSDT (useful background even if you don’t this HP model):

Although there are pre-patched DSDTs available as downloads from the tonymacx86.com forums and in installer packages such as the HP ProBook Installer, there can be differences in individual DSDTs that can cause delays in booting and perhaps other problems. Perhaps there are slight differences in BIOS settings, memory installed, etc, that is causing these differences. It is best, therefore, to patch your own DSDT and install it into /Extra/dsdt.aml (Chameleon) or EFI/Clover/ACPI/patched (Clover). I have included five different methods for extracting your native DSDT. Just pick the method that seems easiest for you. The easiest one will depend on whether you still have Windows installed, whether you already have a Linux USB stick prepared, and just how familiar you are with both systems.

Quoting from the OSx86 wiki, for the Mac OSX-perspective on it, ACPI’s DSDT is:

The Differentiated System Description Table is the main table in the ACPI part of a computer’s BIOS. The Advanced Configuration and Power Interface (ACPI) defines a large number of tables that provide the interface between an ACPI-compliant operating system and system firmware. These allow description of system hardware in a platform-independent manner in ACPI Machine Language (AML). The problem is that OS X has an incomplete ACPI implementation which supports only a subset of DSDT. Modifying the DSDT allows the user to better support their hardware. For example, fixing Time Machine and the UUID 35 error is possible after modifying the DSDT. To patch your DSDT, you must either use a new table file that someone else has provided, or extract and modify your own. Then tell your bootloader to use the new DSDT file instead of the BIOS. On a few motherboards it is also possible to replace the BIOS with an updated BIOS with a patched DSDT. One of the simplest ways to extract your DSDT from your BIOS is by using DSDT Editor. Once you have downloaded DSDT Editor, open it and press File –> Extract DSDT. After 2-15 seconds, your DSDT should appear on the screen.

Look at the various ACPI-centric projects RepoMan has, there’re many! Also, the Ubuntu wiki and SmackerelOfOpinion blog are both excellent for ACPI diagnostic tips.

These ‘modding community’-based ACPI changes for OS X are educational, to see how people can extend their purchases for use cases beyond those that the vendor could imagine. As systems get more tamper-proof, it seems likely that users will have less and less ability to change things. [There also exists a HUGE modding community by photographers and their smartcameras (embedded devices). They add amazing new features. The other day I saw one talk about how they update the system to be able to take pictures of lighting better. Nice example of how owners can add features to their purchases, if able to update their firmware. 🙂 And of course there is custom ‘firmware’ for smartphones, entire distros.]

Personal modding hobbies aside, how much time, if any, do enterprise sysadmins currently spend fixing OEM ACPI tables and other firmware features, to make their systems work properly?

More Info:
https://github.com/RehabMan/Laptop-DSDT-Patch
https://github.com/RehabMan/HP-ProBook-4x30s-DSDT-Patch/wiki/How-to-patch-your-DSDT
https://bitbucket.org/RehabMan/os-x-maciasl-patchmatic
http://www.insanelymac.com/forum/topic/223205-dsdt-editor-and-patcher/
https://github.com/RehabMan?tab=repositories
http://uefi.org/acpi
http://smackerelofopinion.blogspot.com/2009/10/dumping-acpi-tables-using-acpidump-and.html
http://acpi.sourceforge.net/dsdt/
https://01.org/linux-acpi/documentation/overriding-dsdt
http://www.tldp.org/HOWTO/ACPI-HOWTO/dsdt.html
http://wiki.osdev.org/DSDT
http://wiki.osx86project.org/wiki/index.php/DSDT
https://msdn.microsoft.com/en-us/library/windows/hardware/dn495660%28v=vs.85%29.aspx#dsdt
https://wiki.debian.org/OverridingDSDT
http://www.insanelymac.com/forum/topic/278170-dsdt-%E2%80%94-what-is-it-and-how-do-i-get-it/
https://wiki.ubuntu.com/Kernel/Reference/ACPITricksAndTips
https://www.kernel.org/doc/Documentation/acpi/dsdt-override.txt
http://smackerelofopinion.blogspot.com/search/label/ACPI
http://clover-wiki.zetam.org/Configuration/ACPI#DSDT

Andy Simpkins: Developing products in the open

Last month, at the DebConf, the annual Debian conference, there was a talk for OEMs on using Open Source Software and Free Software (FOSS), as well as using Open Source Hardware. Most have heard an Open Source advocate discuss the merits of open-source -vs- closed-source software. This talk is from the perspective of vendors who need to buy and build hardware.

Developing products in the open
Andy Simpkins
Over the last couple of decades the world of product development with embedded systems has changed considerably. Changing to Open Source (for hardware as well as software) is not easy. The world resists change, this is a brief history of where I have succeeded, where I have failed and the lessons learned. This is a not a technical talk, more a collection of observations.

The video can be downloaded in WBEM format from DebConf site, or watched online via Youtube:

http://meetings-archive.debian.net/pub/debian-meetings/2015/debconf15/
https://summittest.debconf.org/debconf15/meeting/192/developing-products-in-the-open/
https://summit.debconf.org/debconf15/meeting/192/developing-products-in-the-open/
http://debconf15.debconf.org/

LegbaCore training announcement

The 2-day agenda:
    Introduction to BIOS concepts
        General system configuration responsibilities
        Security-specific configuration responsibilities
    Hardware architecture
        ICH/MCH/PCH
        SPI flash chip
    Usage of PCI for x86 system internals
    Talking to hardware through the PCI configuration space
    PCI Option ROMs (and their use in attack)
    BIOS access control mechanisms
        How they fail
        Tools to detect their failure
    System Management Mode (SMM)
        Why SMM is basically the best place for an attacker to live on an x86 system
        Discussion of how the BIOS instantiates SMM from flash chip contents
        Discussion of how attackers can break into SMM even without persisting on the flash chip
    Introduction to UEFI BIOS
        The UEFI phases and security parameters specific to UEFI
        UEFI Firmware Filesystem
    Reverse engineering UEFI modules
        Applying UEFI structure definitions in IDA Pro
    How Secure Boot & Measured Boot work
        Attacks against Secure Boot
        Attacks against Measured Boot
    Specific tools useful for performing further firmware security research
        RWEverything
        ChipSec

http://gsec.hitb.org/sg2015/sessions/tech-training-6-introductory-bios-smm-attack-defense/

FWTS updated

Ivan Hu of Canonical has announced the release of FWTS (FirmWare TestSuite), to 5.09.00. FWTS is a set of command line tools for Ubuntu-based and related Linux systems. It also includes a curses-based interface frontend, which is also the default UI to FWTS-live. FWTS is also included in LUV, the Linux UEFI Validation distribution, but it may be a few days until this latest release has been updated in LUV-live. The release features many bugfixes, as well as some new updates/features, including:

* Update ACPICA to version 20150717
* SMBios 3.0.0 tests supported
* acpi: add _CR3 test
* acpi: add _MTL test
* acpi: add _RST test
* acpi: add _PRR test
* dmicheck: SMBIOS 3.0.0 test

For more information, see the full announcement on the fwts-announce mailling list, and see the full changelog, /usr/share/doc/fwts/changelog.Debian.gz in the source tarball.

https://launchpad.net/ubuntu/+source/fwts
http://fwts.ubuntu.com/release/fwts-V15.09.00.tar.gz
https://launchpad.net/~firmware-testing-team/+archive/ubuntu/ppa-fwts-stable
https://wiki.ubuntu.com/FirmwareTestSuite/ReleaseNotes/15.09.00

CVE-2015-5367: HP Gobi 4G firmware vulnerability

I missed this CVE the first time around, only noticed it with recent mainstream news reports. 😦

Quoting the Debian page:

The HP lt4112 LTE/HSPA+ Gobi 4G module with firmware before 12.500.00.15.1803 on EliteBook, ElitePad, Elite, ProBook, Spectre, ZBook, and mt41 Thin Client devices allows local users to gain privileges via unspecified vectors.

Huawei is also listed with this CVE, so perhaps other vendors besides HP are impacted?

More Information:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5367
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-5367

Click to access Intel_DC23_SPLTE.pdf

https://security-tracker.debian.org/tracker/CVE-2015-5367
http://www1.huawei.com/en/security/psirt/security-bulletins/security-advisories/hw-446601.htm
http://www.securityfocus.com/bid/76171/
http://www.techworm.net/2015/09/hackers-can-remotely-exploit-bug-in-hp-pcs-laptops-and-tablets.html