Zenbleed, Drop in Zero-Days, Security Testing Handbook, Public Speaking – ASW #249

I've been a long-time fan of Clang and LLVM. Its various analyzers are immensely helpful for discovering and fixing issues that lead to bugs and security flaws.

This article highlights the desire of researchers who want to work more directly through the compiler toolchain, such as reviewing and manipulating the AST in order to find all sorts of security issues. (In fact, the analyzers work on the CFG, not the AST -- which I didn't realize.) It points out how Clang is optimized to optimize code and serve developers, but it doesn't have all the features a security researcher would want.

But if you don't care about compiled code or the few acronyms in this summary have already thrown you off, think instead about the development toolchains you currently use and how well they can be instrumented for security purposes.

Per the article, “Last year, researchers detected 41 zero day vulnerabilities being used in the wild, down from 69 in 2021, which was the most since Google began tracking them in 2015.”

The article then includes some insights from Maddie Stone of Google's Threat Analysis Group on what might influence the drop and how the drop itself isn't necessarily a strong signal of overall improvements within security.

But I mostly grabbed this article to talk about the opposite end of this topic -- new vulns are what keep orgs patching, cool new vulns are what make for entertaining conference presentations. Yet defending against zero-days shouldn't be near the top of the list for most org's security strategies. All sorts of other resources like the Verizon DBIR and CISA point to valid credentials as the primary vector for most attacks. For sure, we'll cover zero days and their implications, but we can't forget the boring parts of security like asset inventory, strong authentication backed by solutions like FIDO2, and keeping software up to date.

Last episode I shared some disappointment at a list of cloud security tools. So, this week I'm including a tool I would have expected, or at least suggested, to be on such a list.

ScoutSuite is an open source cloud configuration scanner. You can audit your environment or have it provide continuous monitoring for risky changes.

One caveat is that it's the open source version of NCC Group's freemium offering for cloud monitoring. That's a relatively common model for open source projects like this. Even so, we'll continue to cover other open source projects that provide similar auditing capabilities.

The writeup and techniques may be of interest to Android folks. It's mostly a brief updated on a vuln identified about four years ago. But what made me include this article is the timeless nature and more general applicability of its two takeaways. No spoilers -- you'll either have to read the article or listen to the episode!

We briefly covered TETRA last episode and I wanted to include this article as a followup. It adds some context to original design and current use of the radio systems, including some discussion on whether the reduced key size constitutes a backdoor.

Wow do people sure love semgrep. It's the first chapter in Trail of Bits new Testing Handbook. It's a pretty nice start, with lots of examples of advanced usage and an impressive amount of additional resources. Fingers crossed we'll see many more chapters in the upcoming weeks.

This article is a bit older, from May 2023. But it's topical with our interview segment about cars and it's also updated this week with a response from the vendor.

Plus, the title is a WTF moment -- why does a car battery monitor need your location data? I guess these are the new flashlight apps from over a decade ago. A small, very narrow-purpose app that makes a grab for lots of data is indistinguishable from a malicious app.

There's a wealth of advice here for public speaking, which is well timed given we're headed into the height of conference season in Vegas.

Tavis Ormandy at Google has found a speculative execution vulnerability in AMD Zen2 CPUs where register state is not correctly rolled back after the speculation system goes down the wrong branch, leading to "easily exploitable" ability to leak registers "across concurrent processes, hyper threads and virtualized guests."

Also of note, this was found via fuzzing.

Also, there's a bit of teeth gnashing on the OSS Security mailing list about how AMD has submitted patches for this in the Linux Kernel - it looks like they haven't covered all CPUs and/or use cases.

Also also, this can be mitigated by setting a "chicken bit" that disables speculative execution.

Not sure I noticed Google was putting POC code on GitHub for their work before. Browsing up a level or two in this GitHub repo can be interesting. https://github.com/google/security-research/tree/master/pocs/cpus/zenbleed

After we covered CVSS v4 recently, I wanted to give a different perspective on things. At large scale, CVSS by itself probably won't work for most organizations.

See also the EPSS model at FIRST https://www.first.org/epss/model

Earlier this year the Keepass password safe relesaed an audit of the project, along with some tips for what users can do to ensure their passwords remain safe.

I just (re?)noticed this book last week while doing some research. It came out a little before The Hardware Hacking Handbook, but has a bit more of an appsec feel and talks through more basic hardware hacking aspects, vs the glitzy-sounding work of Chipwhisperers and power fault injections.