Category: Uncategorized

Qualcomm seeks Firmware Security Researcher

~ hucktech ~ Leave a comment

I’m going to try and start to post the occasional relevant interesting job postings for security researchers or developers. I will try to use ‘job-posting” for the tag for all of them. If you think it’s a bad idea for this blog, or if you get the job based on this blog, leave a Comment. 😉

[…]Qualcomm Hardware Security team is looking for a Firmware Security Researcher to help drive security efforts in our System-On-Chip (SOC) solutions. In this role, the Firmware Security Researcher will work closely with the Hardware Design Team, Hardware Verification team, and the Software team to help find vulnerabilities in our products. This role entails using best practices to evaluate, asses, and report vulnerabilities in QUALCOMM products. A systematic approach to vulnerability discovery is essential. Knowledge gained will leverage into new security mitigations for our SOC solutions used in a wide range of products, including mobile devices, IOT, automotive, consumer networking gear, wearables, and embedded medical devices. As a firmware security researcher, it is essential that the candidate be able to develop proof-of-concepts to demonstrate the impact of the vulnerabilities that are discovered, to enable proper prioritization and communication of issues to internal teams and external customers. Communication skills are highly valued as the role will entail cross-department coordination with the various groups involved in Cybersecurity initiatives, and possibly presenting findings at security conferences.[…]

https://jobs.qualcomm.com/public/jobDetails.xhtml?requisitionId=1950936

Linux Foundation workstation security ebook

~ hucktech ~ Leave a comment

[…]Now, before you even start with your operating system installation, there are a few things you should consider to ensure your pre-boot environment is up to snuff. You will want to make sure:
* UEFI boot mode is used (not legacy BIOS) (ESSENTIAL)
* A password is required to enter UEFI configuration (ESSENTIAL)
* SecureBoot is enabled (ESSENTIAL)
* A UEFI-level password is required to boot the system (NICE-to-HAVE)

https://www.linux.com/news/linux-workstation-security/2017/3/4-security-steps-take-you-install-linux

http://go.linuxfoundation.org/workstation_security_ebook

Sounds interesting, but I don’t see any actual download link for this ebook. I guess I need some sleep.

There is also this: https://firmwaresecurity.com/2015/08/31/linux-foundation-it-security-policies-firmware-guidance/

 

Exploiting Samsung’s Secure Bootloader (S-Boot) for Android

~ hucktech ~ Leave a comment

Exploiting Android S-Boot: Getting Arbitrary Code Exec in the Samsung Bootloader (1/2)
Nitay Artenstein (@nitayart) and Gilad Goldman (@gnull00)

Samsung’s Secure Bootloader (S-Boot) for Android lies at the heart of Samsung’s chain of trust concept. An attacker who compromises S-Boot could potentially load an untrusted kernel and system image, therefore bypassing most of the phone’s security mechanisms. This is a well-known attack vector: It’s often used by the Android rooting and modding community, but our guess is that it’s way more popular with law enforcement and government agencies. All the more interesting, then, that S-Boot on contains several memory corruption bugs, one of which could be used to reach full code execution within the bootloader. We can currently confirm the existence of the vulnerability only on Exynos chipsets. It seems universal to approximately 90% of the Samsung Exynos ROMs running on S5, S6 and S7. The very newest ROMs for S7 (February 2017) appear to include a fix for this bug, but we’ll confirm this in a few days. There’s a lot of ground to cover, so we’ll break up this write-up into two posts. In this post we’ll focus on some S-Boot internals, then explore the bootloader’s attack surface and get basic debugging capabilities. We’ll end the post with the discovery of an especially interesting attack surface. In the next post we’ll disclose the actual vulnerability and how we exploited it to get code execution in S-Boot. We won’t go into much detail on the basics of reversing S-Boot, such as how to load it into IDA or find the base address. Fernand Lone Sang (@_kamino_) is about to publish a great article exactly about that and I’ll put a link for it here when it’s out. If you need any help beyond that, just DM me and I’d be glad to give you a hand if I can.[…]

Software Grand Exposure: SGX Cache Attacks Are Practical

~ hucktech ~ Leave a comment

Software Grand Exposure: SGX Cache Attacks Are Practical
Ferdinand Brasser, Urs Müller, Alexandra Dmitrienko, Kari Kostiainen, Srdjan Capkun, Ahmad-Reza Sadeghi
(Submitted on 24 Feb 2017)
Side-channel information leakage is a known limitation of SGX. Researchers have demonstrated that secret-dependent information can be extracted from enclave execution through page-fault access patterns. Consequently, various recent research efforts are actively seeking countermeasures to SGX side-channel attacks. It is widely assumed that SGX may be vulnerable to other side channels, such as cache access pattern monitoring, as well. However, prior to our work, the practicality and the extent of such information leakage was not studied. In this paper we demonstrate that cache-based attacks are indeed a serious threat to the confidentiality of SGX-protected programs. Our goal was to design an attack that is hard to mitigate using known defenses, and therefore we mount our attack without interrupting enclave execution. This approach has major technical challenges, since the existing cache monitoring techniques experience significant noise if the victim process is not interrupted. We designed and implemented novel attack techniques to reduce this noise by leveraging the capabilities of the privileged adversary. Our attacks are able to recover confidential information from SGX enclaves, which we illustrate in two example cases: extraction of an entire RSA-2048 key during RSA decryption, and detection of specific human genome sequences during genomic indexing. We show that our attacks are more effective than previous cache attacks and harder to mitigate than previous SGX side-channel attacks.

https://arxiv.org/abs/1702.07521

 

CHIPSEC gets UEFI variable fuzzer

~ hucktech ~ Leave a comment

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. Note: this module modifies contents of non-volatile SPI flash memory (UEFI Variable NVRAM). This may render system unbootable if firmware doesn’t properly handle variable update/delete operations.
 
Usage:
    “chipsec_main -m tools.uefi.uefivar_fuzz [-a <options>]“
    
Options:        
    “[-a <test>,<iterations>,<seed>,<test_case>]“
    – “test“        which UEFI variable interface to fuzz “(all, name, guid, attrib, data, size)“
    – “iterations“    number of tests to perform (default = 1000)
    – “seed“        RNG seed to use
    – “test_case“    test case # to skip to (combined with seed, can be used to skip to failing test)
    All module arguments are optional
    
Examples:
>>> chipsec_main.py -m tools.uefi.uefivar_fuzz
>>> chipsec_main.py -m tools.uefi.uefivar_fuzz -a all,100000
>>> chipsec_main.py -m tools.uefi.uefivar_fuzz -a data,1000,123456789
>>> chipsec_main.py -m tools.uefi.uefivar_fuzz -a name,1,123456789,94

https://github.com/chipsec/chipsec/blob/master/chipsec/modules/tools/uefi/uefivar_fuzz.py

 

Intel Fortville Ethernet Controller driver vulnerability

~ hucktech ~ Leave a comment

Intel® Ethernet Controller X710/XL710 Driver Security Vulnerability
Intel ID:      INTEL-SA-00069
Product family:      Intel® Ethernet Controller X710 family and Intel® Ethernet Controller XL710 family
Impact of vulnerability:      Denial of Service
Severity rating:      Critical
Original release:      Feb 27, 2017

A security vulnerability in the Intel® Ethernet Controller X710 and Intel® Ethernet Controller XL710 family of products (Fortville) has been found in the device driver.   A security vulnerability in the Intel® Ethernet Controller X710 and Intel® Ethernet Controller XL710 family of products (Fortville) has been found in the device driver.  In certain layer 2 network configurations the device driver may continuously reset.  All driver versions prior to 21.3 are impacted. Intel recommends updating to Intel® driver versions included in Release 22.0 or newer available[…]

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

 

Purism Librem 13 coreboot update

~ hucktech ~ Leave a comment

Here are the news you’ve been waiting for: the coreboot port for the Librem 13 v1 is 100% done! I fixed all of the remaining issues, it is now fully working and is stable, ready for others to enjoy. I fixed the instability problem with the M.2 SATA port, finished running all the tests to ensure coreboot is working correctly, fixed the headphone jack that was not working, made the boot prettier, and started investigating the Intel Management Engine issue. Read on for details.[…]

https://puri.sm/posts/librem-13-coreboot-report-february-25th-2017/

 

more on Apple/SuperMicro story

~ hucktech ~ Leave a comment

Re: https://firmwaresecurity.com/2017/02/24/apple-rejects-supermicro-due-to-bad-firmware/

An update from the Ars Technica story:

Update: A source familiar with the case at Apple told Ars that the compromised firmware affected servers in Apple’s design lab, and not active Siri servers. The firmware, according to the source, was downloaded directly from Supermicro’s support site—and that firmware is still hosted there.

Apple issued the following official comment: Apple is deeply committed to protecting the privacy and security of our customers and the data we store. We are constantly monitoring for any attacks on our systems, working closely with vendors and regularly checking equipment for malware. We’re not aware of any data being transmitted to an unauthorized party nor was any infected firmware found on the servers purchased from this vendor.

https://arstechnica.com/information-technology/2017/02/apple-axed-supermicro-servers-from-datacenters-because-of-bad-firmware-update/

https://www.theinformation.com/apple-severed-ties-with-server-supplier-after-security-concern?shared=516084

https://twitter.com/osxreverser/status/835673513528819713

UEFI VBS required by Microsoft

~ hucktech ~ Leave a comment

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

 

“VBS will enable No-Execute (NX) protection on UEFI runtime service code and data memory regions. UEFI runtime service code must support read-only page protections, and UEFI runtime service data must not be executable.”

I’m glad Alex is reading these Microsoft updates better than I am. 🙂 Glad to know that VBS is not VBScript.

Microsoft updates OEM Device/Credential Guard requirements

Microsoft updates Device Guard OEM guidance

Microsoft Updates OEM Device/Credential Guard requirements

IGD command added to CHIPSEC

~ hucktech ~ Leave a comment

The igd command allows memory read/write operations using igd dma.
>>> chipsec_util igd
>>> chipsec_util igd dmaread <address> [width] [file_name]
>>> chipsec_util igd dmawrite <address> <width> <value|file_name>
Examples:
>>> chipsec_util igd dmaread 0x20000000 4
>>> chipsec_util igd dmawrite 0x2217F1000 0x4 deadbeef

https://github.com/chipsec/chipsec/blob/master/chipsec/utilcmd/igd_cmd.py

coreboot to join Software Freedom Conservancy

~ hucktech ~ Leave a comment

Martin Roth made a post on the coreboot blog about the project joining the Software Freedom Conservancy. I hope this means the project will get more funding.

The coreboot project applied to join the Software Freedom Conservancy[0] and has been approved for membership by their board.  There is still some work to be done in hammering out the governance details, but we hope to have everything completed by April. Joining the SFC as coreboot’s fiscal sponsor \will allow us to go forward with fundraising, and that all donations to the coreboot project from the United States will be tax-deductible.  Up to this point, coreboot hasn’t had any official way to accept donations or payments.  This has meant that the project was mainly supported financially by members of the coreboot leadership, which has put some limitations on what we were able to do. Another of the things that joining the SFC means is that we will be formalizing and fully documenting the coreboot leadership structure.  This is one of the Conservancy’s requirements, and something that they will help the project with. The Conservancy offers a number of other services[1]to its members. We encourage everyone to take a look at the SFC, and to consider joining as individual supporters[2].

[0] https://sfconservancy.org/
[1] https://sfconservancy.org/projects/services/
[2] https://sfconservancy.org/supporter/

https://sfconservancy.org/donate/
https://sfconservancy.org/sponsors/

Full post:

coreboot is joining the Software Freedom Conservancy

Functional Encryption using Intel SGX

~ hucktech ~ Leave a comment

https://twitter.com/sergey_nog/status/834160638729605121

 

{\sc{Iron}}: Functional Encryption using Intel SGX
Ben A Fisch, Dhinakaran Vinayagamurthy, Dan Boneh, Sergey Gorbunov
Functional encryption (FE) is an extremely powerful cryptographic mechanism that lets an authorized entity compute on encrypted data, and learn the results in the clear. However, all current cryptographic instantiations for general FE are too impractical to be implemented. We build {\sc{Iron}}, a practical and usable FE system using Intel’s recent Software Guard Extensions (SGX). We show that {\sc{Iron}} can be applied to complex functionalities, and even for simple functions, outperforms the best known cryptographic schemes. We argue security by modeling FE in the context of hardware elements, and prove that {\sc{Iron}} satisfies the security model.

http://eprint.iacr.org/2016/1071

 

Microsoft updates Secure Boot and ACPI requirements

~ hucktech ~ Leave a comment

These Microsoft pages have recently (last month) been updated. No changelog, so unclear what has changed. 😦

 

https://msdn.microsoft.com/en-us/windows/hardware/drivers/bringup/secure-boot-and-device-encryption-overview

https://msdn.microsoft.com/en-us/windows/hardware/commercialize/design/device-experiences/acpi-firmware-implementation-requirements

https://msdn.microsoft.com/en-us/windows/hardware/drivers/bringup/firmware-requirements-for-d3cold

 

OSR on debugging bad Windows drivers

~ hucktech ~ Leave a comment

OSR has a nice blog post that shows how to debug bad drivers. OSR is a smart group of Windows-centric driver consultants, check out their NT Insider newsletter if you’re into NT. And their NTdev mailing list.

[…]The bugcheck makes much more sense now. Someone’s stack expansion callback was called at DISPATCH_LEVEL (Arg2 == 2) and returned at PASSIVE_LEVEL (Arg1 == 0). That’s against the rules, thus you get a system crash. Personally I would call this a bug in KeExpandKernelStackAndCalloutEx seeing as how it is generating an IRQL_UNEXPECTED_VALUE using invalid (unexpected?) arguments. At a minimum the documentation is currently wrong though and I have filed a bug to try to get that addressed.

Unexpected Case of Bugcheck IRQL_UNEXPECTED_VALUE (C8)

http://www.osronline.com/showthread.cfm?link=281770

https://www.osr.com/developers-blog/

http://www.osronline.com/showlists.cfm?list=ntdev

http://www.osronline.com/index.cfm

Hmm, it looks like OSRonline.com is becoming ‘legacy’. If there’s not a future home for some of the tools listed there, you might want to grab a set of tools while you still can. The tools are somewhat like SysInternals-style of tools.

 

Apple rejects Supermicro due to bad firmware

~ hucktech ~ Leave a comment

https://arstechnica.com/information-technology/2017/02/apple-axed-supermicro-servers-from-datacenters-because-of-bad-firmware-update/

http://appleinsider.com/articles/17/02/23/server-firmware-security-incident-in-2016-forced-apple-to-sever-ties-with-vendor-super-micro

https://www.macrumors.com/2017/02/23/apple-ends-relationship-with-super-micro/

Hurray for a vendor for checking the security of the hardware, and rejecting it for not being secure. If you are a big enough vendor, demand the output of CHIPSEC’s security tests and FWTS’s test results, before you buy it.  If CHIPSEC is failing, do not buy it. This is the only way some OEMs will learn to build secure systems. Unfortunately, no end user consumer has this ability. Large enterprises do, and I wish more would be doing it, and demanding the results be public. OEMs which build secure systems should be proactively showing their test results, so that savvy customers will realize this huge market advantage over competitors.

I wonder what kind of incident this was, firmware malware or something else???

Tianocore patch to increase memory protection

~ hucktech ~ Leave a comment

Ard Biesheuvel of Linaro submitted a V2 5-part patch to the EDK2 project, to harden UEFI more!

This is a proof of concept implementation that removes all executable permissions from writable memory regions, which greatly enhances security. It is based on Jiewen’s recent work, which is a step in the right direction, but still leaves most of memory exploitable due to the default R+W+X permissions. The idea is that the implementation of the CPU arch protocol goes over the memory map and removes exec permissions from all regions that are not already marked as ‘code. This requires some preparatory work to ensure that the DxeCore itself is covered by a BootServicesCode region, not a BootServicesData region. Exec permissions are re-granted selectively, when the PE/COFF loader allocates the space for it. Combined with Jiewen’s code/data split, this removes all RWX mapped regions.

Changes since v1:
– allocate code pages for PE/COFF images in PeiCore, so that DxeCore pages have the expected memory type (as suggested by Jiewen)
– add patch to inhibit page table updates while syncing the GCD memory space map with the page tables
– add PCD to set memory protection policy, which allows the policy for reserved and ACPI/NVS memory to be configured separately
– move attribute manipulation into DxeCore page allocation code: this way, we should be able to solve the EBC case by allocating BootServicesCode pool memory explicitly.

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

Slides for coreboot/UEFI talk from REcon available

~ hucktech ~ Leave a comment

 

Click to access REConBrussels2017_BARing_the_system.pdf

http://www.intelsecurity.com/advanced-threat-research/index.html