Critical bug in Xen hypervisor

Wow, Joanna of ITL says “IMHO this is the worst bug affecting Xen, ever.”

Excerpt from Qubes Security Bulletin #22:

Critical Xen bug in PV memory virtualization code (XSA 148)

The Xen Security Team has announced a critical security bug (XSA 148) in the hypervisor code handling memory virtualization for the PV VMs [1]:

| The code to validate level 2 page table entries is bypassed when
| certain conditions are satisfied.  This means that a PV guest can
| create writeable mappings using super page mappings.
|
| Such writeable mappings can violate Xen intended invariants for pages
| which Xen is supposed to keep read-only.

The above is a political way of stating the bug is a very critical one. Probably the worst we have seen affecting the Xen hypervisor, ever. Sadly.
[…]

Full advisory:

https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-022-2015.txt

The Platform on Intel 3D Xpoint memory

http://www.theplatform.net/2015/10/28/intel-shows-off-3d-xpoint-memory-performance/

ThePlatform is a really nice news site, they generally have very well written articles.

This new 3D Xpoint memory technology was announced at Intel SDR this Summer. I’ll admit, I still haven’t internalized what this new memory means for the future of computing, nor firmware (eg, how it impacts UEFI), nor firmware security.. 😦 I don’t recall seeing any Tiancore.org checkins for this, I’ll check for that next time I study the next code update.

New ITL research on x86 security!!

Joanna of Invisible Things Lab has a new blog post on Intel x86 security!!

http://blog.invisiblethings.org/2015/10/27/x86_harmful.html

Click to access x86_harmful.pdf

http://blog.invisiblethings.org/papers/2015/x86_harmful.epub

https://github.com/rootkovska/x86_harmful

And there’s a second paper in the works, as well!

USB Armory security

Two stories, 1 post:

1) USB Armory, an Open Source Hardware-based ARM device by Inverse Path, has secured it’s boot sequence, and uses the term “Secure Boot”, not to be confused by UEFI Secure Boot, and have finished documenting it:

Excerpt, just of the disclaimer, since it is a serious one:

IMPORTANT DISCLAIMER: enabling secure boot functionality on the USB armory SoC, unlike similar features on modern PCs, is an irreversible action that permanently fuses verification keys hashes on the device. This means that any errors in the process or loss of the signing PKI will result in a bricked device incapable of executing unsigned code. This is a security feature, not a bug. The activation and use of the secure boot functionality is therefore at your own risk and must be approached with care.

https://github.com/inversepath/usbarmory/wiki/Secure-boot

2) A second USB Armory story:

https://twitter.com/Yann2192/status/658590304392650752

WordPress.com processes URLs I include in text, including embedding the entire docment of git.github-based URLs, I have to split this URL in have, you’ll have to recombine it, sorry (alternately, click on the URL inside the Twitter ‘box’ above):
https://gist.github.com/
yann2192/f989143c86567237460e

Another UEFI Hello World sample project

There’s a new hello world sample on using UEFI on Github, MyPkg by KurtQiao. The GPL-licensed sample code does a variety of things to experiment with UEFI:

* AHCI: sample how to manipulate AHCI mmio issue HDD identify cmd and ODD eject cmd.
* ctest: a uefi sample import c language.
* HddId: sample how to identify HDD data,support both AHCI and IDE mode.
* HiiMenu: sample how to use uefi HII.
* bootmgr: sample to manipulate UEFI variables, show/set BootOrder, show Boot####, BootCurrent.
* GPT: sample to read disk LBA1 to check GPT signature.
* 2048: small game in UEFI shell
* pwcyle utility that shutdown and RTC wakeup, support both DOS version and UEFI version, by different build.

This is a good starting point for UEFI beginners to start learning about UEFI, beyond just working with the single hello world app in Tianocore, and the rest of the live implementation code. It is similar to the “Bare Metal Examples” project, in this regard. As well, the Intel SSG UEFI training courseware lab samples are also good for this, though mostly targetting an IHV/OEM audience.

https://github.com/kurtqiao/MyPkg

TechCrunch on IoT security

As pointed out by Atmel Corp, Ben Dickson wrote an article on TechCrunch, entitled “Why IoT Security Is So Critical”. Excerpts:

“More connected devices mean more attack vectors and more possibilities for hackers to target us.”

“More effort needs to be made to secure IoT-related data to ensure the privacy of consumers and the functionality of businesses and corporations.”

The rest of the article is a history of some recent attacks in the media, and new IoT security orgs that’ve been created. Excerpts from Reader Comments:

“I can’t wait until some hacker can use my IoT toaster to burn my house down. The future is so exciting!”

Article:

Why IoT Security Is So Critical

Whitepaper from Legbacore on Thunderstrike

At GSEC HITB Singapore 2015, Legbacore gave pre-conference training. As well, they gave a presentation on Thunderstrike. Beyond the presentation slides, the whitepaper is now available!

http://gsec.hitb.org/materials/sg2015/

Click to access D2%20-%20Xeno%20Kovah%20-%20Thunderstrike%202%20-%20Sith%20Strike.pdf

Click to access Xeno%20Kovah%20-%20Thunderstrike%202%20-%20Sith%20Strike.pdf

Hack.lu 2015 Radare2 firmware hacking workshop materials

There was a Radare2 workshop at HACK.LU 2015, which included firmware targets. Check out the github’s top-level readme, Chapter 2 on Firmware.  There are some UEFI-based demos in the Github project, as well.

https://github.com/XVilka/hacklu
http://archive.hack.lu/2015/

Click to access radare2-workshop-slides.pdf

http://archive.hack.lu/2015/radare2-workshop/
http://2015.hack.lu/archive/2015/radare2-workshop/vm/

seeking overhead projector malware pointer

Q: Do you recall the news story earlier this year about an overhead projector that was infecting systems that connected to it? I seem to recall it, but can’t find it online. if you have a pointer to it, please leave a Comment (see left) or email me (see upper right).

I spoke yesterday at SeaGL, and in the slides I mentioned this. I MISTAKINGLY mentioned it under the scope of a Thunderbolt adapter. I don’t think think news story was related to Thunderbolt.

Thanks!

PS: The blog post from the other day, on “A PRIORI FILE”, see the COMMENTS section for 2 comments from CodeRush with additional details, including a screenshot of one inside UEFItool. I’ll do a follow-up post on this next week, with canon pointers to spec and code, after I’ve had a moment to do that research.

Laszlo’s OVMF SMM patch status

Laszlo Ersek of Red Hat has a huge patch to Tianocore, which adds SMM to OVMF, and just posted a detailed status update to the EDK2-devel mailing list, The current test results of patch look impressive! Pretend the following table is using a fixed font:

  accel  bits  guest OS         OS boots  efibootmgr works on  S3 resume
  —–  —-  —————  ——–  ——————-  ———
  TCG    32    Fedlet 20141209  pass[1]   BSP and AP           pass
  TCG    64    F21 XFCE LiveCD  pass[1]   BSP and AP           fail[2]
  KVM    32    Fedlet 20141209  pass      BSP and AP           pass
  KVM    64    F21 XFCE LiveCD  pass      BSP and AP           fail[2]
  KVM    64    Windows 8.1      pass      n/a                  fail[2]

I’ve excerpted the key items from the TODO section of the status report: 🙂

* TODO:
– celebrate a bit this weekend (look at that “OS boots” column!)
– celebrate some more?

Full status report (including most of the details, and the omitted footnotes listed above):

http://article.gmane.org/gmane.comp.bios.edk2.devel/3357

(Also note that the EDK2-devel mailing list, which recently moved from SourceForge.net to Intel’s 01.org, is now hosted on Gmane under the gmane.bios.edk2 namespace. The previous SourceForge list is listed under the gmane.bios.tianocore namespace.)

Dual-Booting Kali2 and Windows10 with Secure Boot

https://twitter.com/linuxworldwide/status/656321205805318144

As Windows systems secure their boot process, the ability to install other OSes on a PC gets more difficult. Here’s a recent tutorial that helps show how some of the issues involved in getting a Linux to dual-boot alongside modern Windows with Secure Boot. If you use another Linux distro, the same site has other Windows UEFI dual-boot articles for multiple other distros.

How to dual-boot Windows 10, Kali Linux 2 on a PC with UEFI firmware

slides from today, SeaGL talk, defensive UEFI for sysadmins

I’m giving the below presentation later today at “SeaGL”, pronounced “Seagull”, the Seattle GNU/Linux Conference.

It is based on the presentation given earlier at SASAG.org and BsidesPDX.org. This one is shorter, for a 1-hour timeslot, with more concise NIST advice and “other tools” section, various other cleanups, and a few additions for a Free Software-centric audience.

The Intel LUV team was kind enough to send me some thumbdrives of LUV-live. The first dozen attendees gets a thumbdrive. THANKS, Intel!

https://osem.seagl.org/conference/seagl2015/proposal/4

Click to access 20151023-seagl.pdf

UEFI’s A Priori File

UEFI has an “A Priori File”, which lets vendors list the explicit drivers to load, to override traditional hardware bus enumeration. This is a security issue: if an attacker was able to modify this, then the game is over, their drivers are loaded. From a Tianocore FAQ:

There is another method called an a priori file. There can be one per Firmware volume. This will tell the dispatcher what order to dispatch list drivers in the order they need to dispatch them. This is a manual order. It does not need to be in any specific place in the FV. If it in the FV the dispatcher will find it.

Bluntly, I don’ t know the right way to efficiently search for A Priori Files on UEFI systems, probably using GUIDs via UEFI Tool. EDK-I — but not, apparently, EDK-II — had a GenApriorFile tool. If someone knows how, please speak up. Anyway, in an ideal world, you’ll be searching all of your firmware volumes for an A Priori File …as well as the UEFI Shell’s ‘autoexec.bat’ equivalent: startup.nsh, the latter may be anywhere in the path.

http://tianocore.sourceforge.net/wiki/Shell_FAQ#How_does_PEI_core_allocate_Cache_for_keeping_track_of_PEIMs_that_do_not_get_dispatched.3F

http://tianocore.sourceforge.net/wiki/EDK_II_FAQ#Is_an_a_priori_file_checked_first.3F

 

Apple EFI security update for Mac OS X 10.9.5

Apple has announced an EFI securtity update for Mac OS X 10.9.5, apparently due to LegbaCore/MITRE research.

APPLE-SA-2015-10-21-6 Mac EFI Security Update 2015-002

Mac EFI Security Update 2015-002 is now available and addresses the following: EFI
Available for:  OS X Mavericks v10.9.5
Impact:  An attacker can exercise unused EFI functions
Description:  An issue existed with EFI argument handling. This was addressed by removing the affected functions.
CVE-ID: CVE-2015-7035 : Corey Kallenberg, Xeno Kovah, John Butterworth, and Sam Cornwell of The MITRE Corporation, coordinated via CERT
Installation note: Mac EFI Security Update 2015-002 may be obtained from the Mac App Store.

Full message:

http://support.apple.com/kb/HT1222
https://support.apple.com/en-us/HT205317
https://support.apple.com/en-us/HT204934

In addition to this EFI update, Apple has released Multiple Security Updates:
https://www.us-cert.gov/ncas/current-activity/2015/10/21/Apple-Releases-Multiple-Security-Updates

Western Digital drives vulnerable: BadUSB, EvilMaid

Most news sites are reporting about bad security in Western Digital hard drives. As presented at Hardware.io the other week, and from the Full Disclosure mailing list from a few days ago, excerpt below:

Authors: Gunnar Alendal, Christian Kison, modg
Vendor notification: The vendor has been informed of the research.
Patches: The authors are not aware of any fixes.

Research on Western Digital wide-spread self-encrypting hard drive series “My Passport” / “My Book”. Devices researched utilizes mandatory HW AES encryption. Multiple vulnerabilities, including:
* Multiple authentication backdoors, bypassing password authentication
* AES factory key recovery attacks, exposing user data on all affected devices, regardless of user password
* Exposure of HW PRNGs used in cryptographic contexts
* Unauthorized patching of FW, facilitating badUSB/evil-maid attacks

Architectures researched (USB Bridge Vendor – Chip model – Architecture):
 JMicron – JMS538S – Intel 8051
 Symwave – SW6316 – Motorola M68k
 PLX – OXUF943SE – ARM7
 Initio – INIC-1607E – Intel 8051
 Initio – INIC-3608 – ARC 600
 JMicron – JMS569 – Intel 8051

Click to access 1002.pdf

Click to access got-HW-crypto-slides_hardwear_gunnar-christian.pdf

http://seclists.org/fulldisclosure/2015/Oct/79

Academics Find Critical Flaws in Self-Encrypting Hardware Drives

http://www.theregister.co.uk/2015/10/20/western_digital_bad_hard_drive_encryption/

US-CERT Vulnerability Note on CAIN in VMMs

Apparently “Linux KVM”, Parallels, and “Red Hat” are affected.  Microsoft and Xen are not affected. “Oracle”, QEMU, and VMware are unknown. CERT excerpt below, for more information, see full CERT Vulnerability Note and CAIN paper, including a list of other mitigations.

Virtual Machine Monitors (VMM) contain a memory deduplication vulnerability
Vulnerability Note VU#935424

CVE IDs: CVE-2015-2877
Date First Published: 20 Oct 2015

Multiple vendors’ implementations of Virtual Machine Monitors (VMM) are vulnerable to a memory deduplication attack. As reported in the “Cross-VM ASL INtrospection (CAIN)” paper, an attacker with basic user rights within the attacking Virtual Machine (VM) can leverage memory deduplication within Virtual Machine Monitors (VMM). This effectively leaks the randomized base addresses of libraries and executables in the processes of neighboring VMs. Granting the attacker the ability to leak the Address-Space Layout of a process within a neighboring VM results in the potential to bypass ASLR. Impact: A malicious attacker with only user rights within the attacking VM can reliably determine the base address of a process within a neighboring VM. This information can be used to develop a code-reuse or return oriented programming exploit for a known vulnerability in a target process. Attacking the target process is outside the scope of the CAIN attack. Solution: Deactivation of memory deduplication is the only known way to completely defend against the CAIN attack.

CAIN: Silently Breaking ASLR in the Cloud
Antonio Barresi, Kaveh Razavi, Mathias Payer, Thomas R. Gross

Modern systems rely on Address-Space Layout Randomization (ASLR) and Data Execution Prevention (DEP) to protect software against memory corruption vulnerabilities. The security of ASLR depends on randomizing regions in memory which can be broken by leaking addresses. While information leaks are common for client applications, server software has been hardened to reduce such information leaks. Memory deduplication is a common feature of Virtual Machine Monitors (VMMs) that reduces the memory footprint and increases the cost-effectiveness of virtual machines (VMs) running on the same host. Memory pages with the same content are merged into one read-only memory page. Writing to these pages is expensive due to page faults caused by the memory protection, and this cost can be used by an attacker as a side-channel to detect whether a page has been shared. Leveraging this memory side-channel, we craft an attack that leaks the address space layouts of the neighboring VMs, and hence, defeats ASLR. Our proof-of-concept exploit, CAIN (Cross-VM ASL INtrospection) defeats ASLR of a 64-bit Windows Server 2012 victim VM in less than 5 hours (for 64-bit Linux victims the attack takes several days). Further, we show that CAIN reliably defeats ASLR, regardless of the number of victim VMs or the system load.

http://www.kb.cert.org/vuls/id/935424

https://www.usenix.org/conference/woot15/workshop-program/presentation/barresi

Click to access woot15-paper-barresi.pdf

Click to access woot15_slides_barresi.pdf