SeaBIOS 1.10.0 released!

Kevin O’Connor announced the 1.10.0 release of SeaBIOS.

New in this release:
* Initial support for Trusted Platform Module (TPM) version 2.0
* Several USB XHCI timing fixes on real hardware
* Support for “LSI MPT Fusion” scsi controllers on QEMU
* Support for virtio devices mapped above 4GB
* Several bug fixes and code cleanups

Multiple contributors: Kevin O’Connor, Stefan Berger, Gerd Hoffmann, Igor Mammedov, Dana Rubin, Marcel Apfelbaum, Alex Williamson, Cao jin, Cole Robinson, Don Slutz, Haozhong Zhang, Matt DeVillier, Paolo Bonzini, Piotr Król, Roger Pau Monne, and Zheng Bao.

More info:



IAEA Director: German Nuclear Plant Experienced Cyber Attack

STUXXNET is old news, apparently. As reported by SANS, a year ago a nuclear power plant, probably in Germany, was attacked by malware.

The director of the United Nation’s (UN’s) International Atomic Energy Agency (IAEA) said that an unnamed nuclear power plant suffered a cyberattack within the last three years. Yukiya Amano said that the targeted plant was not forced to shut down operations, and that “This issue of cyber attacks on nuclear-related facilities or activities should be taken very seriously.” Amano said that IAEA is helping nuclear facilities around the word improve cyber and physical security.
The director of IAEA is most likely referring to the incident involving a Korea Hydro & Nuclear Power (KHNP) plant, but recent discoveries in Germany of aged malware infections on plant process control equipment is also troubling. The nuclear industry has been well positioned to defend against Internet-borne, non-targeted, threats based because they adopted secure network architectures early, but they are now struggling to address human-enabled (e.g. infected USBs) and highly targeted cyber threats. The next step for the industry will be to transform its cyberdefense strategies from prevention-focused to a more active defense. Active defense is based on the assumption that intrusions will occur, and effective defense focuses on rapid detection of failures along with rapid collapse of free-time available to attackers.



Nuclear Power Plant Disrupted by Cyber Attack

IAEA Cautions on Cybersecurity Risks to Nuclear Power Plants

I wonder what malware was used, was it firmware-centric? Is ‘critical infrastructure’ really secured any better than COTS consumer devices? Do they use Intel x64 systems with UEFI-based blogs than can be tested with CHIPSEC?



Wow, there are a lot of Rowhammer stories in the news recently.



Drammer: Flip Feng Shui Goes Mobile





Matthew and James on IoT security

Matthew Garret and James Bottomley have two blog posts out on IoT security.

I have nearly given up on IoT security, there is so much new IoT vulnerabilities in the news each day.😦


Home Automation: Coping with Insecurity in the IoT


Jacob Torrey: coding in a post-Rowhammer world

Jacob Torrey has a presentation on ROWHAMMER:

[…] Earlier this year at TROOPERS I presented on how many tenets of the LangSec theories could be integrated into a modern SDLC through providing a framework for “verification-oriented programming”. This idea revolved around the notion that “to err is human, to be caught at compile-time (or as close to it as possible) divine”, and that developers are going to make mistakes, but a good SDLC should be able to catch those bugs rapidly. […]




Dmytro takes on the Intel NUC

Dmytro Oleksiuk has a new blog post with UEFI security issues with an Intel NUC using AMI Aptio UEFI BIOS.

(Sad to see that Intel appears to not appear to run CHIPSEC as part of release management QA their own NUCs.)

Exploiting AMI Aptio firmware on example of Intel NUC
[…] Today I’m sharing with you the story of my next x86 machine hacking — we’re going to talk about UEFI vulnerabilities, exploit mitigation features of System Management Mode and new exploit called Aptiocalypsis. Also, this time I did responsible disclosure to Intel and AMI, so, at the moment of this publication you already can patch some of vulnerable products.

Lots of interesting things happened since release of ThinkPwn exploit. Firstly I supposed that vulnerable code was written by Lenovo or its Independent BIOS Vendor (IBV), but later it turned out that they’ve taken this totally mad driver from Intel reference code. This exact code is not available in public, but open source firmware of some Intel boards has it too. For example, SmmRuntimeManagementCallback() function from Intel Quark BSP it’s exactly the same vulnerable code that I’ve found in firmware of my T450s. It’s also interesting that vulnerable code is quite old (it comes from EFI 1.x era) but nevertheless, it was never present in EDK2 source from public repository — its version of QuarkSocPkg was heavily modified in comparison with vulnerable one. The horrible and vulnerable by design piece of code was removed by Intel somewhere in the middle of 2014, but it seems that there were no security advisories regarding this issue. Due to this IBVs had no chance to fix this vulnerability in their relatively old code base and the bug appeared in modern computers from Lenovo, Intel, GIGABYTE, Dell, HP, Fujitsu and other OEM’s (oops!).

Well, I guess at this point it’s much or less clear that currently there’s nothing to do with ThinkPad anymore, it was pwned with 0day, it has too awkward code base that follows ancient version of EFI specification and 8 series chipset that is not the freshest stuff you can get. As my next target for firmware security adventures I’ve decided to take some Skylake based machine of well-known vendor who might have a decent firmware that would be interesting to break. Because I like all kinds of small x86 compatible computers, I’ve put my eye on the latest generation of Intel NUC. It also looks interesting because platform vendor knows his hardware better than anyone else, so, from firmware security perspective, Intel NUC is definitely not the worst choice.[…]




Dirty COW Linux security issue

From the OSS-Security list, some details on a new “Dirty COW” Linux security issue:

CVE-2016-5195 “Dirty COW” Linux kernel privilege escalation vulnerability

This was brought to the linux-distros list (and briefly inadvertently to the distros list, although discussion continued on linux-distros only) on October 13 and it was made public yesterday, so it must be in here as well.  Unfortunately, no one posted about it in here so far (the person who brought this to [linux-]distros must have done so!), and I don’t have time to make a proper posting (with full detail in the message itself, as per oss-security list content guidelines), but I figured it’s better for me to post something than nothing at all.

Red Hat’s description:

“A race condition was found in the way the Linux kernel’s memory subsystem handled the copy-on-write (COW) breakage of private read-only memory mappings.  An unprivileged local user could use this flaw to gain write access to otherwise read-only memory mappings and thus increase their privileges on the system.”