Tag: Linux

Kees on Linux 4.14 security enhancements

~ hucktech ~ Leave a comment

Kees Cook has a new blog post, talking about new security features in Linux kernel 4.14.

vmapped kernel stack on arm64
set_fs() balance checking
SLUB freelist hardening
setuid-exec stack limitation
randstruct automatic struct selection
structleak passed-by-reference variable initialization
improved boot entropy
eBPF JIT for 32-bit ARM
seccomp improvements

security things in Linux v4.14

Many vulnerabilities found in Linux kernel USB subsystem by syzkaller

~ hucktech ~ Leave a comment

https://twitter.com/kayseesee/status/927923337543655424

Andrey Konovalov posted a bunch of Linux USB vulnerabilities to the OSS-Security list, found using the syzkaller Linux system call fuzzer.

Hi! Below are the details for 14 vulnerabilities found with syzkaller in the Linux kernel USB subsystem. All of them can be triggered with a crafted malicious USB device in case an attacker has physical access to the machine. There’s quite a lot more similar bugs reported [1] but not yet fixed.[…]

The first message had 14 vulns:
http://www.openwall.com/lists/oss-security/2017/11/06/8
This second message has 8 more:
http://www.openwall.com/lists/oss-security/2017/11/08/2

https://github.com/google/syzkaller/blob/master/docs/linux/found_bugs_usb.md
https://github.com/google/syzkaller

Google syzkaller – Linux syscall fuzzer

 

 

 

Linux Security Summit 2017 Summary

~ hucktech ~ Leave a comment

James Morris summarized the recent LSS event, excerpts below. For full message, see his original oss-security list posting.

The 2017 Linux Security Summit (LSS) was held on Sept 14th and 15th in Los Angeles, USA. It was co-located with Open Source Summit North America (previously/including LinuxCon) and the Linux Plumbers Conference (LPC). LSS is unique as a security conference as it’s dedicated to Linux and Open Source, and tends to be focused on defensive security engineering. This year we had refereed presentations, Linux kernel security subsystem updates, and BoF topics. There was also a shared day with LPC (on the 13th), where the TPMs and containers microconfs were held. We’re also seeing continued activity in TPMs (v2.0 stack developoment), integrity/boot verification, hardware-based mitigations, mobile/device, and containers. There are lots of challenges across these areas, and the materials I’ve linked from LSS and LPC are a good place to start if you’re interested in where things are at currently. There was no video this year, unfortunately, and we’ll work on making that happen for next year.

http://events.linuxfoundation.org/events/archive/2017/linux-security-summit
http://events.linuxfoundation.org/events/archive/2017/linux-security-summit/program/schedule
http://events.linuxfoundation.org/events/archive/2017/linux-security-summit/program/slides (in some cases by clicking on the session topics).

Linux Security Summit 2017 Roundup


http://www.paul-moore.com/blog/d/2017/09/linux-security-summit.html
https://tyhicks.com/2017/09/22/2017-Linux-Security-Summit-Day-1/
https://tyhicks.com/2017/09/25/2017-Linux-Security-Summit-Day-2/
https://etherpad.openstack.org/p/LPC2017_TPM
https://etherpad.openstack.org/p/LPC2017_Containers

Click to access LSS-2017-Kernel-Self-Protection-Project.pdf

“Linux/Acpi.A!tr”: Linux ACPI malware?

~ hucktech ~ Leave a comment

I noticed this on an AV vendor’s site, about some Linux-centric (?) ACPI malware. Wish there was more info on it. If you have more details, please leave a Comment on this blog, thanks!

Linux/Acpi.A!tr
ID 7546097
Released Oct 26, 2017

Linux/Acpi.A!tr is classified as a trojan.

A trojan is a type of malware that performs activites without the user’s knowledge. These activities commonly include establishing remote access connections, capturing keyboard input, collecting system information, downloading/uploading files, dropping other malware into the infected system, performing denial-of-service (DoS) attacks, and running/terminating processes. The Fortinet Antivirus Analyst Team is constantly updating our descriptions. Please check the FortiGuard Encyclopedia regularly for updates.

https://www.fortiguard.com/encyclopedia/virus/7546097

MSI-GT7x-VGA-Switch: toggle Intel/Nvidia VGA from UEFI Shell

~ hucktech ~ Leave a comment

MSI-GT7x-VGA-SWITCH: Selects VGA from LINUX or EFI!

These programs or batch scripts will let you swtch the VGA from INTEL to NVIDIA (or the opposite). This is possible at the moment only from Windows (bad choice MSI!). Now it will also be possible from Linux or directly from an EFI SHELL! Intel.nsh and nvidia.nsh are two EFI Shell scripts that can be run directly from EFI shell. Just “make intel” and “make nvidia” to compile the 2 C sources. A reboot is needed afterwards because the VGA is switched by BIOS at boot time.[…]

https://github.com/Zibri/MSI-GT7x-VGA-SWITCH

Linux UEFI Validation Project v2.2-rc1 released

~ hucktech ~ Leave a comment

Megha Dey of Intel has taken over the role of LUV maintainer, and announced the 2.2-rc1 release. Excerpts of announcement are below, read full announcement for list of bugfixes.

This is to announce the release of LUV v2.2-rc1. Firstly, I would inform all of you that I have taken over the role of maintainer of this project from Ricardo Neri. I would like to thank Ricardo for all the guidance and support he has provided to make this release possible. This release comes approximately 3 months after our last 2.1-rc2 release and we are further working to have releases more frequently. It mostly includes updates to yocto, meta-oe, various test suites and kernel version. We have also added a new test suite called pstore-test which will run the pstore selftests of the kernel and added some tests in kernel-efi-warnings to detect machine check errors. Given that this is the first time I am doing the release, it is possible for some issues to arise, hence it made sense to have this release as rc1 of v2.2 to allow stabilization towards the next release cycle.

We added a new test suite called pstore-test. This test-suite will check the pstore behavior and are useful to avoid regressions of pstore. This test-suite will cause a reboot during its execution. The necessary groundwork to ensure these type of test suites can be integrated seamlessly into LUV has also been included in this release.

Also, Ricardo added some tests in kernel-efi-warnings to detect machine check errors such as system bus errors, parity errors, cache errors and TLB errors. Linux has support to detect this underlying mechanism and report the error in the kernel message buffer.

We include FWTS V17.09.00 Chipsec 1.3.3 and NDCTL v58, the latest versions available as of this week.

The release images for x86 (disk and network) will be available on 10/23/2017.

 

https://01.org/linux-uefi-validation/v2.2 (apparently this URL won’t be valid until 10/23?)

https://01.org/linux-uefi-validation

Full announcement:
https://lists.01.org/mailman/listinfo/luv

Linux kernel lockdown patch

~ hucktech ~ 1 Comment

David Howells of Red Hat has posted the latest version of the ‘kernel lockdown’ patch to the Linux-EFI mailing list. The latest patch includes a manpage, see the LWN article below for text. For more info, see the full 27-part patch on the linux-efi mailing list.

AFAICT, no Linux distros use this patch. Why?!

The Kernel Lockdown feature is designed to prevent both direct and indirect access to a running kernel image, attempting to protect against unauthorised modification of the kernel image and to prevent access to security and cryptographic data located in kernel memory, whilst still permitting driver modules to be loaded.

Enabling CONFIG_LOCK_DOWN_KERNEL makes lockdown mode available. Enabling CONFIG_ALLOW_LOCKDOWN_LIFT_BY_SYSRQ will allow a SysRq combination to lift the lockdown. On x86 this is SysRq+x. The keys must be pressed on an attached keyboard. Enabling CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT will cause EFI secure boot to trigger kernel lockdown.

http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=efi-lock-down
http://vger.kernel.org/majordomo-info.html
https://lwn.net/Articles/736910/

NISTIR 8176: Linux app container security

~ hucktech ~ Leave a comment

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

 

more on Google NERF

~ hucktech ~ Leave a comment

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:

Click to access 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

Google NERF: Non-Extensible Reduced Firmware

 

 

Microsoft seeks senior embedded Linux firmware engineer

~ hucktech ~ Leave a comment

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

Ecosystem momentum positions Microsoft’s Project Olympus as de facto open compute standard

CVE-2015-7837: RHEL UEFI Secure Boot

~ hucktech ~ Leave a comment

 

https://twitter.com/security_de/status/910399697986244609

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.

 

Linux IoT and secure firmware updates

~ hucktech ~ Leave a comment

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

 

static analysis of Linux kernel

~ hucktech ~ Leave a comment

Colin has a new blog post about static source analysis of the Linux kernel:

Static analysis on the Linux kernel
There are a wealth of powerful static analysis tools available nowadays for analyzing C source code. These tools help to find bugs in code by just analyzing the source code without actually having to execute the code. Over that past year or so I have been running the following static analysis tools on linux-next every weekday to find kernel bugs: cppcheck, smatch, sparse, clang scan-build, CoverityScan, and The latest gcc. Typically each tool can take 10-25+ hours of compute time to analyze the kernel source; fortunately I have a large server at hand to do this. The automated analysis creates an Ubuntu server VM, installs the required static analysis tools, clones linux-next and then runs the analysis. The VMs are configured to minimize write activity to the host and run with 48 threads and plenty of memory to try to speed up the analysis process.[…]

http://smackerelofopinion.blogspot.com/2017/09/static-analysis-on-linux-kernel.html

 

Linux kernel ACPI-centric CVE-2017-13694: Awaiting Analysis

~ hucktech ~ Leave a comment

CVE-2017-13694
Source: MITRE
Last Modified: 08/25/2017
CVE-2017-13694

This vulnerability is currently awaiting analysis.

The acpi_ps_complete_final_op() function in drivers/acpi/acpica/psobject.c in the Linux kernel through 4.12.9 does not flush the node and node_ext caches 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.

https://nvd.nist.gov/vuln/detail/CVE-2017-13694

https://github.com/acpica/acpica/pull/278/commits/4a0243ecb4c94e2d73510d096c5ea4d0711fc6c0
https://patchwork.kernel.org/patch/9806085/

DR.CHECKER: Linux kernel driver vulnerability detection tool

~ hucktech ~ Leave a comment

 DR.CHECKER : A Soundy Vulnerability Detection Tool for Linux Kernel Drivers

usage: run_all.py [-h] [-l LLVM_BC_OUT] [-a CHIPSET_NUM] [-m MAKEOUT] [-g COMPILER_NAME] [-n ARCH_NUM] [-o OUT] [-k KERNEL_SRC_DIR] [-skb] [-skl] [-skp] [-ske] [-ski] [-f SOUNDY_ANALYSIS_OUT]

optional arguments:
-h, –help show this help message and exit
-l LLVM_BC_OUT Destination directory where all the generated bitcode files should be stored.
-a CHIPSET_NUM Chipset number. Valid chipset numbers are:
1(mediatek)|2(qualcomm)|3(huawei)|4(samsung)
-m MAKEOUT Path to the makeout.txt file.
-g COMPILER_NAME Name of the compiler used in the makeout.txt, This is
needed to filter out compilation commands. Ex: aarch64-linux-android-gcc
-n ARCH_NUM Destination architecture, 32 bit (1) or 64 bit (2).
-o OUT Path to the out folder. This is the folder, which
could be used as output directory during compiling
some kernels. (Note: Not all kernels needs a separate out folder)
-k KERNEL_SRC_DIR Base directory of the kernel sources.
-skb Skip LLVM Build (default: not skipped).
-skl Skip Dr Linker (default: not skipped).
-skp Skip Parsing Headers (default: not skipped).
-ske Skip Entry point identification (default: not
skipped).
-ski Skip Soundy Analysis (default: not skipped).
-f SOUNDY_ANALYSIS_OUT Path to the output folder where the soundy analysis output should be stored.

https://github.com/ucsb-seclab/dr_checker

TPM microconf at 2017 Linux Plumbers Conference

~ hucktech ~ Leave a comment

Matthew Garrett has announced a TPM microconference at the upcoming Linux Plumbers Conference:

I’m pleased to say that after the success last year, there will be another TPM microconference at this year’s Linux Plumbers Conference. The current schedule has this taking place on Wednesday the 13th of September, so just under 4 weeks from now. We have a list of proposals for discussion at http://wiki.linuxplumbersconf.org/2017:tpms but please feel free to add more! I intend to finalise the schedule by the end of next week, so please do so as soon as you can. For those of you who weren’t there, the Linux Plumbers conference is an event dedicated to bringing together people working on various infrastructural components (the plumbing) of Linux. Microconferences are 3 hour long events dedicated to a specific topic, with the focus on identifying problems and having enough people in the room to start figuring out what the solutions should be – the format is typically some short presentations coupled with discussion.

From James Bottomley’s comments on the LPC entry on this microconf:

Following on from the TPM Microconference last year, we’re pleased to announce there will be a follow on at Plumbers in Los Angeles this year. The agenda for this year will focus on a renewed attempt to unify the 2.0 TSS; cryptosystem integration to make TPMs just work for the average user; the current state of measured boot and where we’re going; using TXT with TPM in Linux and using TPM from containers.

http://wiki.linuxplumbersconf.org/2017:tpms

http://www.linuxplumbersconf.org/2017/trusted-platform-module-microconference-accepted-into-the-linux-plumbers-conference/

Full text of Matthew’s email:
https://lists.sourceforge.net/lists/listinfo/linux-ima-devel

eventstat for Linux

~ hucktech ~ Leave a comment

Colin Ian King just tweeted about eventstat. But his tweets are protected, so you have to login to Twitter and Follow him in order to see them.

Eventstat periodically dumps out the current kernel event state. It keeps track of current events and outputs the change in events on each output update. The tool requires sudo to run since it needs to write to /proc/timer_stats to start and stop the event monitoring.

http://kernel.ubuntu.com/~cking/eventstat/

https://github.com/ColinIanKing/eventstat

https://launchpad.net/~colin-king/+snap/eventstat

Maybe there’ll be a blog post on it shortly, as well.

http://smackerelofopinion.blogspot.co.uk/