Intel Fortville Ethernet Controller driver vulnerability

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

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

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

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

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

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

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

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

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

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

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

 

Click to access REConBrussels2017_BARing_the_system.pdf

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

Linux Kernel Podcast returns

After being offine since 2009, the Linux Kernel podcast has restarted. The first new episode mentions an EFI/ACPI patch!

Bhupesh Sharma posted a patch moving in-kernel handling of ACPI BGRT (Boot(time) Graphics Resource) tables out of the x86 architecture tree and into drivers/firmware/efi (so that it can be shared with the 64-bit ARM Architecture).

http://www.kernelpodcast.org/2017/02/20/kernel-podcast-for-feb-20th-2017/

Linux Kernel Podcast

http://jcm.libsyn.com/rss

sample of queries to this blog

I host this blog on WordPress.com, so they manage the PHP-based code. 🙂 I am not good at PHP nor WordPress, as you can tell. The web UI to the blog shows me a subset of the queries that people use to query the blog. It might help give you a better idea of the readerbase of this blog to get an idea of the queries people are making. Here’s the top queries from the last month. The interesting ones are queries that have nothing to do with my posts. 🙂 BTW, it appears the Search widget of WordPress is lame, sorry about that.

intel innovation engine
intelmetool
hvci
cantoolz
download firmware copperheados
intel ptt txt
intel me security
svn udk2015
ivrs amd
open trust protocol
intel me
arm trusted firmware
intel boot guard
ru efi
efiswissknife
trusted boot boot guard intel
efipwn
exdi windbg intel
pointer authentication
uefi memory map
firmadyne
malduino
ozmtool
fwupd lenovo
radare2 dlink
uefi 5
sp 800 147
intel ptt
edk ii uefi
security dxe driver software
pci expansion rom
ios 10 security guide
acpi 6.1 spec
what is firmware security
windows smm security mitigation
coreboot bmc
smm mitigation
intel bootguard
arm v8 pointer authentication
hackbgrt
uefi datahub protocol
microsoft + semm
efi game
verified boot uboot
u-boot secure boot
hsti
intel jtag
vsphere 6.5 secure boot
luander ribeiro
lava firmware
libvirt qemu kvm smm
rootkits and bootkits
invisible labs libreboot
bootkit efi
rowhammer puf
igd opregion
nx support wsmt acpi table
snapdragon 410 firmware
edk erst table error
isca iot
uefi specification version 2.6
megarac sp-x developer guide
fsp2.0 specification
firmware security
microsoft surface enterprise management
dell 7370 boot guard verified dxe
bios ru efi
deck linux
microsoft surface semm
motorola qualcomm firmware certificate
16.09.00
linux
schumilo vusbf
chipsec fuzzer
intel sgx visual studio example
hardenedbsd uefi
lenovo hsti
“platform trust technology” linux
underwriter labs iot security
mallik bulusu
uboot fit
ja.axxs.net
booting verification
veyron_speedy
canada s6 edge software update g925a
uefi version 2.5
http boot uefi
soc/rockchip/rk3288/bootblock.c
gefinvmexpresspassthru
chipsec
intel redfish
qualcomm snapdragon firmware
firmware rootkit broadcom
stateless laptop
hsti microsoft
yardstick security
dsdt editor
opc events security
meow by satoshi tanda
co to jest klucz intela ptt
qualcomm snapdragon update software
how to use binskim binary
usb cable tester d.i.y
uefi debugger amd
“intelssg”
introspection openstack
intel ipt chip
zte w300 firmware reverse
“uefi” network stack what is
qubes install windows
nikolaj schlej
firmware gd25lq128 download
fossdem
uefi gdb
firmware tcg 200t
ikgt intel
loading an elf in uefi
defcon 24 village talk jtag serial sip
radare2 manual efi
tpm grub
hsm luna g5 forum
intel firmware key rsa
protected audio video path (pavp)
srini devadas security
sgx s/mime
intel tpm 2.0 software stack
the intel tpm2 software stack
nvme malware
uefi 2.6 specifications
archive rweverything.com
cybersecurity practice guide sp 1800-7, situational awareness for electric utilities public comments

US Customs looks at QubesOS inventors computer

😦

 

https://twitter.com/rootkovska/status/834043480167030784

Kaspersky Antivirus for UEFI

 

[…]Kaspersky Antivirus for UEFI is integrated into Kraftway’s proprietary chip-based Kraftway Security Shell to ensure timely detection and blocking of malware attacks against key points (Master Boot Record, Global Partition Table, OS loader and kernel, key OS files, registry, critical files and directories, etc.) before the OS itself even starts to load.[…]

 

https://usa.kaspersky.com/oem/partners/kraftway

http://www.kraftway.ru/en/

http://www.kraftway.ru/products/detail.php?ID=1438&sphrase_id=21351