Tag: Intel

Linux EFI bootloader control driver

~ hucktech ~ Leave a comment

Matt Gumbel of Intel has submitted a patch to the Linux-EFI and Linux-kernel lists, to add an EFI bootloader control driver to Linux:

efi: Introduce EFI bootloader control driver

This driver intercepts system reboot requests and populates the LoaderEntryOneShot EFI variable with the user-supplied reboot argument. EFI bootloaders such as Gummiboot will consume this variable and use it to control which OS is booted next. We use this with Android where reboot() tells the kernel that we want to boot into recovery or other non-default OS environment. It is the bootloader’s job to guard against this variable being uninitialzed or containing invalid data, and just boot normally if that is the case.

+config EFI_BOOTLOADER_CONTROL
+    tristate “EFI Bootloader Control module”
+    depends on EFI_VARS
+    default n
+    help
+      This driver installs a reboot hook, such that if reboot() is
+      invoked with a string argument NNN, “bootonce-NNN” is copied to
+      the EFI variable, to be read by the bootloader. If the string
+      matches one of the boot labels defined in its configuration,
+      the bootloader will boot once to that label.

For more information, see drivers/firmware/efi/efi-bc.c, the linux-efi or linux-kernel mailing lists:
http://vger.kernel.org/majordomo-info.html

UEFI support for TCG OVAL passwords

~ hucktech ~ Leave a comment

Eric Dong of Intel has submitted an 8-part patch to enable TCG OPAL password support in UEFI:

Enable Opal password solution: These patches used to enable opal password solution in BIOS. Opal feature defined in TCG storage Opal spec. This opal solution is a sample driver shows how to use opal feature in bios. It enables user to config opal feature in the setup page and popup dialog to let user unlock device in boot phase. It auto unlock opal device in S3 resume phase.

  MdePkg: Add definition for TCG Storage Core and Opal specs.
  SecurityPkg: TcgStorageCoreLib: Add TCG storage core library.
  SecurityPkg: TcgStorageOpalLib: Add TCG storage opal library.
  SecurityPkg: OpalPasswordSupportLib: Add Opal password support
    library.
  SecurityPkg: Add library header file definition to package.
  SecurityPkg: OpalPasswordDxe: Add Opal password dxe driver.
  SecurityPkg: OpalPasswordSmm: Add Opal password Smm driver.
  SecurityPkg: Enable Opal password solution build in Security package
    build.

 39 files changed, 21524 insertions(+)

For more information:
https://lists.01.org/mailman/listinfo/edk2-devel

Intel SSD Data Center for SATA exploitable via SATA abuse

~ hucktech ~ Leave a comment

Excerpting Intel Security advisory:

Potential vulnerability in Intel® SSD Data Center Family for SATA
Intel ID: INTEL-SA-00050
Product family: Intel® SSD Data Center Family for SATA
Impact of vulnerability: Denial of Service
Severity rating: Important
Original release: Mar 15, 2016

If the Intel SSD Data Center Family for SATA product receives certain commands that violate the SATA protocol, the drive may stop responding to host commands and, in that event, user data will be inaccessible. The Intel SSD Data Center Family for SATA product series was designed to the ATA-ACS specification. If the Intel SSD Data Center Family for SATA product receives certain commands that violate the SATA protocol, the drive may stop responding to host commands and, in that event, user data will be inaccessible. There is no risk of data corruption as a result of this issue. Platforms with a host implementation that complies with the SATA protocol are not at risk for this issue. Intel recommends that customers with affected product should download and apply the mitigated firmware version using the Intel® Solid State Drive Data Center Tool, which is available from the Intel Download Center (https://downloadcenter.intel.com).

https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00050&languageid=en-fr
https://downloadcenter.intel.com/download/23931/Intel-Solid-State-Drive-Data-Center-Tool

Intel FSP 2.0 in the works?

~ hucktech ~ Leave a comment

As reported by Phoronix, it appears that Intel is working on the 2.0 release of their Firmware Support Package (FSP), the pre-compiled set of firmware binaries needed by most firmware solutions to work Intel systems.

http://www.phoronix.com/scan.php?page=news_item&px=Intel-FSP-2.0-Coreboot
http://anzwix.com/a/Coreboot/SocintelapollolakeEnableUsingFSP20Driver
https://review.coreboot.org/gitweb?p=coreboot.git;a=commit;h=b37fd67e8757e2eaf3ae7dd453e9aaa1518e9439
http://firmware.intel.com/learn/fsp/about-intel-fsp
http://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-support-package/intel-fsp-overview.html

Nikolaj Schlej audits Intel Quark BSP

~ hucktech ~ Leave a comment

William Leara of Dell has a new blog post about Nikolaj Schlej’s new blog post analyzing Intel Quark’s BSP:

Another tip of the cap to Nikolaj Schlej, this time for an interesting article where he examined the Intel Quark Board Support Package (BSP) source code with the static source code analyzer PVS-Studio. The Intel Quark is an SoC used in embedded systems applications.  For example, it runs the Intel Galileo family of development boards.  Galileo is a small computer board comparable to the Arduino family of products, and is targeted to maker and educational customers. The BSP is a set of documentation and EDKII source code that allows a developer to build his own bootable firmware image for the Quark. Nikolaj discovered many serious problems, and I found it educational to read through them.  This is helpful so that you can discover the typical mistakes people make in UEFI development, and also so that you won’t make the same mistakes yourself! […]

http://www.basicinputoutput.com/2016/03/nikolaj-schlej-analyzing-intel-galileo.html
https://habrahabr.ru/post/258721/
http://www.viva64.com/en/b/0326/

Intel releases GLibC advisory

~ hucktech ~ Leave a comment

The Intel Software Center has announced a list of multiple products and services implacted by the recent GLibC bug:

Intel ID:      INTEL-SA-00049
CVE Name:  CVE-2015-7547

Intel Software Products and Services that rely on glibc may be indirectly impacted by CVE-2015-7547. Multiple stack-based buffer overflows in the (1) send_dg and (2) send_vc functions in the libresolv library in the GNU C Library (aka glibc or libc6) prior to version 2.23 allow remote attackers to cause a denial of service (crash) or possibly execute arbitrary code via a crafted DNS response that triggers a call to the getaddrinfo. Intel Products and API services not included in this advisory are considered not to be impacted at this time. Intel Products and API services listed below are potentially impacted indirectly by this issue since those perform DNS lookups and are reliant on the Operating System. End-users should contact their Operating System vendor for a relevant glibc patch to help mitigate CVE-2015-7547. Intel recommends customers contact their Operating System vendor for a relevant glibc patch to help mitigate CVE-2015-7547. […]

https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html
https://googleonlinesecurity.blogspot.com/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html
https://access.redhat.com/articles/2161461

Full advisory:
https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00049&languageid=en-fr

Updating Android devices

~ hucktech ~ Leave a comment

Sam Varghese has a story on ITWire about how Android-based devices are hard to update, including some conversation about firmware:

[…] x86 processors have a long history of standardisation. An x86 processor is mostly made of the CPU and an interface to the BIOS/UEFI firmware on the motherboard. From there the operating system can gather the information about the hardware components present in the system. In comparison, ARM processors, especially in the Android/embedded market are System-on-Chips (SoCs). This means, apart from the CPU the SoC provides most to all peripheral components on one die (e.g. network chip, USB chip, display chip, etc). Apart from that, although ARM has standard components for the core system (e.g. interrupt controller, timers etc), most ARM SoCs implement their custom components here, which needs their own drivers in the kernel. The reason is because many companies which produce ARM-based processors have a long history in the mobile phone market in the pre-smartphone era. They have core components which were developed years ago and they want to re-utilise them, as they have a deep knowledge on how they work and their custom software drivers. Third, especially in the embedded world, the ARM processors don’t use the Unified Extensible Firmware Interface (UEFI) to communicate with the firmware. To tell the Linux kernel which components are present, the bootloader passes a device tree blob to the kernel. So there is no dynamic way to tell the kernel which components are present. This is changing a lot and the Linux community are putting a big effort in standardising the firmware interface (EFI, PSCI, ACPI). […]

http://www.itwire.com/business-it-news/open-source/71698-why-updating-android-without-vendor-help-is-a-nightmare.html

Intel SGX Encryption Engine

~ hucktech ~ Leave a comment

Cryptographic protection of memory is an essential ingredient for any technology that allows a closed computing system to run software in a trustworthy manner and handle secrets, while its external memory is susceptible to eavesdropping and tampering. An example for such a technology is Intel’s emerging Software Guard Extensions technology (Intel SGX) that appears in the latest processor generation, Architecture Codename Skylake. This technology operates under the assumption that the security perimeter includes only the internals of the CPU package, and in particular, leaves the DRAM untrusted. It is supported by an autonomous hardware unit called the Memory Encryption Engine (MEE), whose role is to protect the confidentiality, integrity, and freshness of the CPU-DRAM traffic over some memory range. To succeed in adding this unit to the micro architecture of a general purpose processor product, it must be designed under very strict engineering constraints. This requires a careful combination of cryptographic primitives operating over a customized integrity tree that mostly resides on the DRAM while relying only on a small internally stored root. The purpose of this paper is to explain how this hardware component of SGX works, and the rationale behind some of its design choices. To this end, we formalize the MEE threat model and security objectives, describe the MEE design, cryptographic properties, security margins, and report some concrete performance results.

Click to access 332680-002.pdf

Click to access 204.pdf

https://software.intel.com/en-us/isa-extensions/intel-sgx

BIOS analysis presentation at Analyze 2016

~ hucktech ~ Leave a comment

Analyze 2016 takes place in March in San Francisco. It is a “Security community event for malware and exploit analysis research”. Amongst the presentations is one on BIOS analysis by two of the Intel Advanced Threat Research (ATR) team!

Talks:
Tom Bennett – Whose RAT Is It Anyways?
Aaron Shelmire – Sections, Segments, and Functions, oh my! Hashing your way to analytical shortcuts.
Edward Miles – Making sense of ProGuard’s mess
Oleksandr Bazhaniuk/Yuriy Bulygin – Different methods of BIOS analysis: Static, Dynamic and Symbolic execution
Darren Spruell – Malicious Traffic Distribution: Tactics and Response
Rick Wesson – Static Malware Analysis on GPUs
Chip McSweeney – DGA Antivenom: Stopping new configurations before analysis
Jing Xie – Risks of iOS Remote Hot-Patching
Alexander Matrosov – Distributing the reconstruction of IR for large scale malware analysis
http://www.analyze.cc/Waylon Grange – Wherefore by their crypto ye shall know them
Armin Buescher – Sanzoku APT

http://www.analyze.cc/

Kali for Intel Edison

~ hucktech ~ Leave a comment

hackgnar has a new blog post out, showing how to build Kali for Edison targets:

Building Kali Linux for Intel Edison: This documentation goes though the process of manually building a base Kali Linux image for the Intel Edison board. These steps were derived from frankensteining the edison build scripts for Debian Jessie and some of the Kali Linux ARM build scripts. All of the content from this post can be found in my github repo for this project here, along with pre compiled images (coming soon!) and ansible scripts for automated building. Note, all of these steps were tested in Ubuntu Linux 14.04 x64 LTS. As of this writing, this OS/Version has the most support for doing Edison source builds. I have done these steps in other operating systems, but the process is not as clean due to bugs, script tweaks, etc. […]

http://www.hackgnar.com/2016/02/building-kali-linux-for-intel-edison.html
https://github.com/hackgnar/kali_intel_edison

Brian Richardson on UEFI hacker tools

~ hucktech ~ Leave a comment

https://twitter.com/Intel_UEFI/status/699756428177776640

Brian Richardson of Intel has a new blog out talking about UEFI hacking tools in general, and UEFI Tool in particular, and he mentions this blog! 🙂 (This reminds me, I need to create a list of tools that I promised earlier. Give me a few days and I’ll create a new blog on that…)

“This is where my friends in firmware development and validation need to pay attention, because these tools can be your friend or your enemy. It’s great to use UEFITool for testing firmware images, making sure contents are properly formatted and verifying changes between version updated. However, it’s also an easy way for someone you don’t like to try and insert malicious code into your product.”

http://blogs.intel.com/evangelists/2016/02/16/uefi-tools-theyre-not-just-for-hackers-anymore/

CHIPSEC training at TROOPERS

~ hucktech ~ Leave a comment

The Intel CHIPSEC team doesn’t get out much to give training to the public often, so this upcoming 2-day of CHIPSEC training at TROOPERS is nice!

Security below the OS with CHIPSEC framework
Oleksandr Bazhaniuk, Yuriy Bulygin

A variety of attacks targeting platform firmware have been discussed publicly, drawing attention to the pre-boot and firmware components of the platform such as BIOS and SMM, UEFI secure boot and OS loaders. This workshop provides a hands-on opportunity to learn how to use an open source CHIPSEC framework https://github.com/chipsec/chipsec to test systems for vulnerabilities in low-level platform firmware components, problems with firmware security protections as well as develop your own modules in CHIPSEC which test for known issues or implement tools identifying new issues. Agenda:

* Introduction to platform hardware and access with CHIPSEC
* Introduction to platform firmware such as BIOS, UEFI firmware, SMI handlers
* Overview of main components of CHIPSEC framework
* Analyzing main firmware components and configuration
* Assessing systems for vulnerabilities in the BIOS and other firmware
* Developing vulnerability testing modules
* Developing fuzzers for firmware interfaces and other security tools
* BIOS forensics with CHIPSEC

https://www.troopers.de/events/troopers16/567_security_below_the_os_with_chipsec_framework/

Intel Linux Perf team’s 0-Day project

~ hucktech ~ Leave a comment

The Intel open source site, 01.org, hosts the Linux Kernel Perf project, and they have a 0-Day project.

https://twitter.com/mcgrof/status/698175557423362049

[…] The infrastructure we developed to test the Linux kernel is called 0-Day.  It is a service and test framework for automated regression-testing that intercepts kernel development at its earliest stages, and is available to the worldwide Linux kernel community. This project provides a further “shift-left” by testing key developers’ trees before patches move forward in the development process. Some key features of 0-Day are:

* Provides 1-hour response time around the clock, hence the 0-Day name.
* Performs patch-by-patch tests
* Covers all branches of a developer’s tree
* Performs kernel build and static semantics-level testing using industry static source code analyzers
* Performs boot tests, functional and performance tests on a variety of IA-based platforms in our labs
* Bisects code automatically when tests fail, or when performance regresses, enabling us to identify which patch caused the failure.

More info:
https://lists.01.org/mailman/listinfo/lkp
https://01.org/lkp

I just learned about this, and don’t know much about it yet, It sounds interesting, “performs boot tests”. Maybe it is the Intel version of ARM/Linaro’s LAVA?

Tony Mangefeste, new Tianocore community manager

~ hucktech ~ 1 Comment

Tony Mangefeste of Intel is the new “Community Technology Lead, Tianocore Community Manager”. Yesterday he posted a message to the edk2-devel mailing list with an introduction. Two excerpts:

“I’m your new Tianocore community manager. As best as I can tell, no one has had this role, and I’m the first. And I’m thrilled to have the opportunity to help Tianocore evolve into an awesome-er OSS program.”

“What’s going to change with Tianocore? I hope much positive change will come. More details will follow in the coming weeks. As many of you know, several of our members (led by Erik, Jordan) have been leading the efforts to move to GitHub.  That’s just the tip of the iceberg of improvements that are coming.  If there are barriers to contribution levels, I want to help knock those down.  If we can’t knock them down, I want to navigate around them.”

Full post:
http://article.gmane.org/gmane.comp.bios.edk2.devel/7458

He has just created new Tianocore feeds on Twitter and Google+:
https://twitter.com/tianocore/
https://plus.google.com/communities/104320775708339899382

I noticed a non-ISO-licensed tree in the new Github tree, which may be helpful for Linux, a home non-BSD FOSS code. I hope Tianocore appropriately encourages and maintains this in conjunction with the BSD tree. I hope that in addition to Twitter and Google+ posts, the community manager helps with communinty-led questions about Tianocore, like the FW_OS_Forum. So far this list does not appear to useful for community. It’d be great to see UEFI Forum and it’s members generate a GSoC for Tianocore, most than just maintaining a wishlist of projects on their wiki. I’d like to see more work with UEFI team with coreboot and U-Boot projects using EFI as a payload. I really wish UEFI forum was a bit more open in their events. Right now events are only for members, and the only public events are ‘developer roadshow’-style groomed subset talks. Anyway, enough of me wondering about how Tianocore could do community better. If you have some ideas, contact Tony.

Intel roadshow for Xeon Phi code modernization

~ hucktech ~ Leave a comment

Intel, in partnership with Bayncore, is doing a free roadshow, 1-day workshop in a few European cities, on “code modernization” for the Intel Xeon Phi processor. So far, Dublin, Cambridge. and Barcelona are the only 3 cities listed in the tour. The event is free, so if you’re in the area, use Intel System Studio, and do parallel processing and other coding techniques that need “modernization”, check out this event. Agenda:

INTEL TECHNOLOGY PLATFORM FOR HPC & PROCESSOR UPDATE
MEET INTEL PARALLEL STUDIO XE 2016 – WHAT’S NEW?
OPTIMIZE AND PERFORM WITH INTEL MPI
HPC MEETS BIG DATA – CODING HIGH-PERFORMANCE ANALYTICS IN C++ USING INTEL’S NEW DATA
ANALYTICS ACCELERATION LIBRARY
BEST PRACTICES FOR VECTORIZATION – PARALLELISM AT CORE LEVEL (SIMD)
TUTORIAL – REAL WORLD EXAMPLES FOR VECTORIZATION
CODE OPTIMIZATION IN A 3D DIFFUSION MODEL
CASE STUDY – PAIRWISE SEQUENCE ALIGNMENT WITH THE SMITH-WATERMAN ALGORITHM

http://www.inteldevconference.com/
http://www.intel.com/content/www/us/en/processors/xeon/xeon-phi-detail.html

Home

Intel blog: attackers moving down toward hardware

~ hucktech ~ Leave a comment

I always miss lots of firmware news. 😦 I just now noticed this blog post from 11/2015 from Intel Security executives:

Hardware.Next: Diving deeper into the stack—understanding the dangers of hardware and firmware vulnerabilities
https://blogs.mcafee.com/executive-perspectives/hardware-next-hardware-firmware-vulnerabilities-provide-tools-attackers-defenders/

It gives me a big ‘deja-vu’ to the 4/2014 blog post from elsewhere at Intel:

Attackers Expand to Hack Hardware
https://communities.intel.com/community/itpeernetwork/blog/2015/04/15/attackers-expand-to-hack-hardware

I guess if you’re a chip company, this will be your perspective, that attackers are coming from usermode down to attack their hardware.

Board Design Files for Minnowboard Turbot available

~ hucktech ~ Leave a comment

John Hawley of Intel announced on the Minnowboard mailing list the availability of board design files for the ADI MinnowBoard Turbot, released by Mentor Graphics.

3D STEP files now available – Courtesy of Mentor Graphics. Just wanted to let everyone know that Mentor Graphics has just released accurate STEP files for ADI MinnowBoard Turbot. I know there’s been folks interested in getting these for a variety of reasons, and while I’ve attempted to respond to the folks who have pinged me directly, I wanted to make sure that everyone is aware that those are now available. If you’ve got any problems with them, let me know, and serious thanks go out to Mentor Graphics for doing this!

More information:
http://wiki.minnowboard.org/MinnowBoard_Turbot#MinnowBoard_Turbot_Rev_X205_.28PCB_Rev_F200.29
http://lists.elinux.org/mailman/listinfo/elinux-minnowboard
http://minnowboard.57273.x6.nabble.com/MinnowBoard-3D-STEP-files-now-available-Courtesy-of-Mentor-Graphics-td2061.html
https://firmwaresecurity.com/tag/minnowboard/

Two quotes from the Minnowboard wiki:

“The design files are released under Creative Commons CC-BY-SA.”

“The MinnowBoard Turbot is intended to comply with all requirements and guidelines set forth by the Open Source Hardware Association (OSHWA).”

The word “intended” is probably significant; regardless I’m happy to see Minnowboard intending to be OSH. I hope they fulfill this intended goal! 🙂