HP seeks firmware pentester

Application Security Engineer – Firmware
HP Cloud Solutions and Operations (CSO) Security is an engineering organization specializing in secure development practices and penetration testing. We are organized as an internal consulting business, enabling our customers to develop and launch a diverse range of customer-facing products including mobile, eCommerce, web services, and embedded. It’s our job to analyze the design, audit the source code, and attempt to break the final product before potential adversaries do. We’re hiring an application security engineer with firmware experience and penetration tester at our new Vancouver, WA office. We have openings for a full-time engineer. Ideally, you have a passion for learning new attack vectors and implementing working exploits. Given your past experience you can improve the security of the architecture, design, authorship, and testing of code. If many of the following apply, you’re probably a good fit.[…]


DFIR toolset links

Mark McCurdy of HP has a nice set of links for DF

It is sort of like an ‘awesome forensics’ page, so related to lists like:

new HP printers to include additional firmware security

Multiple news sites have stories about new HP printer which has new firmware security features. Quoting a story by Samira Sarraf and Steven Kiernan in CRM Australia:

[…] The recently announced printers, which are expected to start shipping in April 2017, also boast beefed-up security, including run-time intrusion detection, which monitors constantly for sign of attack and sends alerts into security management. There is also a firmware whitelisting device that makes sure that only good and certified firmware have access to the devices. And Sure Start, a chip on the devices that checks for the bios integrity during boot time, shuts the device down if it detects anything wrong and reboots. […]


List of UEFI vendors who care about security

Which UEFI vendors care — or at least may care — about security? The list (alphabetically) is shorter than you might expect:

Hewlett Packard Enterprises
HP Inc.
Insyde Software
Intel Corp.
Phoenix Technologies

Nobody else. If your vendor is not listed above, ask them why you should purchase a UEFI-based system from them.

The above list is from the list of vendors who have feedback mechanisms listed on the UEFI Forum’s security contact page.


HP Printers expose anon FTP

Exposed HP LaserJet printers offer Anonymous FTP to the public

Networked HP LaserJet printers, which have been made available to the public by the organizations hosting them, offer potential attackers a ready-made Anonymous FTP server. At present, there are thousands of these devices online. The exposed printers were the focus of a new blog post by Chris Vickery. Vickery has previously worked with Salted Hash on a number of stories – including database leaks that exposed class records at SNHU, 3.3 million Hello Kitty fans, 191 million voter records, and an additional 18 million voter records with targeted data. […]

Full article:

RISC-V/LowRISC update

The recent RISC-V workshop is over, presentations are online, videos are not yet online:


RISC-V and coreboot:




There is some post-workshop coverage here:

LowRISC, a related project to RISC-V is also making progress. From the below EE Times article:

“The LowRISC project at the University of Cambridge is attracting interest as the likely first source of real development hardware. The team which includes members of the Raspberry Pi project hopes to have first silicon this year and plans to make development boards available in 2017, likely for $50-100.”



I missed this news, it is interesting to see Google, HP, and Oracle getting involved with RISC-V.



new Linux kernel NVDIMM IOCTL pass thru patch

Jerry Hoemann of HP (now HPE) posted a message to the linux-nvdimm@lists.01.org, linux-acpi, and linux-kernel lists with new patch to the Linux 4.3 kernel with a new ioctl inteface for NVDIMM DSMs:

nvdimm: Add an IOCTL pass thru for DSM calls

The NVDIMM code in the kernel supports an IOCTL interface to user space based upon the Intel Example DSM:

This interface cannot be used by other NVDIMM DSMs that support incompatible functions. This patch set adds a generic “passthru” IOCTL interface which is not tied to a particular DSM. A new IOCTL type “P” is added for the pass thru call. The new data structure ndn_pkg serves as a wrapper for the passthru calls.  This wrapper supplies the data that the kernel needs to make the _DSM call. Unlike the definitions of the _DSM functions themselves, the ndn_pkg provides the calling information (input/output sizes) in an uniform manner making the kernel marshaling of the arguments straight forward. This shifts the marshaling burden from the kernel to the user space application while still permitting the kernel to internally calling _DSM functions. To make the resultant kernel code easier to understand the existing functions acpi_nfit_ctl and __nd_ioctl were renamed to .*_intel to denote calling mechanism as in 4.2 tailored to the Intel Example DSM. New functions acpi_nfit_ctl_passthru and __nd_ioctl_passthru were created to supply the pass thru interface.

 drivers/acpi/nfit.c        |  91 ++++++++++++++++++++++++++++++++–
 drivers/nvdimm/bus.c       | 118 +++++++++++++++++++++++++++++++++++++++++—-
 drivers/nvdimm/dimm_devs.c |   6 +–
 include/linux/libnvdimm.h  |   3 +-
 include/uapi/linux/ndctl.h |  20 +++++++-
 5 files changed, 220 insertions(+), 18 deletions(-)

For more information, see the posting on the linux-nvdimm@lists.01.org mailing list archives.


new Windows PDB tool: pdb_type_theft.py

As pointed out by ZDI, Dustin Childs of HP Security Research (HPSR) wrote an article on Windows binaries and symbols, and how some symbolic information is missing from current binaries, and how he wrote a new tool — pdb_type_theft.py — to extract the missing information from old binaries.

In August of this year, Microsoft published an update to NTDLL and along with it, released updated symbols for debugging. These symbols are available as PDBs (program databases). Unfortunately, the symbols that were released contain type information that is missing standard structures and enumerations. As a result, debugging applications on Windows became a far more involved task. Microsoft is aware of the issue but has yet to release updated PDBs that rectify this issue. While they are working on it, I found myself wondering if I could avoid their involvement altogether. Barring any changes to the structures and enumerations, the information from previous versions of the PDBs should still be valid. As such, if I could copy the type information from a previous PDB and inject it into the current PDB, I’d theoretically be able to have everything I expect from a working build process. […] This script requires having a PDB with the type information you want available to copy into another PDB.  If you are not in the habit of snapshotting your VMs after every update, the following links may be helpful […]

Full article and source:

(If you’ve read a few blog entries, you know that I misspell things a lot. Sorry. The other day, Microsoft finally made the PDB spec public, and I blogged on it, calling it “PDF”. Sigh.)

UEFI 2.5 Platform Recovery feature appearing in Tianocore

Ruiyu Ni of Intel has posted an 12-part patch addding UEFI 2.5’s Platform Recovery feature to the public Tianocore EDK2 trunk.

Amongst the features of UEFI 2.5, the last public release of UEFI from the UEFI Forum, was #1227 “UEFI.Next feature – Platform recovery“. Load up the multi-thousand page UEFI 2.5 specification, with a PDF viewer with good search abilities, to find all the locations in the spec which Platform Recovery impacts. A good place to start would be around page 119, the OsRecovery#### and PlatformRecovery#### variables that’re new to UEFI 2.5.

Given that the patch includes a question from Intel asked HP:  “Could you please check my patch to see whether it can meet your real requirement?“, it appears that HP already has an existing implementation of this, perhaps already publicly available, probably separate from the Tianocore implementation, like they did with HTTP Boot. I’m not sure of other vendors with existing UEFI 2.5 Platform Recovery support.

Given UEFI capsule updates can add new features, your next firmware update may include this feature; is your organization ready to deal with UEFI 2.5 Platform Recovery support appearing in the near future? I’m not ready. I don’t understand what this feature really means, in terms of system impact. Earlier (not in this patch), there was a LOT of new code dealing with recovery in drivers. I don’t now know how to test this feature yet in Tianocore. Are there any new tools involved with this feature, for sysadmins to use? How do I test if this feature is working in a specific driver, or in the entire system? Where are some test scripts that exercise the feature? If someone has any more pointers to using this new feature, please add a Comment to this post (see left), thanks!

Subject: [Patch 00/11] Add Platform Recovery support

OS Recovery will be added later.

Ruiyu Ni (11):
  MdePkg: Add Platform Recovery definitions.
  MdeModulePkg: Add Bm prefix for internal functions
  MdeModulePkg: Use BmCharToUint in BmIsKeyOptionVariable
  MdeModulePkg: Use BM_OPTION_NAME_LEN instead of sizeof L”Boot####”
  MdeModulePkg: Use BmForEachVariable to collect all key options
  MdeModulePkg: Support to expand File device path
  MdeModulePkg: Add Platform recovery support
  MdeModulePkg: Add missing PrintLib to BdsDxe.inf
  MdeModulePkg: Use UefiSpec.h defined macro to replace L”xxx” string
  MdeModulePkg: Add PlatformRecovery#### pointing to default file path
  MdeModulePkg: Enable PlatformRecovery in BdsDxe driver

 MdeModulePkg/Include/Library/UefiBootManagerLib.h  |   1 +
 MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c   |  76 ++++
 MdeModulePkg/Library/UefiBootManagerLib/BmHotkey.c | 181 +++++—-
 …/Library/UefiBootManagerLib/BmLoadOption.c      | 155 +++++–
 MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c   |  26 ++
 …/Library/UefiBootManagerLib/InternalBm.h        |  30 +-
 …/UefiBootManagerLib/UefiBootManagerLib.inf      |   1 +
 MdeModulePkg/Universal/BdsDxe/Bds.h                |   3 –
 MdeModulePkg/Universal/BdsDxe/BdsDxe.inf           |   1 +
 MdeModulePkg/Universal/BdsDxe/BdsEntry.c           | 447 ++++++—————
 MdePkg/Include/Uefi/UefiSpec.h                     |   1 +
 11 files changed, 474 insertions(+), 448 deletions(-)

More Information:

LinuxCon Europe UEFI Mini-Summit presentations available

Earlier this month, the UEFI Forum recently had a “Mini-Summit” at LinuxCon Europe. The presentations are now available online (so far just the slides, unclear if A/V will show up on Youtube later):

UEFI Mini-Summit at LinuxCon Europe: October 7, 2015

* UEFI Forum Update and Open Source Community Benefits – Mark Doran (Intel)
* What Linux Developers Need to Know About Recent UEFI Spec Advances – Jeff Bobzin (Insyde Software)
* LUV Shack: An Automated Linux Kernel and UEFI Firmware Testing Infrastructure – Matt Fleming (Intel)
* Goodbye PXE, Hello HTTP Boot – Dong Wei (HP)
* UEFI Development in an Open Source Ecosystem – Michael Krau (Intel)

More information (about halfway down the page, past the Youtube section):



iPXE adds UEFI HTTP Boot support

Samer El-Haj-Mahmoud of HP posted a message to the EFI development list, with an update on iPXE, supporting UEFI HTTP Boot:

It looks like iPXE has been updated to work with UEFI 2.5 HTTP Boot, and tested with OVMF. Their page also includes instructions for configuring the DHCP server to enable HTTP Boot, and building OVMF with HTTP_BOOT enabled. It would be interesting to see if iPXE EFI version will directly use EFI_HTTP_PROTOCOL or carry its own TCP/IP HTTP code.

Excerpt from iPXE site:

Version 2.5 of the UEFI specification introduces the UEFI HTTP Boot feature. You can use the basic UEFI HTTP Boot client to chainload iPXE from an HTTP server, eliminating the need for a separate TFTP server in your boot infrastructure. The simple UEFI HTTP Boot client will download and boot iPXE. You can then use any of iPXE’s more advanced features such as HTTPS, Digest authentication, POST requests, scripts, menus, customisable code signing etc. to download and boot your operating system. UEFI HTTP chainloading provides a way to load iPXE on systems which do not have iPXE present as part of the UEFI firmware. If your system already provides iPXE as part of the UEFI firmware, then you do not need to use UEFI HTTP chainloading.

More information:

TrustZone in AMD Pro APUs

Bruno Ferreira has a story in TechReport on TrustZone support in new AMD Pro APUs:

AMD goes Pro with TrustZone-enabled APUs

AMD has released a Pro family of APUs and management tools targeted at business environments. These APUs hail from the Godavari and Carrizo families, and come in both mobile and desktop flavors. According to AMD, its new Pro A12 mobile APU is “the first [HSA-compliant] commercial processor in the industry.” It’s also the first APU with support for ARM’s TrustZone, for system-wide separation of software execution environments. The mobile Pro A12 packs in four CPU cores with a 3.4 GHz Turbo clock, alongside an R7-series GPU with 512 compute units clocked at 800 MHz. The inclusion of an HEVC decoder is also a nice bonus. A similar part exists in the Pro-series desktop APU lineup, with four cores and Turbo speeds of 4.1 GHz. Along with the hardware, AMD has released its companion Pro Control Center software, which offers centralized system management features like system health monitoring, traffic shaping, and USB port blocking. If this whole thing sounds similar to Intel’s vPro, you’re probably right. Still, AMD’s take has a few unique features. AMD already has a few partners on board. HP is using Pro APUs in  its “AMD Elite” family of products, and Lenovo is building around these chips with its M79 Tower. More AMD Pro products should be coming soon.

Full story:


Firmware security is main feature of new HP printers

Excerpting their press release:

HP Announces World’s Most Secure Printers: New HP LaserJets include built-in self-healing security features with protection down to the BIOS

HP today announced three new enterprise class LaserJet printers that deliver increased protection against malicious attacks. The stronger security is part of a broader HP strategy to provide the deepest security across PCs and printers. Printer security is a topic of growing importance. According to the Ponemon Institute, 64 percent of IT managers believe their printers are likely infected with malware. At the same time, 56 percent of enterprise companies ignore printers in their endpoint security strategy.(1) To help address this gap, HP is delivering its new HP LaserJet Enterprise printers and multi-function printers (MFPs) with industry-leading security features(2) built in, including:

* HP Sure Start enables detection of and self-healing recovery from malicious BIOS attacks, extending the same BIOS security protecting HP’s Elite line of PCs since 2013 to the new HP LaserJet Enterprise printers.
* Whitelisting ensures only known, good firmware can be loaded and executed on a printer.
* Run-time Intrusion Detection is a new feature providing in-device memory monitoring for malicious attacks. It was developed in partnership with Red Balloon Security, an embedded device security company started by researchers from Columbia University. The company has done extensive research for several government agencies, as well as private sector companies in industries such as telecommunications and controller systems.

These new features will be standard on new HP LaserJet Enterprise printers and OfficeJet Enterprise X printers with HP PageWide Technology going forward. With a firmware update, these three features can also be enabled on several HP LaserJet Enterprise printers available since April. In addition, Whitelisting and Run-time Intrusion Detection can be added to many existing HP LaserJet Enterprise printers and OfficeJet Enterprise X printers launched since 2011 through an HP FutureSmart service pack update. FutureSmart is HP firmware that helps protect customers’ investments in HP Enterprise printers by enabling delivery of new capabilities via updates.

It would be nice to see firmware security as a major feature of all new devices! 🙂

Full announcement:

HP printer firmware information page:

CVE-2015-5367: HP Gobi 4G firmware vulnerability

I missed this CVE the first time around, only noticed it with recent mainstream news reports. 😦

Quoting the Debian page:

The HP lt4112 LTE/HSPA+ Gobi 4G module with firmware before 12.500.00.15.1803 on EliteBook, ElitePad, Elite, ProBook, Spectre, ZBook, and mt41 Thin Client devices allows local users to gain privileges via unspecified vectors.

Huawei is also listed with this CVE, so perhaps other vendors besides HP are impacted?

More Information:



HP Security: HDD firmware hacking

Oleg Petrovsky of HP posted a good article on hard disk firmware hacking on the HP Security Research Blog. Long post, lots of pictures, very informative!

“In light of the recent publicity around malware that can remain persistent in hard drive firmware, it seems reasonable to seek a better understanding of what actually happens inside the hard drive – specifically, an understanding of the firmware. […]”


HP/Intel presentation on HTTP Boot and Redfish

Samer El-Haj-Mahmoud, a System Firmware Architect at Hewlett-Packard, was kind enough to give me an URL to a recent presentation at Intel Developer Forum (IDF), on UEFI HTTP Boot and DMTF Redfish:

STTS001: Firmware in the Data Center:
Building a Modern Development Framework Using UEFI and Redfish REST APIs.
Mark Doron, Intel
Dong Wei, HP
Samer El-Jah-Mahmoud, HP

The HP/Intel co-presentation is on HTTP Boot and Redfish, and the UEFI based deployment solution on HP ProLiant Servers. Topics include PXE -vs- UEFI HTTP Boot, IPMI -vs- Redfish, and clarification of HP’s implementation -vs- recent UEFI 2.5/TianoCore implementation. I wish I could find audio or video archives of this talk, not just slides. 😦

I’m not a fan of URL-shorteners, and this is a LONG URL, I think you need all the stuff after the .pdf extension:


Also, check out the UEFI videos and other resources at HP’s site:

LTE modem exploitation gives attackers online access

Yesterday at DEF CON 23 this talk happened:

Scared Poopless – LTE and *your* laptop
Mickey Shkatov, Jesse Michael
“With today’s advancement in connectivity and internet access using 3G and LTE modems it seems we all can have a device that’s always internet capable, including our laptops, tablets, 2 in 1’s ultrabook. It becomes easier to be online without using your WiFi at all.  In our talk we will demonstrate and discuss the exploitation of an internal LTE modem from Huawei which can be found in a number of devices including laptops by HP.”

The slides are now available:



DMTF Redfish 1.0 released

Redfish, an IPMI replacement, has shipped the first release of their spec. Quoting the press release:

DMTF Helps Enable Multi-Vendor Data Center Management with New Redfish 1.0 Standard

DMTF has announced the release of  Redfish 1.0, a standard for data center and systems management that delivers improved performance, functionality, scalability and security. Designed to meet the expectations of end users for simple and interoperable management of modern scalable platform hardware, Redfish takes advantage of widely-used technologies to speed implementation and help system administrators be more effective. Redfish is developed by the DMTF’s Scalable Platforms Management Forum (SPMF), which is led by Broadcom, Dell, Emerson, HP, Intel, Lenovo, Microsoft, Supermicro and VMware with additional support from AMI, Oracle, Fujitsu, Huawei, Mellanox and Seagate. The release of the Redfish 1.0 standard by the DMTF demonstrates the broad industry support of the full organization.


Don’t forget to grab the Redfish “Mockup” as well as the specs and schema.

UEFI 2.5 has a JSON API to enable accessing Redfish. HP was first vendor with systems that supported UEFI 2.5’s new HTTP Boot, a PXE replacement.  Intel checked in HTTP Boot support into TianoCore, so it’s just a matter of time until other vendors have similar products. JSON-based Redfish and HTTP-based booting makes UEFI much more of a “web app”, w/r/t security research, and the need for system administrators to more closely examine how firmware is updated on their systems, to best protect them.

HP QuickLook: EFI PIM for MS Outlook

In business-class HP systems, they include various pre-OS tools. In addition to “HP System Diagnostics”, some older HP laptops (and perhaps desktops, but hopefully not servers) include “HP QuickLook”, a UEFI Pre-OS application which is a PIM (Personal Information Manager) for Microsoft Outlook (email, calendar, tasks, contacts).

From an HP PDF entitled “HP Business Notebook Computer EFI Guidelines”, also in below URLs:

The HP EFI partition includes the following applications, which are accessible during computer startup:
* HP QuickLook or later versions (select models)
* <…omitted…>

QuickLook is a personal information manager (PIM) viewer for Microsoft(R) Outlook 2003 and 2007. QuickLook captures Microsoft Outlook email, calendar, task, and contact information, and then displays it without starting the operating system and without launching Microsoft Outlook. QuickLook can access cached Outlook information at the press of a single button, whether the computer is off or in Hibernation.

That’s rather scary. UEFI Pre-OS office applications. I’m not sure if it is a UEFI Application which gets run when you press the button, or if it is a UEFI RunTime Service, that is always running and only provides UI when button is pressed.

Plus, the EFI System Partition (ESP) is a FAT32-based partition, no file system-level security. Granted, a Unix-based system could mount the volume in such a way to help protect the contents, but on a Windows-based platform the user will have full read-write access to the HP .EFI executables.

It looks like there is a 2010-era HP QuickLook 3.2, perhaps later versions. I am not sure if this software is on modern HP UEFI systems, I don’t see it anymore on some docs, it may no longer be used, I’m not sure.

So, some business-class HP systems can be attacked via email network protocols, with added system complexity of being surrounded by a firmware suspend-resume! Network and content-media attacks are both options for this application. System administrators should check if this is installed on any modern systems, and consider the security risks -vs- the convenience this offers. Hiding inside corrupted HP PIM pre-OS app/service would be a great place for malware to hang out, or gain foothold via “a single button, whether the computer is off or in Hibernation”.



More Info on UEFI 2.5 HTTP Boot Implementations

Earlier, I made this blog post on UEFI 2.5’s new HTTP Boot feature. At that time, I was unaware of some details, like if this feature will be implemented in TianoCore, or only in commercial products. HP gave a talk at the Spring UEFI Forum on UEFI 2.5 HTTP Boot (to replace PXE) and DMTF Redfish (to replace IPMI), so I presume some new HP products will have these new features soon, if not already. On the EFI development list, I asked a question about Tianocore and vendor support of UEFI HTTP boot, as well as DMTF Redfish, and got 2 replies, one from Intel and one from HP.

Ye Ting of Intel replied and said:

“Intel is working on implementation of UEFI 2.5 HTTP boot support.”

Samer El-Haj-Mahmoud of HP also replied, and said:

“Both HTTP Boot and Redfish are very new standards. HTTP Boot got standardized as part of UEFI 2.5 in March. Redfish is still not even 1.0 (last published spec is 0.96.0a, with a target 1.0 spec sometime this month according to DMTF). It is expected that implementation will take some time to catch up to the spec. At the same time, PXE and IPMI have been there for quite some time, are implemented across the board on servers (and many clients), and are already in wide use. I do not expect them to go away anytime soon. But the goal is to switch over to HTTP and Redfish/REST over time, especially as they enable new use cases and capabilities that were not possible (or easy to do) before. The first step though is to get the specs implemented. As Ting explained, Intel is working on UEFI 2.5 HTTP Boot implementation (that I expect will show up in EDK2. I see the header files submitted already). DMTF is also working on a Redfish mockup/simulator that can be used to exercise clients. HP ProLiant Gen9 servers already support proprietary flavors of both HTTP Boot (or “Boot from URL”) and Redfish (or the “HP RESTful API”). I do not know of any other servers that implement such technologies at this time.”

So, it sounds like HP is the only vendor that supports UEFI HTTP Boot at the moment, and Intel is working on an implementation. If Intel’s implementation is part of TianoCore, other vendors may use it.

I’m looking forward to a TianoCore implementation, as well as DMTF’s Redfish simulator.

Thanks to Ye Ting and Samer El-Haj-Mahmoud for the answers!