Tag: Intel

Intel AMT remotely exploitable since 2008?

~ hucktech ~ Leave a comment

Remote security exploit in all 2008+ Intel platforms
Nehalem through Kaby all remotely and locally hackable
May 1, 2017 by Charlie Demerjian
Every Intel platform from Nehalem to Kaby Lake has a remotely exploitable security hole. SemiAccurate has been begging Intel to fix this issue for literally years and it looks like they finally listened. The short version is that every Intel platform with AMT, ISM, and SBT from Nehalem in 2008 to Kaby Lake in 2017 has a remotely exploitable security hole in the ME (Management Engine) not CPU firmware. If this isn’t scary enough news, even if your machine doesn’t have SMT, ISM, or SBT provisioned, it is still vulnerable, just not over the network. For the moment. From what SemiAccurate gathers, there is literally no Intel box made in the last 9+ years that isn’t at risk. This is somewhere between nightmarish and apocalyptic.[…]

Remote security exploit in all 2008+ Intel platforms

 

UEFI UDK2017 pre-release available

~ hucktech ~ Leave a comment

Brian Richardson of Intel announced a pre-release of UDK2017, a snapshot of the Tianocore.org EDK2 trunk code matching a set of UEFI.org specs.

Information on UDK2017, the next stable snapshot release of EDK II, is available on the TianoCore wiki.

From the release page on the wiki, here’s the list of

UDK2017 Key Features
    Industry Standards & Public Specifications
        UEFI 2.6
        UEFI PI 1.4a
        UEFI Shell 2.2
        SMBIOS 3.1.1
        Intel® 64 and IA-32 Architectures Software Developer Manuals
    Storage Technologies
        NVMe
        RAM Disk (UEFI 2.6, Section 12.17, RAM Disk Protocol)
    Compilers
        GCC 5.x
        CLANG/LLVM
        NASM
    OpenSSL 1.1.0
    UEFI HTTP/HTTPS Boot
    Adapter Information Protocol
    Regular Expression Protocol
    Signed Capsule Update
    Signed Recovery Images
    SMM Communication Buffer Protections
    STM Launch
    Memory Allocation/Free Profiler
    NX Page Protection in DXE
    LZMA Compression 16.04
    Brotli Compression
    MP Init Library

https://github.com/tianocore/tianocore.github.io/wiki/UDK2017

More info:
https://lists.01.org/mailman/listinfo/edk2-devel

CHIPSEC whitelist gets updated

~ hucktech ~ Leave a comment

https://github.com/advanced-threat-research/efi-whitelist

microparse

~ hucktech ~ 1 Comment

“Microparse: Microcode update parser for AMD, Intel, and VIA processors written in Python 3.x.”

Security Analysis of x86 Processor Microcode
Daming D. Chen, Gail-Joon Ahn
December 11, 2014

Modern computer processors contain an embedded firmware known as microcode that controls decode and execution of x86 instructions. Despite being proprietary and relatively obscure, this microcode can be updated using binaries released by hardware manufacturers to correct processor logic faws (errata). In this paper, we show that a malicious microcode update can potentially implement a new malicious instructions or alter the functionality of existing instructions, including processor-accelerated virtualization or cryptographic primitives. Not only is this attack vector capable of subverting all software-enforced security policies and access controls, but it also leaves behind no postmortem forensic evidence due to the volatile nature of write-only patch memory embedded within the processor. Although supervisor privileges (ring zero) are required to update processor microcode, this attack cannot be easily mitigated due to the implementation of microcode update functionality within processor silicon. Additionally, we reveal the microarchitecture and mechanism of microcode updates, present a security analysis of this attack vector, and provide some mitigation suggestions. A tool for parsing microcode updates has been made open source, in conjunction with a listing of our dataset.

https://github.com/ddcc/microparse

 

Click to access 2014_paper_microcode.pdf

 

Intel cancels Intel Developer Forum

~ hucktech ~ Leave a comment

http://www.anandtech.com/show/11279/intel-discontinues-the-intel-developer-forum-idf17-cancelled

http://www.intel.com/content/www/us/en/intel-developer-forum-idf/san-francisco/2017/idf-2017-san-francisco.html

PS: In other event news, the Fall UEFI Plugfest will be in Taipei instead of Seattle. See the presentations from the last plugfest for details.

details on Intel’s Bug Bounty Program

~ hucktech ~ Leave a comment

The Intel Security Center now has a new page that describes Intel’s Bug Bounty Program:

Intel® launches its first bug bounty program
Intel® Bug Bounty Program

At the CanSecWest Security conference on March 14, 2017, Intel launched its first Bug Bounty program targeted at Intel Products. We want to encourage researchers to identify issues and bring them to us directly so that we can take prompt steps to evaluate and correct them, and we want to recognize researchers for the work that they put in when researching a vulnerability. By partnering constructively with the security research community, we believe we will be better able to protect our customers.

Scope and Severity Ratings

Intel Software, Firmware, and Hardware are in scope. The harder a vulnerability is to mitigate, the more we pay
Vulnerability Severity     Intel Software     Intel Firmware     Intel Hardware
Critical     Up to $7,500     Up to $10,000     Up to $30,000
High     Up to $2,500     Up to $5,000     Up to $10,000
Medium     Up to $1,000     Up to $1,500     Up to $2,000
Low     Up to $500     Up to $500     Up to $1,000

A few details on items that are not in the program scope:

    Intel Security (McAfee) products are not in-scope for the bug bounty program.
    Third-party products and open source are not in-scope for the bug bounty program.
    Intel’s Web Infrastructure is not in-scope for the bug bounty program.
    Recent acquisitions are not in-scope for the bug bounty program for a minimum period of 6 months after the acquisition is complete.

https://security-center.intel.com/BugBountyProgram.aspx

https://security-center.intel.com/default.aspx

 

Intel updates Minnowboard firmware, and Firmware Engine for Windows

~ hucktech ~ Leave a comment

Intel has updated their UEFI firmware for the Minnowboard, and has updated Intel Firmware Engine for Windows.

 

 

CHIPSEC 1.3.0 released

~ hucktech ~ Leave a comment

New/updated modules:
* tools.uefi.whitelist – The module can generate a list of EFI executables from (U)EFI firmware file or extracted from flash ROM, and then later check firmware image in flash ROM or file against this list of [expected/whitelisted] executables
* tools.uefi.blacklist – Improved search of blacklisted EFI binaries, added exclusion rules, enhanced blacklist.json config file
* tools.smm.rogue_mmio_bar – Experimental module that may help checking SMM firmware for MMIO BAR hijacking vulnerabilities described in “BARing the System: New vulnerabilities in Coreboot & UEFI based systems” (http://www.intelsecurity.com/advanced-threat-research/content/data/REConBrussels2017_BARing_the_system.pdf) by Intel Advanced Threat Research team at RECon Brussels 2017
* tools.uefi.uefivar_fuzz – The module is fuzzing UEFI Variable interface. The module is using UEFI SetVariable interface to write new UEFI variables to SPI flash NVRAM with randomized name/attributes/GUID/data/size.

New/updated functionality:
* Debian packaging support
* Compiling in setup.py and automated loading of chipsec.kext kernel module on macOS
* Internal Graphics Device support including software DMA via Graphics Aperture
* Improved parsing andsearch within UEFI images including update capsules
* Export of extracted EFI firmware tree in JSON format
* Export of CHIPSEC results in JSON format via –json command-line argument
* EFI (de-)compression ported from uefi-firmware-parser project
* Decompression to macOS helper to parse Mac EFI firmware images
* Support of command-line arguments in chipsec_util.py
* SMI count command
* Improved platform dependent Flash descriptor parsing
* ReadWriteEverything helper to work with RWE driver
* map_io_space to improve SPI read performance on Linux
* Native (OS based) access PCI, port I/O and CPU MSR to Linux helper
* Improved chipsec_util.py unit testing

See full announcement for list of bugfixes.

https://github.com/chipsec/chipsec/releases/tag/v1.3.0

 

6-part Youtube BIOS system architecture series

~ hucktech ~ Leave a comment

 

BIOS Session 1 – System Memory Map
BIOS Session 2 – Legacy Region
BIOS Session 3 – HIgh Level Overview of the BOOT flow
BIOS Session 4 – Transaction flows and address decoding part 1
BIOS Session 5 – Transaction flows and address decoding part 2
BIOS Session 6 – PCI Basics and Bus Enumeration

 

 

 

UEFI Plugfest slides uploaded

~ hucktech ~ Leave a comment

https://uefi.blogspot.com/2017/03/uefi-plugfest-2017-in-nanjing.html

Tim Lewis of Insyde has a blog post with an update for the UEFI plugfest. *Multiple* presentations on security!!

 State of UEFI – Mark Doran (Intel)
 Keynote: China Information Technology Ecosystem – Guangnan Ni (Chinese Academy of Engineering).
 The Role of UEFI Technologies Play in ARM Platform Architecture – Dong Wei (ARM)
 ARM Server’s Firmware Security – Zhixiong (Jonathan) Zhang, Cavium
 SMM Protection in EDK II – Jiewen Yao (Intel)
 Server RAS and UEFI CPER – Mao Lucia and Spike Yuan (Intel)
 A More Secure and Better User Experience for OS-based Firmware Update – David Liu (Phoenix)
 UEFI and IoT: Best Practices in Developing IoT Firmware Solutions – Hawk Chen (Byosoft)
 Establishing and Protecting a Chain of Trust with UEFI – David Chen (Insyde)
 Implementation of Hypervisor in UEFI Firmware – Kangkang Shen (Huawei)
 Lessons Learned from Implementing a Wi-Fi and BT Stack – Tony Lo (AMI)
  UEFI Development Anti-Patterns – Chris Stewart (HP)

http://www.uefi.org/learning_center/presentationsandvideos

Tianocore gets Brotli compression support

~ hucktech ~ Leave a comment

BinX Song of Intel has submitted a patch to EDK2 with support for Google’s Brotli compression algorithm.

[PATCH 0/4] MdeModulePkg/BaseTools: Add Brotli algorithm support

Brotli algorithm has a little less compress ratio than Lzma, but has better decompress performance than it.  Add Brotli algorithm support, include Brotli decompression library and tool set.

Brotli is a generic-purpose lossless compression algorithm that compresses data using a combination of a modern variant of the LZ77 algorithm, Huffman coding and 2nd order context modeling, with a compression ratio comparable to the best currently available general-purpose compression methods. It is similar in speed with deflate but offers more dense compression.

More info:
https://lists.01.org/mailman/listinfo/edk2-devel
https://github.com/google/brotli
https://www.ietf.org/rfc/rfc7932.txt
https://groups.google.com/forum/#!forum/brotli

Intel Optane

~ hucktech ~ Leave a comment

Intel launched Optane hardware recently, and there are a few Optane-related blog posts on Intel.com:

https://newsroom.intel.com/news/intel-introduces-worlds-most-responsive-data-center-solid-state-drive/

“New era of memory and it’s not a DRAM. I believe March 19th, 2017 is one of the most exiting days in the Non-Volatile industry when Intel® Optane™ SSD DC P4800X was introduced.[…]”

http://itpeernetwork.intel.com/optane-intel-memory-drive-technology

http://itpeernetwork.intel.com/intel-optane-ssds-aerospike-new-level-fast

http://itpeernetwork.intel.com/applying-intel-optane-ssds-to-mysql-part-1-fast-storage/

http://www.intel.com/content/www/us/en/architecture-and-technology/intel-optane-technology.html

Intel Israel seeks Security Researcher

~ hucktech ~ Leave a comment

[…] Do you want to get your hands on the most cutting edge technology before it reaches the Market? Intel’s SW group is looking for a talented Security Researcher. In this position you will work on ensuring security aspects of Intel software and firmware products. You will be a member of the security evaluation team, located in Haifa, encompassing all aspects of the architecture, design and implementation. How your day will look like (when you are not working on your own personal initiatives) :Identify flaws and vulnerabilities in complex secure systems.Reverse engineering and white box SW analysis.Working with software, hardware, embedded systems, cryptography etc. […]

http://jobs.intel.com/ShowJob/Id/1038620/Security%20Researcher%20%20Software%20Group

LUV announces v2.1-rc2 release

~ hucktech ~ Leave a comment

Ricardo Neri of Intel posted a LONG announcement about LUV V2.1-rc2, most of which included here. There are a LOT of new features in this LUV release!

This is to announce the release of LUV v2.1-rc2. It has been a while since the last time of our last release. This is not the ideal release cadence are working to make changes. We will now release more frequently. We aim to release a new version every 4-5 weeks with the content we accumulate over that period of time. Given the large number of new features and changes in this release, it made sense to release it as rc2 of v2.1 to allow for issues to arise and stabilize towards the next release cycle.

This release include the client side of our telemetrics solution. This solution is based on the implementation done for Clear Linux[1]; abiding Intel privacy policies[2]. Please note that telemetrics is an opt-in feature and is disabled by default and only works for systems within Intel networks. We will work now on the server side of the solution.

In this release we have migrated from systemV to systemd, which is inline with most Linux distributions. Also, our telemetrics client needed it to function. Megha Dey did all the heavy lifting to migrate to systemd; which was not an easy task (kudos to her!). She worked on stabilizing network and revamping our splash screen, which now uses plymouth.

Sai Praneeth Prakhya extended our existing implementation to detect illegal access to UEFI Boot Services memory regions after boot. His extension now allows to detect such access to also conventional memory. Likewise, it now detects these acceses at runtime and long after UEFI SetVirtualAddressMap. This has been quite useful recently to detect bugs related to UEFI capsules in certain firmware implementations.

Gayatri Kammela worked on providing tools to make the netboot images more useful. She completed a reference implementation of an HTTP server to collect test results in a test farm. The documentation of this implementation can be found here[2]; we don’t provide collection services. Of course, the client-side implementation of this solution is part of this release. Along with this solution, she wrote a script to customize a netboot binary (an EFI application) to work with her reference implementation[4].

Naresh Bhat updated the kernel configuration for aarch64. He also worked on providing a more clean, unified and structured kernel command line for all the supported CPU architectures. He also enabled support of netboot images for aarch64.

Fathi Boudra kindly reworked the kernel configuration fragments to avoid unnecessary duplications.

Matt Hart added a new luv.poweroff option.

Configuration of LUV has been simplified by moving all the parameters that the user might configure a LUV.cfg file found in the boot partition of the disk image. No more meddling with the grub.cfg configuration file.

We now provide images built for both GPT and MBR partition schemes.

Updated test suites: We include FWTS V17.03.00, CHIPSEC v1.2.5 plus all the changes available as of this week towards the release of v.1.2.6, which should be coming soon. BITS was bumped to v2079. We use Linux v4.10. This release is based on the Morty version of the Yocto Project.

meta-oe and updates to the build process: Our build process changed a bit. We now include certain components from the  meta-oe layer[5]. Such layer has been added to our repository, but it still need to be added locally to the build/conf/bblayers.conf file when building.

Binary images for x86: A announcement to download binary images for x86 will be sent this week.

See rest of announcement for list of Known Issues, and Fixed Issues.

[1] https://clearlinux.org/features/telemetry
[2] http://www.intel.com/content/www/us/en/privacy/intel-privacy.html
[3] https://github.com/01org/luv-yocto/wiki/Send–LUV-test-results-to-an-HTTP-server
[4] https://github.com/01org/luv-yocto/wiki/Using-LUV-Script-modify_luv_netboot_efi.py
[5] https://layers.openembedded.org/layerindex/branch/master/layer/meta-oe/

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

Intel firmware bug bounty program!

~ hucktech ~ Leave a comment

https://www.hackerone.com/blog/Intel-launches-its-first-bug-bounty-program

 

Intel Xeno Phi memory modes

~ hucktech ~ Leave a comment

James Reinders has an article in InsideHPC describes Intel XeonPhi memory modes:

[…]In this article, I will discuss one of the “mode” options that Intel Xeon Phi processors have to offer unprecedented configurability: memory modes. For programmers, this is the key option to really study because it may inspire programming changes. In my next article, I’ll tackle the other mode option (cluster modes). The memory modes allow the MCDRAM to be used as either a high bandwidth cache or a high bandwidth memory, or a little of each.[…]

http://insidehpc.com/2017/03/intel-xeon-phi-memory-mode-programming-mcdram-nutshell/

 

 

LUV adds EFI_WARN_ON_ILLEGAL_ACCESSES

~ hucktech ~ Leave a comment

Sai Praneeth Prakhya of Intel has posted a patch to the LUV project list, with new clever new abilities to increase LUV’s ability to detect bad UEFI firmware.

Presently, LUV detects illegal accesses by firmware to EFI_BOOT_SERVICES_* regions only during “SetVirtualAddressMap()”. According to UEFI spec, this function will be called only once; by kernel during boot. Hence, LUV cannot detect any other illegal accesses that firmware might do after boot. Moreover, LUV can detect illegal accesses *only* to EFI_BOOT_SERVICES_CODE/DATA regions. This patch set tries to address the above mentioned two issues:
1. Detect illegal accesses to other EFI regions (like EFI_LOADER_CODE/DATA, EFI_CONVENTIONAL_MEMORY)
2. Detect illegal accesses to these regions even after kernel has booted
Recently, we came across machines with buggy firmware that access EFI memory regions like EFI_CONVENTIONAL_MEMORY, EFI_BOOT_SERVICES_CODE/DATA and EFI_LOADER_CODE/DATA even after kernel has booted. Firmware accesses these regions when some efi_runtime_service() is invoked by test cases like FWTS. These illegal accesses can potentially cause kernel hang. Hence, it’s good to have a test case in LUV which can detect these illegal accesses and hence report them to user. This requires making changes to kernel and searching dmesg for relative warnings. As there are 9 patches to linux kernel to enable this feature and putting all these 9 kernel patches in a single LUV patch makes the LUV patch gigantic; hence I have split them into smaller ones (as suggested by Ricardo). The first patch in this series (“linux-yocto-efi-test: Do not support EFI_BOOT_SERVICES_WARN”) removes support to “EFI_BOOT_SERVICES_WARN” and the later patches add all the bits and pieces together and the 10th patch (“linux-yocto-efi-test: Introduce EFI_WARN_ON_ILLEGAL_ACCESSES”) enables the (new) feature.

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