The National Institute of Standards and Technology (NIST) has released the Considerations for Managing Internet of Things (IoT) Cybersecurity and Privacy Risks report. The publication—the first in a planned series on IoT—aims to help federal agencies and other organizations manage the cybersecurity and privacy risks associated with individual IoT devices.[…]
[…]Through ongoing collaboration with industry researchers AMD became aware that, if using the user-selectable AMD secure encryption feature on a virtual machine running the Linux operating system, an encryption key could be compromised by manipulating the encryption technology’s behavior.[…]
This vulnerability was discovered and reported to AMD by Cfir Cohen of the
Google Cloud security team.
For a long time Intel has offered a “freeware” (not open source) solution to debug UEFI with a 2-system solution, one running either Linux/GDB or Windows/Windbg:
Last updated in 2017, it used to work on the old TunnelMountain desktop systems, I’ve been meaning to see if it works on MinnowBoard2 systems. And this is Intel-centric (and I presume it may also work on AMD), but, I’m not aware of ARM — nor UEFI Forum’s Tianocore — having a similar offering, which I’d like to be able to use on a UEFI-based Rasberry Pi. HOWEVER… I just noticed this, which came out LAST YEAR, somehow I missed it, an open source solution!!
This is a open code replacement for Intel’s binary only GDB server that comes as part of the ‘Intel UEFI Development Kit Debugger Tool’. Since that tool is Intel x86/64 Linux/Windows only this allows more flexibility. E.g. you can run this on any ARM based SoC with python3 and a USB OTG port connected directly to your target via a USB2.0 EHCI Debug port using the Linux USB OTG Debug Port gadget. You can then connect to that target remotely from your build box, etc. This also allows you to tweak the debugger itself. I’ve already added some additional functionality here to assist when using SourceLevelDebugPkg on non-EDK2 (i.e. no source available) firmwares such as AMI Aptio IV.
Now it just needs also add LLDB support (especially for the Clang-centric HBFA branch)… 🙂 Given this is open source, unlike the Intel solution, this is a possiblity!
The FreeBSD project needs some testing help:
“A quick macOS-EFI-Mounter for those who are too lazy to work with Terminal-Commands.”
I not positive, but I think that one of the NSA’s guidance documents has been recently updated:
BOOT SECURITY MODES AND RECOMMENDATIONS
Modern computing platforms provide a variety of boot options. The security implications, advantages, and disadvantages are rarely identified in documentation. Some configuration options, such as Secure Boot and Trusted Platform Module (TPM) 1 may appear redundant despite serving complementary roles. Six different configurations are compared below. Recommendations for different use cases are presented at the end of this document.
I was just watching this presentation on GRUB from FOSDEM 2019:
and it mentions that Fedora has a large number of downstream patches. Before this, I didn’t realize how MANY PATCHES that GRUB2 has, in various distros. For example
So I need to stop thinking all GRUBS are alike.
I also note this recent Debian bug report, which suggests some GRUB network security issues (which do not appear to be Debian-centric):
I hope GRUB’s network issues can be improved, maybe the additional focus of firmware security researchers?
[…]This could allow an attacker who gains access to several signatures to reconstruct the private key.[…]
No docs. The sources are in MASM-based Intel assembler, C, C++. The build environment requires Visual Studio and Windows.
[…]The content of SP 800-193 should be considered required reading for professional BIOS/firmware engineers.[…]
William, a firmware engineer at Dell, has a new blog post summarizing NIST 193, NIST’s latest firmware security standard. It is nice to see someone else talking about it, other than myself. 😉 🙂
It appears the coreboot project has 2 Google Summer of Code projects going, one is this project, addressing security issues found by Coverity!
[…]My project is on making coreboot Coverity clean. Coverity is a free static-analysis tool for open source projects that searches for common coding mistakes and errors, such as buffer overruns, null pointer dereferences, and integer overflow. Coverity automatically analyzes the coreboot codebase and flags issues it finds, and my job is to classify them into bugs and false-positives and patch them if I can. You can check the Coverity overview for coreboot here, though seeing the issue tracker itself requires registration. At the beginning of the summer, coreboot had over 380 flagged issues, but it’s now down to 303, so we’re making progress! I plan to address 20-30 issues per week depending on the source component, which so far has gone surprisingly well (surprising, in the sense that coming into the summer I knew very little about coreboot or firmware development in general).[…]
Make Magazine shuts down.
(AFAICT, no mention of this news on the official web site, but the Subscribe page is still taking orders.)
The Wayback Machine has started to create an archive.
The US DoD has a new grant offered for a side-channel attack tool:
The Defense Advanced Research Projects Agency (DARPA) Small Business Programs Office (SBPO) is issuing an SBIR/STTR Opportunity (SBO) inviting submissions of innovative research concepts in the technical domain of side channel security. In particular, DARPA is interested in the feasibility of effective pre-silicon side channel and fault injection estimation. These vulnerabilities are of interest to this program only in the context of emissions from the parts of the design that perform on-chip cryptographic functions. This would permit these vulnerabilities to be identified and reduced to acceptable constraints at design time rather than with a costly chip re-spin after fabrication and test.
[…]The DARPA Common Evaluation Platform (CEP) is a publicly available RISC-V based System-on-a-Chip (SoC). It will be used as a reference design and may have to be extended for the purposes of this program. The reference point for the current state of the art of side channel attack simulation technology will be based on transistor level simulation with SPICE. All the baseline metrics will be based on leakage sources found with SPICE simulation of a meaningful number of traces on the cryptographic block(s) within the CEP.[…]