Tag: Linux

Hardened Linux and firmware

~ hucktech ~ Leave a comment

I recently noticed Hardened Linux, because they were calling CHIPSEC. I just noticed they have some informational pages with info on Intel ME/AMT/UEFI and other technologies:

https://github.com/hardenedlinux/firmware-anatomy

https://github.com/hardenedlinux/firmware-anatomy/blob/master/hack_ME/firmware_security.md

https://github.com/hardenedlinux/firmware-anatomy/tree/master/hack_ME

https://github.com/hardenedlinux/firmware-anatomy/blob/master/hack_ME/me_info.md

https://hardenedlinux.github.io/about3/

https://hardenedlinux.github.io/system-security/2017/07/31/firmware_chipsec.html

https://translate.google.com/translate?hl=enu&u=https://hardenedlinux.github.io/system-security/2017/07/31/firmware_chipsec.html

 

UEFI BoF at LPC

~ hucktech ~ Leave a comment

UEFI Forum member Harry Hsiung of Intel will be presenting a Birds of a Feather presentation titled “The State of UEFI Technology.” The session will cover the latest UEFI specifications and variables, as well as features like HTTP Boot, Wi-Fi, Bluetooth, NVDIMM, Secure Boot and capsule update. Attendees will also learn about the latest UEFI SCT updates and other tests like the Linux UEFI Validation (LUV) and the Linux Firmware Test Suite (FWTS).

http://www.uefi.org/events/upcoming

http://www.uefi.org/node/3738

https://www.linuxplumbersconf.org/2017/

GRSecurity sues Bruce Perens over GPL issues

~ hucktech ~ Leave a comment

Below Register article has a link to the PDF of the court case.

Posted on June 28, 2017 by Bruce
Warning: Grsecurity: Potential contributory infringement and breach of contract risk for customers
It’s my strong opinion that your company should avoid the Grsecurity product sold at grsecurity.net because it presents a contributory infringement and breach of contract risk.[…]

https://perens.com/blog/2017/06/28/warning-grsecurity-potential-contributory-infringement-risk-for-customers/

[…]Defendant is a computer programmer, known for his creation of the Open Source Definition and co-founder of the Open Source Initiative. This action arises from Defendants’ abusive and false claims made on a blog post 1 (“Posting”), on Defendant’s website, http://www.perens.com (the “Website”), regarding Plaintiff’s business, which has resulted in substantial harm to Plaintiff’s reputation, goodwill, and future business prospects.[…]

https://www.theregister.co.uk/AMP/2017/08/03/linux_kernel_grsecurity_sues_bruce_perens_for_defamation/

https://grsecurity.net/

archlinux-fde-uefi

~ hucktech ~ Leave a comment

A collection of brief guides for installing Arch Linux with LUKS full disk encryption over a UEFI based system. While I was further exploring the linux universe seeking the answer to the meaning of life, I met a challenge of never matched difficulty: full disk encryption using LUKS over a UEFI based system. Many are the guides available on the web but none of them fullfilled my thirst for knowledge, as some were for older non-GPT installs or a bit too vague for a first time approach of the argument. Therefore, here I share with you what I’ve learned during my journey… BTRFS as well!

https://github.com/archmirak/archlinux-fde-uefi

UEFI-Boot

~ hucktech ~ Leave a comment

[[
CORRECTION:
It is not a boot loader, is a few bash shell scripts, that calls the efibootmgr to configure UEFI with Linux kernel, presuming a Ubuntu-based system.

I should have read the code before calling the code a boot loader. Mea culpa.
]]

UEFI-Boot is a new UEFI-centric, Linux-centric bootloader that lets you “Boot Linux directly from UEFI firmware (without any bootloader)”:

UEFI Boot – is a small and simple project aimed to organize the loading of linux kernel via UEFI firmware (without any bootloader). The synchronization of UEFI boot options with installed kernel versions is triggered via /etc/kernel/postinst.d and /etc/kernel/postrm.d kernel triggers.

https://github.com/slytomcat/UEFI-Boot

Google NERF: Non-Extensible Reduced Firmware

~ hucktech ~ Leave a comment

 

Open Source Summit North America 2017
September 11-14, 2017 – Los Angeles, CA
Replace Your Exploit-Ridden Firmware with Linux – Ronald Minnich, Google

With the WikiLeaks release of the vault7 material, the security of the UEFI (Unified Extensible Firmware Interface) firmware used in most PCs and laptops is once again a concern. UEFI is a proprietary and closed-source operating system, with a codebase almost as large as the Linux kernel, that runs when the system is powered on and continues to run after it boots the OS (hence its designation as a “Ring -2 hypervisor”). It is a great place to hide exploits since it never stops running, and these exploits are undetectable by kernels and programs. Our answer to this is NERF (Non-Extensible Reduced Firmware), an open source software system developed at Google to replace almost all of UEFI firmware with a tiny Linux kernel and initramfs. The initramfs file system contains an init and command line utilities from the u-root project (http://u-root.tk/), which are written in the Go language.

https://ossna2017.sched.com/event/BCsr/replace-your-exploit-ridden-firmware-with-linux-ronald-minnich-google?iframe=no&w=100%&sidebar=yes&bg=no

https://www.linkedin.com/pulse/open-hardware-servers-step-forward-jean-marie-verdun

Click to access Denver_2017_coreboot_u-root.pdf

U-Root: firmware solution written in Go

https://linuxfr.org/news/un-pas-en-avant-pour-les-serveurs-libres-le-projet-nerf

Baidu releases SGX SDK for Rust

~ hucktech ~ Leave a comment

Rust SGX SDK, v0.2.0 Release

This Rust SGX SDK helps developers write Intel SGX enclaves in Rust programming language. We are proud to have our v0.2.0 Rust SGX SDK released. It is now providing more threading functions, thread local storages, exception handling routines and supports unwind mechanism, as well as support of LARGE ENCLAVE MEMORY with the help of Intel SGX v1.9 (31.75 GB enclave memory tested). Please refer to release notes for further details. And we are working on a white paper for technical details about this project.[…]

https://github.com/baidu/rust-sgx-sdk/releases/tag/v0.2.0

CVE-2017-11472: Linux kernel ACPI KASLR vulnerability

~ hucktech ~ Leave a comment

The acpi_ns_terminate() function in drivers/acpi/acpica/nsutils.c in the Linux kernel before 4.12 does not flush the operand cache and causes a kernel stack dump, which allows local users to obtain sensitive information from kernel memory and bypass the KASLR protection mechanism (in the kernel through 4.9) via a crafted ACPI table.

[…]This causes a security threat because the old kernel (<= 4.9) shows memory locations of kernel functions in stack dump, therefore kernel ASLR can be neutralized. To fix ACPI operand leak for enhancing security, I made a patch which removes the ACPI_EXEC_APP define in acpi_ns_terminate() function for executing the deletion code unconditionally.[…]

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11472
https://nvd.nist.gov/vuln/detail/CVE-2017-11472
https://vuldb.com/?id.104315
https://github.com/acpica/acpica/commit/a23325b2e583556eae88ed3f764e457786bf4df6
https://github.com/torvalds/linux/commit/3b2d69114fefa474fca542e51119036dceb4aa6f

 

Attacking the kernel via its command line

~ hucktech ~ Leave a comment

Attacking the kernel via its command line
June 20, 2017
Nur Hussein

The kernel’s command line allows the specification of many operating parameters at boot time. A silly bug in command-line parsing was reported by Ilya Matveychikov on May 22; it can be exploited to force a stack buffer overflow with a controlled payload that can overwrite memory. The bug itself stems from a bounds-checking error that, while simple, has still been in the Linux kernel source since version 2.6.20. The subsequent disclosure post by Matveychikov in the oss-security list spawned a discussion on what constitutes a vulnerability, and what is, instead, merely a bug.[…]

https://lwn.net/Articles/725860/

Follow-up conversation is interesting, as well. Includes a pointer to a few things, such as this blog post:

On dm-verity and operating systems

 

UEFI/SMM stability and performance improvements in QEMU 2.9 and edk2/OVMF git 296153c5, included with Fedora 26

~ hucktech ~ Leave a comment

Fedora 26 just released, and it ships with QEMU v2.9 and an updated OVMF, which adds SMM security improvements. Quoting email from Laszlo Ersek of Red Hat:

QEMU 2.9 is part of Fedora 26. The full changelog for QEMU 2.9 is here:

http://wiki.qemu.org/ChangeLog/2.9

The broadcast SMI feature is just one tiny line in the huge list (and it only mentions the generic negotiation feature, not the specific broadcast one):

“The q35 machine type offers SMI feature negotiation to interested guest firmware.”

QEMU v2.9 is important for running the SMM driver stack of edk2 — more precisely, machine type “pc-q35-2.9” is important — because it offers negotiable SMI broadcast, i.e., where one VCPU writes to ioport 0xB2, and the SMI is raised synchronously on all VCPUs. See:

https://bugzilla.redhat.com/show_bug.cgi?id=1412313 [ovmf]
https://bugzilla.redhat.com/show_bug.cgi?id=1412327 [qemu]

QEMU v2.10 — more precisely, machine type “pc-q35-2.10” — will bring another SMM-related improvement, although not as critical as SMI broadcast. (And I guess it will be available in Fedora 27.) We call it “extended TSEG”, and it allows the QEMU user to specify more than 8MB SMRAM on the cmdline. This is important if you have a huge number of VCPUs, or huge guest RAM (into the TB range) because those things have a linearly growing SMRAM footprint (albeit with small constant factors). See:

https://bugzilla.redhat.com/show_bug.cgi?id=1447027 [qemu and ovmf, both committed]
https://bugzilla.redhat.com/show_bug.cgi?id=1469338 [libvirt, under design]

The patches (qemu and ovmf) committed for BZ#1447027 above solve the “many VCPUs” question. The “huge guest RAM” question needs more platform code in OVMF; the patch for that is on edk2-devel, pending review:

https://bugzilla.redhat.com/show_bug.cgi?id=1468526 [ovmf, pending review]

More info:
https://getfedora.org/
https://en.wikipedia.org/wiki/System_Management_Mode

Intel releases LUV (Linux UEFI Validation) v2.1

~ hucktech ~ Leave a comment

Today Ricardo Neri of Intel announced the 2.1 release of LUV. In additon to updating Linux to v4.11, FWTS to V17.06.00, CHIPSEC to v1.3.1, BITS to v2079, and NDCTL v56, they also started doing nightly builds. Here are some of the other highlights of this release, from the announcement:

Gayatri Kammela won the prize of the most active contributor with many bug fixes and a new feature. She fixed our netboot image, which was missing the ramdisk(!). She added support for debugging and logging of BITS output via network. Likewise, she reworked the LUV configuration file to make more sense to both humans and computers by making clear when parameters are not used. She also investigated and fixed dependencies in systemd that caused delays in the execution of tests. Lastly, she fixed a couple of build-time bugs.

Naresh Bhat updated our Linux kernel recipe to retrieve the kernel configuration directly from the source tree rather than manually updating it. This helped us to remove those eyesore patches for updating our configuration that needed to be sent every time we bumped to a new kernel version. The overall result looks great and is closer to the intended use of the kernel and Yocto Projects’s scripts to merge multiple configuration fragments. I took this opportunity to sanitize the configuration for x86 to add missing configurations and reorganize them.

Sai Praneeth Prakhya added functionality to dump relevant and useful dumps as part of the testing results. Now LUV is capable of dumping the kernel’s boot log, the contents of the ACPI tables as well as the properties of the CPUs in the system. Very useful! Also, he helped us to bump to Linux v4.11. He also took burden of rebasing our implementation to detect firmware’s illegal memory access in this new version of Linux.

Matt Hart updated our GRUB configuration to automate boots across all CPU architectures by not waiting for human intervention to complete boots.

See the full announcement for lists of Known and Fixed Issues:
https://lists.01.org/mailman/listinfo/luv

In addition to stuff mentioned in LUV announcement, LUV also did some updates to how LUV calls CHIPSEC, see these posts:
https://lists.01.org/pipermail/chipsec/2017-July/thread.html

These days, LUV-live ships with BIOS MBR or UEFI GPT partition types, local or network boot types, and x86 or x64 architecture type, multiple choices for the image:
https://download.01.org/linux-uefi-validation/v2.1/
https://download.01.org/linux-uefi-validation/v2.1/sha256sums.asc

 

Alpine Linux Persistence and Storage Summit

~ hucktech ~ Leave a comment

Christoph Hellwig announced this event on the Linux-NVME mailing list.

We proudly announce the Alpine Linux Persistence and Storage Summit (ALPSS), which will be held from September 27-29 at the Lizumerhuette in Austria. The goal of this conference is to discuss the hot topics in Linux storage and file systems, such as persistent memory, NVMe, multi-pathing, raw or open channel flash and I/O scheduling in a cool and relaxed setting with spectacular views in the Austrian alps. We plan to have a small selection of short and to the point talks, and lots of room for discussion in small groups, as well as ample downtime to enjoy the surrounding. Attendance is free except for the accommodation and food at the lodge, but the number of seats is strictly limited. […] Note: The Lizumerhuette is an Alpine Society lodge in a high alpine environment. A hike of approximately 2 hours is required to the lodge, and no other accommodations are available within walking distance.

Full announcement:

http://lists.infradead.org/mailman/listinfo/linux-nvme
http://lists.infradead.org/pipermail/linux-nvme/2017-July/thread.html

 

 

CHIPSEC in BlackArch Linux

~ hucktech ~ Leave a comment

It has been in there for a while, but I don’t think I’ve seen an announcement.

https://github.com/BlackArch/blackarch/issues/1568
https://github.com/BlackArch/blackarch/tree/master/packages/chipsec
https://www.blackarch.org/tools.html
https://www.blackarch.org/hardware.html
https://www.blackarch.org/downloads.html

So you can use LUV-live to use CHIPSEC in a batch mode, or you can use BlackArch live to use CHIPSEC in an interactive mode.

PS: Kali status:
https://bugs.kali.org/view.php?id=3940
https://github.com/chipsec/chipsec/wiki/Using-CHIPSEC-with-Kali-Linux

PaX legal warning

~ hucktech ~ Leave a comment

Guys, this is your *last warning*. This stops *now* or I’m sending lawyers after you and the companies paying you to plagiarize our work and violate our *registered* copyright (which for the record entitles us to punitive damages which now are very easily provable). It’s time to get serious about attribution — what you are doing is completely unacceptable. I’m already in contact with lawyers to prepare for the next time this happens. If any of this plagiarized and misattributed code actually made it into the Linux kernel, you’d all be in a world of pain.

http://openwall.com/lists/kernel-hardening/2017/06/03/14

http://www.openwall.com/lists/kernel-hardening/2017/06/03/11

Linux kernel patch for ACPI HMAT support

~ hucktech ~ Leave a comment

Ross Zwisler of Intel posted a new patch to the Linux kernel, with support for the ACPI 6.2 HMAT (Heterogeneous Memory Attribute Table).

This series adds kernel support for the Heterogeneous Memory Attribute Table (HMAT) table, newly defined in ACPI 6.2. The HMAT table, in concert with the existing System Resource Affinity Table (SRAT), provides users with information about memory initiators and memory targets in the system. A “memory initiator” in this case is any device such as a CPU or a separate memory I/O device that can initiate a memory request. A “memory target” is a CPU-accessible physical address range. The HMAT provides performance information (expected latency and bandwidth, etc.) for various (initiator,target) pairs. This is mostly motivated by the need to optimally use performance-differentiated DRAM, but it also allows us to describe the performance characteristics of persistent memory. The purpose of this RFC is to gather feedback on the different options for enabling the HMAT in the kernel and in userspace.

==== Lots of details ====
[…]

See the patch, especially more details in comment documentation in part 0, on the linux-acpi mailing list posting.

Click to access ACPI_6_2.pdf

http://vger.kernel.org/majordomo-info.html
http://marc.info/?l=linux-acpi&r=1&b=201706&w=2