GoFetch Side Channel, OpenSSF & Security Education, Fuzzing vs. Formal Verification – ASW #278

Another side-channel in a CPU, this time in Apple's M1 (and later) chips. The cool aspect of this is that it's demonstrated against a constant-time cryptographic implementation. Constant-time algorithms are intended to prevent leaks about secrets, such as not revealing the length of a key or the result of a byte comparison between a user-supplied guess and a secret.

The sky won't be falling due to this flaw. It's unrelated to memory safety and it weakens a recommended design pattern (i.e. constant-time operations), but it's a chance to highlight my favored approach to appsec -- as Columbo says, there's always one more thing.

Also covered in this article.

One of our recurring topics is security-minded education for developers, so this plan from OpenSSF is something we'll be watching throughout the year.

The plan has three focus areas. One stands out as something I never really considered -- educating managers on what they should expect in terms secure software development. And, I have to admit, I'm not sure how much I'd emphasize this aspect. We'll have to talk about what this should and shouldn't mean for appsec.

You can download a PDF of the plan here. You don't even need to fill out the form!

I'm mostly just noting this for those who enjoy reading security audits with an eye towards learning about new threat scenarios or security issues to test for.

I also wanted to highlight a forward-looking aspect of this audit -- they "integrated cert-manager into Google’s OSS-Fuzz project to help catch bugs on an ongoing basis.” That work is far more consequential than a point-in-time PDF.

The PDF of the report is here.

I think I've only seen formal verification in practice related to TLS and implementations like OpenSSL. I've read about its application in network protocols and e2ee systems, and I'm sure there's a crypto(currency) project out there that toyed with it beyond those noted in the article.

That article notes how fuzzing typically requires less time to get set up. That's the part that resonates with me. It feels a lot easier to express how a system is observed to operate as opposed to how it must operate. Effective fuzzing still requires setting up states and triggering transitions where a bug may be lurking, but we've seen the brute force approach here be somewhat successful and a guided approach (even with -- gasp! -- LLMs) be even more successful.

Plus, it's nice to be able to catch implementation errors with fuzzing along with design errors.

The list not only goes back at least 19 years, it also encompasses a lot more than just appsec.

I wanted to point out what the article doesn't cover -- fixing all the vulns. I think the spirit of keeping software patched is within a few of the items listed, but it's very refreshing and important to note that a hard problem isn't patching all the vulns. And I think that's because the premise that all vulns need to be patched is flawed to begin with.

The items that appeal to me and where I wish appsec would go are in the fail-secure, fail-safe design patterns.

On the part about making phishing a thing of the past, I think we're very close to that in terms of making credential phishing a thing of the past. (And we really need to make all the too-cute variants the term go away. They don't serve anyone in terms of eradication or user education.) However, there'll always be a degree of scams and social engineering that might fall under a definition of phishing. A lot of modern phishing-style scams predated the internet.

A kind of boring tool for a kind of boring subject, that nevertheless has a very non-boring potential improvement to supply chain security. Maybe boring appsec is fine!

Loop DoS came out of CISPA (Not CISA - CISPA is the Helmholtz Center for Information Security in Saarbrücken, Germany) that leverages weaknesses in application protocols which sit on top of UDP. In a nutshell, since these protocols attempt to implement stateful connections themselves instead of letting TCP do it, there's chance to "introduce" to servers to each other, and let them DOS themselves

In the US (probably other places, too?), commercial trucks (think tractor-trailer, "Semis," etc) are required to have Electronic Logging Devices(ELD) that track statistics like mileage per day to ensure driver/vehicle safety. Researchers at Colorado State University have discovered that these devices use bluetooth low-energy or wifi for some communication, such as software updates. And the security on these is weak. Did I mention yet that the ELDs connect to the vehicle's CAN bus?

While the researchers focused on a particular ELD, they believe the different devices out there are are similar enough that these weaknesses are industry-wide: Besides controlling the CAN bus, they were also able to demonstrate a "truck to truck worm" using ESP32 dev boards. In particular I like this, as it's breaching the concept of an expensive, difficult to learn "industrial" control systems with the ease and availability of controller devices that are becoming very common in consumer products.

We talk about "infrastructure security" and think of power plants and the like. But that 80,000 pound truck barreling down the highway at 60MPH can be a pretty big risk, as well...