Tag: Intel Management Engine

Purism Librem-13 gets 100% funded

~ hucktech ~ Leave a comment

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!

Interview with LegbaCore (and: their OpROM checker ships!)

~ hucktech ~ Leave a comment

A while ago, I emailed Corey and Xeno of LegbaCore, and sent them a few questions for an ‘interview’ for this blog. Well, here’s the results (also see EOM for URLs):

Q: This October in Singapore you’re giving 3-days of training at HITB. Besides new Apple EFI skills, can you give us some other new things that’ll be in this training?
A: The course introduces the basics of evaluating firmware and SMM on modern platforms for security vulnerabilities, as well as for potential compromises. Specifically we work through methodologies for identifying whether or not your system contains publically known vulnerabilities (which a great majority of them do). We also introduce a firmware forensic and reverse engineering methodology for identifying potential firmware compromises… so say if you got comprised by something like the hacking team UEFI rootkit, we’d talk about the tools and procedures that would be useful for identifying and analyzing this threat both on one particular system and at scale across your enterprise.
    The most important point of the training is it will be focused on real hardware that is deployed in real environments. A large portion of the course will involve evaluating the hardware that students bring with them. This way if you’re in charge of malware detection/response in an enterprise, you’ll walk away with actionable information related to the hardware you are deploying on your network.

Q: You had a Twitter post a few weeks (months?) back, saying that you were going to start releasing information about OEM systems’s vulnerabilities. What’s up with that project, I’m eager to see this data, as Consumer Reports and other computer review sources are useless for this most crucial pre-sales information. Any chance you could give FirmwareSecurity.com a teaser of this information, perhaps one new OEM model released in the last 6 months that’s insecure? 🙂
A: We anticipate that the project to start making some vendors’ firmware security failings more apparent (via a public website) will probably kick off in early 2016. We want to give all vendors that we think may have an interest in improving their security a chance to either talk with us about working with them, or show that they can make measurable security improvements on their own within this timeframe.

Q: You had a Twitter post a few days ago, pointing to a new LegbaCore Github repository for a new Option ROM checking tool. This sounds very interesting! What kinds of Option ROM(s) will it support? What platform(s) will it run on? When can we expect initial release?
A: It will only integrity check the Apple Thunderbolt to Ethernet adapter’s option ROM. It will work in conjunction with a port of the linux tg3 kernel driver to run on Macs to dump the OROM. The “ethtool” command can also be run to dump the OROM on linux systems that have a thunderbolt port and the tg3 driver available. The tool will be released to coincide with the talk at BlackHat, August 6th.

Q: Beyond this new Option ROM checker, does LegbaCore have any additional tool plans in the works? If so, any details to reveal?
A: Our current thinking on tools is that we expect that we will make clean-slate “best effort” tools freely available at some point in the future. These tools would be like all typical security tools, being not particularly trustworthy, and thus vulnerable to attacker subversion. They would mostly be useful for catching attackers as they first enter into the domain, and are not particularly sophisticated. However we will only make those tools available once we have commercial-grade tools available, that have a trust argument for why these paid tools have the ability to stand up to sophisticated and well-resourced adversaries. And in the background we will work with vendors to add capabilities such as SMM Dual Monitor mode, which significantly strengthen the trust arguments

Q: The Copernicus release is mostly Windows-centric, but also includes a cross-platform, bios_diff.py tool in the release. Will the new LegbaCore github tree include a open source bios_diff project, perhaps to get open source patches for improved BIOS parsing beyond EFIPWN, perhaps like that in UEFITool?
A: While bios_diff.py continues to provide the only simple, semantically aware integrity checking capability for BIOS, it has a number of issues. E.g. in the context of our latest work, it simply doesn’t work to integrity check Apple firmware, because Apple firmware update structure does not look the same as the structure on-disk.

Q: Post-October/HITB, what’s the next LegbaCore BIOS/UEFI security training event you’ll be giving?
A: Later in October I’ll be offering a similar training at Ruxcon breakpoint. Beyond that we are fairly busy with private training engagements.

Q: Any hints what kind of new firmware vulnerability research you’re working on, and when we might see some of the results?
A: We are branching out to the security of peripheral devices such as network cards, HDs/SSDs, embedded controllers, GPUs, the Intel Management Engine, etc. We are shooting to have our first talk on one of these topics around December.

Q: Recently Stephan of coreboot mentioned that in the past MITRE said that Chrome OS firmware was more secure than UEFI. Both coreboot+depthcharge’s Verified Boot and UEFI’s Secure Boot both seem pretty similar, in terms of PKI usage. Have you an opinion on the security strength of either of these firmware solutions?
A: We have never evaluated CoreBoot to any level of depth. Hardware-wise, we like the Chromebook requirement to provide physical write protection for the flash chip via a screw. The way that Chromebooks supposedly root their boot trust in the embedded controller hardware, as described to us, sounded like a good idea. But without having actually spent time looking at the platforms, we cannot say much in terms of the security (or lack thereof) relative to UEFI-based systems.

—-[End of interview.]

Thanks Corey and Xeno!
Links:

<blink>THEIR OPROM CHECKER IS RELEASED!</blink>
The code was added 5 days ago, and I missed it!
https://github.com/legbacore/t2e_integrity_check

Upcoming training:
http://gsec.hitb.org/sg2015/sessions/tech-training-6-introductory-bios-smm-attack-defense/
https://ruxconbreakpoint.com/training/bios/
http://www.legbacore.com/Training.html

Stephan’s comment on coreboot security: