Uncategorized

NISTIR 8176: Linux app container security

Application Containers are slowly finding adoption in enterprise IT infrastructures. Security guidelines and countermeasures have been proposed to address security concerns associated with the deployment of application container platforms. To assess the effectiveness of the security solutions implemented based on these recommendations, it is necessary to analyze those solutions and outline the security assurance requirements they must satisfy to meet their intended objectives. This is the contribution of this document. The focus is on application containers on a Linux platform.

Keywords: application container; capabilities; Cgroups; container image; container registry; kernel loadable module; Linux kernel; namespace; TPM

 

https://csrc.nist.gov/publications/detail/nistir/8176/final

https://csrc.nist.gov/News/2017/NIST-Releases-NISTIR-8176

http://doi.org/10.6028/NIST.IR.8176

 

Standard
Uncategorized

more on Google NERF

Google NERF looks interesting, they keep UEFI’s PI but replace the UEFI layers with Linux kernel, and the code is written in Go. Looks like they’re focusing on removing dynamic code in UEFI and SMM. Unclear about their position towards dynamic code in ACPI, as well as PCIe (eg, PCIleech-style attacks).

The slides from the recent North American OSS presentation are online, but I can’t find the video online:

http://schd.ws/hosted_files/ossna2017/91/Linuxcon%202017%20NERF.pdf

There’s an upcoming European OSS event upcoming:

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://osseu17.sched.com/event/ByYt/replace-your-exploit-ridden-firmware-with-linux-ronald-minnich-google
https://ossna2017.sched.com/event/BCsr/replace-your-exploit-ridden-firmware-with-linux-ronald-minnich-google
https://osseu17.sched.com/event/ByYt/replace-your-exploit-ridden-firmware-with-linux-ronald-minnich-google

http://u-root.tk/
https://github.com/u-root/u-root

https://firmwaresecurity.com/2017/07/23/google-nerf-non-extensible-reduced-firmware/

 

 

Standard
Uncategorized

Microsoft seeks senior embedded Linux firmware engineer

The Cloud Server Infrastructure Firmware Development (CSI-FW) team is responsible for server hardware definition, design and development of Server and Rack Infrastructure engineering for Microsoft’s online services.
This role will be for a highly-motivated Firmware Engineer with a solid background in embedded system design using embedded Linux.
* 5+ years professional experience in one or many of: designing, developing embedded solutions using ARM SoCs and Linux, extensive u-boot customization, Linux kernel internals and adding new hardware drivers.
* 2+ years proven and demonstrable programming skill in C/C++ for resource constrained embedded platforms.
* Experience with debugging tools such as JTAG, oscilloscopes and bus analyzers.

https://careers.microsoft.com/jobdetails.aspx?jid=321602&job_id=1070761

https://azure.microsoft.com/en-us/blog/ecosystem-momentum-positions-microsoft-s-project-olympus-as-de-facto-open-compute-standard/

Standard
Uncategorized

CVE-2015-7837: RHEL UEFI Secure Boot

 

Vulnerability ID 106841
Red Hat Enterprise Linux UEFI Secure Boot privilege escalation

A vulnerability, which was classified as critical, has been found in Red Hat Enterprise Linux (the affected version is unknown). This issue affects an unknown function of the component UEFI Secure Boot. The manipulation with an unknown input leads to a privilege escalation vulnerability. Using CWE to declare the problem leads to CWE-269. Impacted is confidentiality, integrity, and availability. The weakness was released 09/19/2017 (oss-sec). The advisory is shared for download at openwall.com. The identification of this vulnerability is CVE-2015-7837 since 10/15/2015. The exploitation is known to be easy. An attack has to be approached locally. No form of authentication is needed for a successful exploitation. Neither technical details nor an exploit are publicly available. The price for an exploit might be around USD $5k-$25k at the moment (estimation calculated on 09/20/2017).[…]

https://tsecurity.de/de/206729/Reverse-Engineering/Exploits/Red-Hat-Enterprise-Linux-UEFI-Secure-Boot-erweiterte-Rechte-CVE-2015-7837/
https://vuldb.com/?id.106841
http://nakedsecurity.com/cve/CVE-2015-7837/
https://cxsecurity.com/cveshow/CVE-2015-7837
http://www.openwall.com/lists/oss-security/2015/10/15/6
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-7837
https://www.security-database.com/detail.php?alert=CVE-2015-7837

Comments above seem to incidate a 9/19 update, but I can’t find that, only older messages from 2015-2016. Unclear about current status of this.

 

Standard
Uncategorized

Linux IoT and secure firmware updates

Identifying secure firmware update mechanisms for embedded Linux devices and open source options
September 15, 2017
Alex Gonzalez
[…]With regards to embedded devices, the firmware update mechanism must be not only secure, but also reliable in that it either succeeds in the update or fails to a recoverable state. In no way should the software update brick a device, and it should be able to happen unattended. Most updates must also preserve the previous device state, although on some occasions recovering a device could involve resetting to a default state.[…]

http://www.embedded-computing.com/dev-tools-and-os/identifying-secure-firmware-update-mechanisms-for-embedded-linux-devices-and-open-source-options

 

Standard