This week's news: The high cost of low-quality code

Every Wednesday, Nick Chase and Eric Gregory from Mirantis go over the week’s cloud native and industry news on the Radio Cloud Native podcast.

This week, Eric and regular guest-host John Jainschigg discussed:

• The high cost of low-quality code

• Potential vulnerability in Kubernetes' TokenRequest API

• A new mode of attack against air-gapped systems

• New features in Linux 6.1

• And other stories on the podcast, including runwasi, COBOL research, and much more

You can watch the entire episode below or download the podcast from Apple Podcasts, Spotify, or wherever you get your podcasts. If you'd like to tune into the next show live, follow Mirantis on LinkedIn to receive our announcement of the next broadcast.

John: Per Mike Vizard, writing for DevOps.com, a report published last week by Synopsys along with the Consortium for Information and Software Quality (CISQ) estimated that software quality issues might impact the US economy to the tune of $2.41 Trillion in 2022, against a GDP of $24 Trillion.

The report obviously points fingers at Cybersecurity failures, including data breaches. But…what’s astonishing is that losses here are just a small component (perhaps a third) of the larger risk domain of Operational failures, which is costing us collectively $1.81 Trillion. A chunk of this, in turn, involves losses incurred in the process of finding and fixing software defects ($607B), and overlaps with a $520B chunk ascribed to losses around legacy systems. About a third of the ‘operational failures’ losses (plus a bigger outside chunk) illustrates losses incurred because of technical debt ($1.52T). That Technical Debt part of the Venn diagram also embraces a $200 billion chunk labeled “unsuccessful dev projects” (lol).

In short, it’s a mess. And the only way out is to smooth out and simplify software development and operations to improve software quality and its subset, security. The CPSQ report introduces a (to me) new term, which they’ve apparently been using since 2020, called “DevQualOps,” of which DevSecOps is a conceptual part. We clearly need a complex Venn diagram for DevXOps now.

Eric: Turning to security, DataDog Security Labs published an article this month on a newly discovered attack vector against Kubernetes clusters: the TokenRequest API, which supports user authentication via JSON Web Tokens (or JWT). The danger here is that “attackers can abuse this feature to create long-lived and hard-to-detect privileged access to Kubernetes clusters.” 

DataDog details the standard JWT authentication process and then shows how it can be abused to create privileged access that lasts a long time—say, a year—and is bound to critical system resources. Since there is no way to revoke tokens once they’ve been issued except by deleting the resource they’re attached to, that could pose a real problem. 

Fortunately, the piece also details best practices that can help avoid this sort of attack. Some of these tips are basic security hygiene: use RBAC and observe the principle of least privilege. Others aren’t as immediately obvious—they note that you can set an upper limit on token lifespans, as AWS does by default, and this will mitigate the creation of long-lived malicious tokens. You can also monitor audit logs for significant details like the IP address of token requesters, specific resources they want access to, and the user agent requests are coming from—kubectl, for example, rather than the system itself. The full piece is definitely worth a read for anyone thinking about cluster security.

John: Per ZDNet’s Danny Palmer, Cybersecurity researchers at Ben Gurion University of the Negev’s Department of Software and Information Systems Engineering have demonstrated a new take on hacks in the classic Van Eck phreaking class that can probe air-gapped systems like computers in SCIFs. A newly-published research paper further details that the attack is both evasive and potentially easy to introduce into air-gapped targets, because the information probing, transmitting (and thus exfiltrating) part is all software and can execute from a user-level process, and works even when run inside virtual machines. The receiver part is mostly software, running on a smartphone with a $1 antenna. It’s called COVID-bit – which is cute.

Basically, you write your hack and figure out how to get it into the SCIF and onto something that can run it. Hard, but not impossible. The software manipulates dynamic power consumption and momentary loads on CPU cores to generate low-frequency radiation from 0-60Khz – so at and under AC current frequencies. These can be used to convey information to the receiver, which can be a few meters away – even on the other side of a wall, though not on the other side of a Faraday Cage, presumably. It’s very, very slow, but it grinds exceeding fine and works unless they put the cuffs on you and drag you off before transmission finishes.

Eric: Version 6.1 of the Linux kernel dropped this week, bringing much anticipated early support for Rust in the kernel as well as some interesting features like support for destructive BPF programs that can deliberately crash the system. The smashy BPF addition is intended to support kernel debugging situations where you might want to initiate a crash dump, and is implemented with guardrails to ensure it’s only being used knowingly and for tracing.

The advent of Rust is probably the big story here, though. It’s still early days, with—by Linus Torvalds’ command—the minimum support required to create a module and load it into the kernel. If Rust sticks around, it’ll be the first language in addition to C to have any staying power for kernel development, and Rust’s memory safety should theoretically help to patch Linux security flaws that are the result of memory safety problems. The first implementations are expected to be drivers, especially new drivers—if Rust gains traction in the kernel, it may be more a matter of slow growth through new code rather than a lot of rewritten C code. In fact, we’ve already seen some early work on Rust drivers for things like NVMe and the Apple AGX GPU found in their M1 and M2 chips.

The release also kicks off a sub-optimally timed merge window for the 6.2 release over the last two weeks of December. One thing we can pretty confidently expect for the next version: finally, a fix for our floppy disk problems. A patch submitted for 6.2 proposes to patch up memory leaks that can emerge when you load a floppy disk. So, you know, if nothing else, your floppy disk issues will be resolved in 2023.

Check out the podcast for more of this week's stories.