Category: Uncategorized

GCC 7.3 released, with Spectre Variant2 for x86/ppc

~ hucktech ~ Leave a comment

Subject: GCC 7.3 Released
Date: Thu, 25 Jan 2018 10:41:30 +0100 (CET)
To: gcc-announce@gcc.gnu.org, gcc@gcc.gnu.org, info-gnu@gnu.org

The GNU Compiler Collection version 7.3 has been released.

GCC 7.3 is a bug-fix release from the GCC 7 branch containing important fixes for regressions and serious bugs in GCC 7.2 with more than 99 bugs fixed since the previous release.

This release includes code generation options to mitigate Spectre Variant 2 (CVE 2017-5715) for the x86 and powerpc targets.

http://www.gnu.org/order/ftp.html
http://gcc.gnu.org/

PS: Microsoft updated MSC earlier. I’m not sure about status of Intel C Compiler or ARM C compiler. CLang has some changes in the pipeline:

http://llvmweekly.org/issue/210
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180101/214327.html
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20180101/513875.html
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20180101/513630.html

 

a bit more on Spectre/Meltdown

~ hucktech ~ Leave a comment

Meltdown and Spectre: What about drivers?

https://github.com/iadgov/Spectre-and-Meltdown-Guidance

https://github.com/hannob/meltdownspectre-patches

https://github.com/hackingportal/meltdownattack-and-spectre

https://kb.netgear.com/000053240/Security-Advisory-for-Speculative-Code-Execution-Spectre-and-Meltdown-on-Some-ReadyNAS-and-ReadyDATA-Storage-Systems-and-Some-Connected-Home-Products-PSV-2018-0005

Trail of Bits releases McSema 2.0: Framework for lifting x86, amd64, and aarch64 program binaries to LLVM bitcode

~ hucktech ~ Leave a comment

Heavy lifting with McSema 2.0

Four years ago, we released McSema, our x86 to LLVM bitcode binary translator. Since then, it has stretched and flexed; we added x86-64 support, put it on a performance-focused diet, and improved its usability and documentation. McSema wasn’t the only thing improving these past years, though. At the same time, programs were increasingly adopting modern x86 features like the advanced vector extensions (AVX) instructions, which operate on 256-bit wide vector registers. Adjusting to these changes was back-breaking but achievable work. Then our lifting goals expanded to include AArch64, the architecture used by modern smartphones. That’s when we realized that we needed to step back and strengthen McSema’s core. This change in focus paid off; now McSema can transpile AArch64 binaries into x86-64! Keep reading for more details.[…]

Heavy lifting with McSema 2.0

https://github.com/trailofbits/mcsema

https://github.com/trailofbits/mcsema/blob/master/docs/McSemaWalkthrough.md

https://www.trailofbits.com/research-and-development/mcsema/

 

Intel seeks senior security researcher

~ hucktech ~ Leave a comment

Job ID: JR0037962
Job Type: Senior Security Researcher

Intel Security Center of Excellence’s goal is to be a prominent leader in the industry to assure security in computing platforms by conducting advanced security research. If you are a seasoned threat, vulnerability and exploit research expert who craves for tons of fun and pride in raising the security bar for ubiquitous computing systems, we would like you to join us as a proud member of Intel’s Advanced Security Research Team. Through your deep vulnerability analysis and mitigation development expertise, you will influence the security of a variety of Hardware, Firmware, Software & Systems spanning a range of products including Devices, Cloud, Auto, IOT, AI, VR, Drones, and Networks.

* Knowledge of computer architecture CPU, SoC, chipsets, BIOS, Firmware, Drivers, and others

 

Spaces in URLs!

http://jobs.intel.com/ShowJob/Id/1352711/Senior%20Security%20Researcher

Aleph Security: Firehorse: Research & Exploitation framework for Qualcomm EDL (Firehose)

~ hucktech ~ 3 Comments

Exploiting Qualcomm EDL Programmers (1): Gaining Access & PBL Internals
By Roee Hay (@roeehay) & Noam Hadad
January 22, 2018
* QPSIIR-909, ALEPH-2017029, CVE-2017-13174, CVE-2017-5947

There are many guides across the Internet for ‘unbricking’ Qualcomm-based mobile devices. All of these guides make use of Emergency Download Mode (EDL), an alternate boot-mode of the Qualcomm Boot ROM (Primary Bootloader). To make any use of this mode, users must get hold of OEM-signed programmers, which seem to be publicly available for various such devices. While the reason of their public availability is unknown, our best guess is that these programmers are often leaked from OEM device repair labs. Some OEMs (e.g. Xiaomi) also publish them on their official forums. […] In this 5-part blog post we discuss the security implications of the leaked programmers. The first part presents some internals of the PBL, EDL, Qualcomm Sahara and programmers, focusing on Firehose. In Part 2, we discuss storage-based attacks exploiting a functionality of EDL programmers – we will see a few concrete examples such as unlocking the Xiaomi Note 5A (codename ugglite) bootloader in order to install and load a malicious boot image thus breaking the chain-of-trust. Part 3, Part 4 & Part 5 are dedicated for the main focus of our research – memory based attacks. In Part 3 we exploit a hidden functionality of Firehose programmers in order to execute code with highest privileges (EL3) in some devices, allowing us, for example, to dump the Boot ROM (PBL) of various SoCs. We then present our exploit framework, firehorse, which implements a runtime debugger for firehose programmers (Part 4). We end with a complete Secure-Boot bypass attack for Nokia 6 MSM8937, that uses our exploit framework. We achieve code execution in the PBL (or more accurately, in a PBL clone), allowing us to defeat the chain of trust, gaining code execution in every part of the bootloader chain, including TrustZone, and the High Level OS (Android) itself.

The merit of our research is as follows:
* We describe the Qualcomm EDL (Firehose) and Sahara Protocols. (Part 1)
* We created firehorse, a publicly available research framework for Firehose-based programmers, capable of debugging/tracing the programmer (and the rest of the bootloader chain, including the Boot ROM itself, on some devices). (Part 3 & Part 4)
* We obtained and reverse-engineered the PBL of various Qualcomm-based chipsets (MSM8994/MSM8917/MSM8937/MSM8953/MSM8974) using the Firehose programmers and our research framework. (Part 3)
* We obtained the RPM & Modem PBLs of Nexus 6P (MSM8994). (Part 3)
* We managed to unlock & root various Android Bootloaders, such as Xiaomi Note 5A, using a storage-based attack only. (Part 2)
* We managed to manifest an end-to-end attack against our Nokia 6 device running Snapdragon 425 (MSM8937). We believe this attack is also applicable for Nokia 5, and might be even extensible to other devices, although unverified. (Part 5)

Research & Exploitation framework for Qualcomm EDL Firehorse programmers
https://github.com/alephsecurity/firehorse

Exploiting Qualcomm EDL Programmers (1): Gaining Access & PBL Internals
https://alephsecurity.com/2018/01/22/qualcomm-edl-1/

Exploiting Qualcomm EDL Programmers (2): Storage-based Attacks & Rooting
https://alephsecurity.com/2018/01/22/qualcomm-edl-2/

Exploiting Qualcomm EDL Programmers (3): Memory-based Attacks & PBL Extraction
https://alephsecurity.com/2018/01/22/qualcomm-edl-3/

Exploiting Qualcomm EDL Programmers (4): Runtime Debugger
https://alephsecurity.com/2018/01/22/qualcomm-edl-4/

Exploiting Qualcomm EDL Programmers (5): Breaking Nokia 6’s Secure Boot
https://alephsecurity.com/2018/01/22/qualcomm-edl-5/

 

Intel: Root Cause of Spectre/Meltdown Reboot Issues Identified

~ hucktech ~ Leave a comment

https://newsroom.intel.com/news/root-cause-of-reboot-issue-identified-updated-guidance-for-customers-and-partners/

January 22, 2018 […]We have now identified the root cause for Broadwell and Haswell platforms, and made good progress in developing a solution to address it. Over the weekend, we began rolling out an early version of the updated solution to industry partners for testing, and we will make a final release available once that testing has been completed. Based on this, we are updating our guidance for customers and partners: We recommend that OEMs, cloud service providers, system manufacturers, software vendors and end users stop deployment of current versions, as they may introduce higher than expected reboots and other unpredictable system behavior. For the full list of platforms, see the Intel.com Security Center site.[…]

Maritime security and firmware security

~ hucktech ~ Leave a comment

http://cimsec.org/cyberphysical-forensics-lessons-from-the-uss-john-s-mccain-collision/35254

Cyberphysical Forensics: Lessons from the USS John S. McCain Collision
January 22, 2018 Guest Author Leave a comment

By Zachary Staples and Maura Sullivan

[…]To generate network situational awareness sophisticated enough to do cyber forensics, the team will need to search for electronic anomalies across a wide range of interconnected systems. A key component of anomaly detection is the availability of normal baseline operating data, or trusted images, that can be used for comparison. These critical datasets of trusted images do not currently exist. Trusted images must be generated to include a catalog of datasets of network traffic, disk images, embedded firmware, and in-memory processes.

1. Network Traffic:
A common attack vector is to find a computer that has communications access over an unauthenticated network, which issues commands to another system connected to the network (i.e. malware in a water purification system issuing rudder commands). Cyberphysical forensics require network traffic analysis tools to accurately identify known hosts on the network and highlight anomalous traffic. If the trusted images repository contained traffic signatures for every authorized talker on the network, it would allow forensic teams to efficiently identify unauthorized hosts issuing malicious commands.

2. Disk Images:
Every console on the ship has a disk that contains its operating system and key programs. These disks must be compared against trusted images to determine if the software loaded onto the hard drives contains malicious code that was not deployed with the original systems.

3. Embedded Firmware:
Many local control units contain permanent software programmed into read-only memory that acts as the device’s complete software system, performing the full complement of control functions. These devices are typically part of larger mechanical systems and manufactured for specific real-time computing requirements with limited security controls. Firmware hacks give attackers control of systems that persist through updates. Forensic teams will need data about the firmware in the trusted image repository for comparison.

4. In-memory Processes:
Finally, advanced malware can load itself into the memory of a computer and erase the artifacts of its existence from a drive. Identifying and isolating malware of this nature will require in-memory tools, training, and trusted images.

In addition to the known trusted images, future forensic analysis would benefit from representative datasets for malicious behavior. Similar to acoustic intelligence databases that allow the classification of adversary submarines, a database of malicious cyber patterns would allow categorization of anomalies that do not match the trusted images. This is a substantial task that will require constant updating as configurations change. However, there are near-term milestones, such as the development of shipboard network monitoring tools and the generation of reference datasets that would substantively improve shipboard cybersecurity.

[…]

bios-8088: disassembled BIOS from 8088 machines

~ hucktech ~ Leave a comment

Disassembled BIOS from 8088 machines

https://github.com/ricardoquesada/bios-8088

Speaking of old Intel chips:

https://github.com/jeffpar/pcjs
https://github.com/morphx666/x8086NetEmu
https://github.com/nkeck720/tiny-8088

The IBM BIOS reference was a classic, and archives of it exist online:
https://www.google.com/search?q=IBM+BIOS+Interface+technical+reference

 

meltdown-spectre-bios-list: machine-readable list of vendor patches

~ hucktech ~ Leave a comment

Meltdown/Spectre BIOS/Firmware Updates list

This is a list of all products an manufacturers which patched BIOS/Firmware addressing the Meltdown and Spectre vulnerabilities. If you have better info please send pull requests. Why I did this? to have a parseable list for all my hardware

linux
curl -s https://raw.githubusercontent.com/mathse/meltdown-spectre-bios-list/master/README.md | grep “$(cat /sys/devices/virtual/dmi/id/board_name)”

windows – powershell 3.0 or above
$model = (Get-WmiObject -Class Win32_ComputerSystem -ComputerName . | Select-Object -Property Model).Model
$mainboard = (Get-WmiObject Win32_BaseBoard | Select-Object Product).Product
$list = (Invoke-WebRequest https://raw.githubusercontent.com/mathse/meltdown-spectre-bios-list/master/README.md.conten)t
$list.Split(“`n”) | Select-String “$model |$mainboard “

https://github.com/mathse/meltdown-spectre-bios-list

 

MCUBoot: secure bootloader for 32-bit MCUs

~ hucktech ~ Leave a comment

MCUBoot is a secure bootloader for 32-bit MCUs. The goal of MCUBoot is to define a common infrastructure for the bootloader, system flash layout on microcontroller systems, and to provide a secure bootloader that enables easy software upgrade. MCUboot is operating system and hardware independent, and relies on hardware porting layers from the operating system it works with. Currently mcuboot works with both the Apache Mynewt, and Zephyr operating systems, but more ports are planned in the future. RIOT is currently supported as a boot target with a complete port planned.[…]

https://github.com/runtimeco/mcuboot

http://lists.runtime.co/pipermail/dev-mcuboot_lists.runtime.co/2018-January/000261.html

 

Apple seeks Junior UEFI Security Engineer

~ hucktech ~ Leave a comment

 

chipsec/modules/common/cpu/spectre_v2.py

~ hucktech ~ Leave a comment

Re: https://firmwaresecurity.com/2018/01/17/yuriy-working-on-new-hipsec-spectre-test/

https://github.com/chipsec/chipsec/pull/330

Exploit development resource list

~ hucktech ~ Leave a comment

https://github.com/rmusser01/Infosec_Reference/blob/master/Draft/Exploit%20Development.md

I was going to suggest it should’ve been named awesome-exploit-development, but it appears that is already taken:
https://github.com/FabioBaroni/awesome-exploit-development
Going off-topic, but here’re some other recent ‘awesome’ and related resource lists recently noticed:
https://github.com/qazbnm456/awesome-cve-poc
https://github.com/secfigo/Awesome-Fuzzing
https://github.com/meirwah/awesome-incident-response
https://github.com/cugu/awesome-forensics
https://github.com/rshipp/awesome-malware-analysis
https://github.com/hslatman/awesome-threat-intelligence
http://resources.infosecinstitute.com/category/computerforensics/introduction/free-open-source-tools/

PTSecurity: how to run code in Intel ME

~ hucktech ~ Leave a comment

Thursday, January 18, 2018
How to hack a disabled computer or run code in Intel ME
At the recent Black Hat Europe conference, Positive Technologies researchers Mark Ermolov and Maxim Goryachy spoke about the vulnerability in Intel Management Engine 11 , which opens up access to most of the data and processes on the device. This level of access also means that any attacker exploiting this vulnerability, bypassing traditional software-based protection, will be able to conduct attacks even when the computer is turned off. Today we publish in our blog the details of the study.[…]

http://blog.ptsecurity.ru/2018/01/intel-me.html

https://translate.google.com/translate?hl=en&sl=ru&u=http://blog.ptsecurity.ru/2018/01/intel-me.html