Based on the Go 1.22 release notes from the Go team (3-Clause BSD License), with many interactive examples added. This blog post is synchronized with the source document as it gets updated.

High pressure, high forces, long lever arms...all of that meant heavy and strong (read: expensive) parts which I was not looking forward to having to fabricate. Instead, I settled on the simpler idea of harnessing the power of compressed gas. Instead of using a high mechanical advantage lever to push a piston, compressed CO2 would be dispensed from a small and inexpensive 12g or 16g cartridge which would then generate the requisite pressure to properly extract espresso. This concept is not actually novel; both an unsuccessful kickstarter and a now-defunct handheld espresso maker (with a fanatical user base) employed this mechanism.

In this write-up, we’ll delve into how, through differential fuzzing, we uncovered a bug in Go’s exp/net HTML’s tokenizer. We’ll show potential XSS implications of this flaw. Additionally, we’ll outline how Google assessed this finding within their VRP program and guide how to engage and employ fuzzing to evaluate your software.

Go 1.21 adds a new port targeting the WASI preview 1 syscall API through the new GOOS value wasip1. This port builds on the existing WebAssembly port introduced in Go 1.11.

WebAssembly (Wasm) is a binary instruction format originally designed for the web. It represents a standard that allows developers to run high-performance, low-level code directly in web browsers at near-native speeds.

Go first added support for compiling to Wasm in the 1.11 release, through the js/wasm port. This allowed Go code compiled using the Go compiler to be executed in web browsers, but it required a JavaScript execution environment.

As the use of Wasm has grown, so have use cases outside of the browser. Many cloud providers are now offering services that allow the user to execute Wasm executables directly, leveraging the new WebAssembly System Interface (WASI) syscall API.

Cgo calls take about 40ns, about the same time encoding/json takes to parse a single digit integer. On my 20 core machine Cgo call performance scales with core count up to about 16 cores, after which some known contention issues slow things down.

It was obvious already before that NVD really does not try very hard to actually understand or figure out the problem they grade. In this case it is quite impossible for me to understand how they could come up with this severity level. It’s like they saw “integer overflow” and figure that wow, yeah that is the most horrible flaw we can imagine, but clearly nobody at NVD engaged their brains nor looked at the “vulnerable” code or the patch that fixed the bug. Anyone that looks can see that this is not a security problem.

The vulnerability should be obvious: at some point in the boot process, the VMK transits unencrypted between the TPM and the CPU. This means that it can be captured and used to decrypt the disk.

The new log/slog package in Go 1.21 brings structured logging to the standard library. Structured logs use key-value pairs so they can be parsed, filtered, searched, and analyzed quickly and reliably. For servers, logging is an important way for developers to observe the detailed behavior of the system, and often the first place they go to debug it. Logs therefore tend to be voluminous, and the ability to search and filter them quickly is essential.

The flaw is tracked as CVE-2023-40477 and could give remote attackers arbitrary code execution on the target system after a specially crafted RAR file is opened.

RARLAB released WinRAR version 6.23 on August 2nd, 2023, effectively addressing CVE-2023-40477.

https://www.zerodayinitiative.com/advisories/ZDI-23-1152/

Boring is good. Boring is stable. Boring means being able to focus on your work, not on what’s different about Go. This post is about the important work we shipped in Go 1.21 to keep Go boring.

There will not be a Go 2 that breaks Go 1 programs. Instead, we are going to double down on compatibility, which is far more valuable than any possible break with the past. In fact, we believe that prioritizing compatibility was the most important design decision we made for Go 1.

Espresso coffee is among the most consumed beverages in the world. Recent studies report a protective activity of the coffee beverage against neurodegenerative disorders such as Alzheimer′s disease. Alzheimer′s disease belongs to a group of disorders, called tauopathies, which are characterized by the intraneuronal accumulation of the microtubule-associated protein tau in fibrillar aggregates. In this work, we characterized by NMR the molecular composition of the espresso coffee extract and identified its main components. We then demonstrated with in vitro and in cell experiments that the whole coffee extract, caffeine, and genistein have biological properties in preventing aggregation, condensation, and seeding activity of the repeat region of tau. We also identified a set of coffee compounds capable of binding to preformed tau fibrils. These results add insights into the neuroprotective potential of espresso coffee and suggest candidate molecular scaffolds for designing therapies targeting monomeric or fibrillized forms of tau.

In vitro results, take with a grain of salt or shot of espresso.

MTE = Memory Tagging Extension

In mid-2022, Project Zero was provided with access to pre-production hardware implementing the ARM MTE specification. This blog post series is based on that review, and includes general conclusions about the effectiveness of MTE as implemented, specifically in the context of preventing the exploitation of memory-safety vulnerabilities.

Despite its limitations, MTE is still by far the most promising path forward for improving C/C++ software security in 2023. The ability of MTE to detect memory corruption exploitation at the first dangerous access provides a significant improvement in diagnostic and potential security effectiveness. In comparison, most other proposed approaches rely on blocking later stages in the exploitation process, for example various hardware-assisted CFI approaches which aim to block invalid control-flow transfers.

Implementation Testing

Mitigation Case Studies

The Kernel