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

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/

HPE iLO: multiple remote vulnerabilities (HPESBHF03769 rev.1)

 

Hewlett Packard Enterprise Support Center
HPESBHF03769 rev.1 – HPE Integrated Lights-out 4 (iLO 4) Multiple Remote Vulnerabilities
Document ID: hpesbhf03769en_us
Last Updated: 2017-08-24
Potential Security Impact: Remote: Authentication Bypass, Code Execution:
A potential security vulnerability has been identified in HPE Integrated Lights-out (iLO 4). The vulnerability could be exploited remotely to allow authentication bypass and execution of code. […] Hewlett Packard Enterprise would like to thank Fabien Perigaud of Airbus Defense and Space CyberSecurity for reporting this vulnerability.

https://www.hpe.com/us/en/servers/integrated-lights-out-ilo.html

http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=hpesbhf03769en_us

https://tools.cisco.com/security/center/viewAlert.x?alertId=54930

“Limited details are available to describe this vulnerability or how this vulnerability could be exploited by an attacker. However, a successful exploit of this vulnerability could result in a complete system compromise.”

more on Google Titan

Earlier I pointed out some Google Titan info but didn’t have much info on it:

Google “Titan” secure microcontroller

(nobody left a comment, but a few people commented on it on Twitter.)

In the last few days, there’s more info available now:

https://cloudplatform.googleblog.com/2017/08/Titan-in-depth-security-in-plaintext.html

https://www.blog.google/topics/google-cloud/bolstering-security-across-google-cloud/

https://cloud.google.com/security/

 

 

probably unrelated?:
https://github.com/GoogleCloudPlatform/titan

QubesOS, Invisible Things Lab, and Purism

Purism ships Debian-derived PureOS, and used to ship QubesOS. Now, Qubes is not really an option. I don’t know the full story, below posts give some background.

https://groups.google.com/forum/#!topic/qubes-users/2GfyEz0eYCE

https://puri.sm/posts/2017-07-shipping-update-for-qubes-orders/

https://forums.puri.sm/t/no-longer-listed-on-the-qubes-websites-certification-page/1050/5

https://www.qubes-os.org/news/2015/12/09/purism-partnership/

https://www.qubes-os.org/doc/certified-hardware/#qubes-certified-laptops

https://www.qubes-os.org/doc/system-requirements/

https://www.qubes-os.org/hcl/

https://web.archive.org/web/20170506112157/https://www.qubes-os.org/doc/certified-laptops/

 

Collabora: Changing the Android boot animation

Quick hack: Changing the Android boot animation

Posted on 21/04/2017 by Robert Foss

For various reasons you might want to change the Android boot animation to something other than the stock one, this is how you do it. There exists official documentation for how to create a custom boot animation, but unfortunately it is lacking in actual examples. So this guide is a bit more hands-on. Without covering too much of the same gound as the documentation, let’s have a quick look at what is in a simple bootanimation.zip.[…]

https://www.collabora.com/news-and-blog/blog/2017/04/21/quick-hack-changing-the-android-boot-animation/

https://android.googlesource.com/platform/frameworks/base/+/master/cmds/bootanimation/FORMAT.md

DR.CHECKER: Linux kernel driver vulnerability detection tool

 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

Huawei boot loader vulnerability

3 boot loader/smartphone security vulnerabilities from Huawei. Text of two and links to all 3 are below:

Security Advisory – Out-of-Bounds Memory Access Vulnerability in the Boot Loaders of Huawei Mobile Phones
SA No:huawei-sa-20170816-01-smartphone
Initial Release Date: 2017-08-16
The boot loaders of some Huawei mobile phones have an out-of-bounds memory access vulnerability due to the lack of parameter validation. An attacker with the root privilege of an Android system may trick a user into installing a malicious APP. The APP can modify specific data to cause buffer overflow in the next system reboot, causing out-of-bounds memory read which can continuous system reboot. (Vulnerability ID: HWPSIRT-2017-01070)
This vulnerability has been assigned a CVE ID: CVE-2017-8149. Huawei has released software updates to fix this vulnerability. Successful exploit could cause out-of-bounds memory read, leading to continuous system reboot.
This vulnerability can be exploited only when the following conditions are present: 1) The attacker has gained the root privilege of an Android system and successfully tricked a user into installing the malicious APP. 2) An attacker with the root privilege of an Android system may trick a user into installing a malicious APP. The APP can modify specific data to cause out-of-bounds memory read, leading to continuous system reboot. This vulnerability was reported to Huawei PSIRT by Aravind, Machiry. Huawei would like to thank Aravind, Machiry for working with us and coordinated vulnerability disclosure to protect our customers.[…]

Security Advisory – Authentication Bypass Vulnerability in Huawei Honor 5S Smart Phones
SA No:huawei-sa-20170816-03-smartphone
Initial Release Date: 2017-08-16
Huawei Honor 5S smart phones have an authentication bypass vulnerability due to the improper design of some components. An attacker can get a user’s smart phone and install malicious apps in the mobile phone, allowing the attacker to reset the password and fingerprint of the phone without authentication. (Vulnerability ID: HWPSIRT-2017-07037). This vulnerability has been assigned a CVE ID: CVE-2017-8151. Huawei has released software updates to fix this vulnerability. Successful exploit could allow the attacker to reset the password and fingerprint of the phone. This vulnerability can be exploited only when the following conditions are present: 1) The attacker obtains a user’s smart phone in unlocked state. An attacker can get a user’s smart phone and install malicious apps in the mobile phone, allowing the attacker to reset the password and fingerprint of the phone without authentication. This vulnerability was reported to Huawei PSIRT by security researcher Zhang Qing. Huawei would like to thank Zhang Qing for working with us and coordinated vulnerability disclosure to protect our customers.

http://www.huawei.com/en/psirt/security-advisories/huawei-sa-20170816-01-smartphone-en
http://www.huawei.com/my/psirt/security-advisories/huawei-sa-20170807-01-smartphone-en
http://www.huawei.com/en/psirt/security-advisories/2017/huawei-sa-20170816-03-smartphone-en
http://www.huawei.com/us/psirt

https://www.linkedin.com/in/aravind-kumar-machiry-00459923

https://cn.linkedin.com/in/%E6%B8%85-%E5%BC%A0-4b37b2108

 

Frida 10.4 released

Frida provides quite a few building blocks that make it easy to do portable instrumentation across many OSes and architectures. One area that’s been lacking has been in non-portable use-cases. While we did provide some primitives like Memory.alloc(Process.pageSize) and Memory.patchCode(), making it possible to allocate and modify in-memory code, there wasn’t anything to help you actually generate code. Or copy code from one memory location to another. Considering that Frida needs to generate and transform quite a bit of machine code for its own needs, e.g. to implement Interceptor and Stalker, it should come as no surprise that we already have C APIs to do these things across six different instruction set flavors. Initially these APIs were so barebones that I didn’t see much value in exposing them to JavaScript, but after many years of interesting internal use-cases they’ve evolved to the point where the essential bits are now covered pretty well. So with 10.4 we are finally exposing all of these APIs to JavaScript. It’s also worth mentioning that these new bindings are auto-generated, so future additions will be effortless.[…]

https://www.frida.re/news/2017/08/15/frida-10-4-released/

Android 8.0 (“Oreo”) security changes

https://android-developers.googleblog.com/2017/08/introducing-android-8-oreo.html

https://developer.android.com/about/versions/o/android-8.0-changes.html#security-all

https://developer.android.com/topic/security/index.html

https://developer.android.com/about/versions/o/index.html

 

The Android boot process

The Android boot process
Punya Vashist

[…] Android, by the looks of it, seems to be a simplistic Operating System. However, in contrast, the processes and functions that add up to the OS a majority of the smartphone consumer uses are a lot more complex. The boot process, for starters, is nothing but a bunch of fancy images and animations for the end user. This post aims at breaking the boot process down for those very end users. And I promise a thorough read is all you need to understand the process. Nothing is too complicated if explained the right way.[…]

https://thecyberfibre.com/android-boot-process/

Finnbarr on state of Intel ME hacking tools

Finbarr has a new article on Intel ME, in which he’s wondering if current tools are acquiring bitrot:

[…]It seems to me there is little ongoing work to enhance existing ME analysis tools such as me_unpack or the meloader IDA plugin to support ME firmware versions 9.5.X.X or later. Possible reasons for this state of affairs include the lack of available documentation for ME versions above 9, no ROMB-enabled ME firmware later the version 9 in the wild, or simply that the ME tool developers have moved on to other projects.

https://blog.fpmurphy.com/2017/08/has-intel-me-analysis-tool-development-petered-out.html

Also, this post pointed out an Intel ME web site I had not seen before:

http://me.bios.io/Main_Page

It has an invalid HTTPS cert, and appears to have been last updated a few years ago.

PS: Also, if you are using Finnbarr’s UEFI-Utilities, note that he’s recently started including ThinkPwn as one of the binaries, so be careful how you deploy it. CHIPSEC blacklists ThinkPwn as one of handful of known UEFI malware modules.

Manticore 0.1.4 released

https://twitter.com/feliam/status/898677002789462016

https://github.com/trailofbits/manticore/blob/master/CHANGELOG.md#014—2017-08-18

https://github.com/trailofbits/manticore

Manticore: Symbolic execution for humans

New x86 microcode tool

https://twitter.com/ryanmaple/status/898616746717741058

https://github.com/RUB-SysSec/Microcode

“This repository contains a collection of x86 CPU microcode samples in binary and rtl form. The samples are compiled from scratch and specifically work with AMD’s K10 processor family.”

LLVM can now emit/parse/diff Windows PDBs

PDBs are the sidecar symbol files for Windows. The spec used to be private, now is public, and now it is great to see Clang supporting them. Last time I looked, GCC does not support them.

https://twitter.com/aionescu/status/898829293714784256

http://blog.llvm.org/2017/08/llvm-on-windows-now-supports-pdb-debug.html

Cr4sh’s DmaHvBackdoor.c: Hyper-V backdoor for UEFI

Cr4sh is having fun with Windows Device Guard:

DmaHvBackdoor.c comments:

Part of UEFI DXE driver code that injects Hyper-V VM exit handler backdoor into the Device Guard enabled Windows 10 Enterprise. Execution starts from new_ExitBootServices() — a hook handler for EFI_BOOT_SERVICES.ExitBootServices() which being called by winload!OslFwpKernelSetupPhase1(). After DXE phase exit winload.efi transfers exeution to previously loaded Hyper-V kernel (hvix64.sys) by calling winload!HvlpTransferToHypervisor(). To transfer execution to Hyper-V winload.efi uses a special stub winload!HvlpLowMemoryStub() copied to reserved memory page at constant address 0x2000. During runtime phase this memory page is visible to hypervisor core at the same virtual and physical address and has executable permissions which makes it a perfect place to store our Hyper-V backdoor code. VMExitHandler() is a hook handler for VM exit function of hypervisor core, it might be used for interaction between hypervisor backdoor and guest virtual machines.

WordPress chokes on Github gist-based URLs, so click on initial Tweet above for URL. Or look for entry that matches date: