Equifax’s Breach, CISA’s 1,000 Vulns, Rust’s TLS Library, Complexity vs. Design – ASW #256

BIND vulns are thankfully rare these days. This one a CVSS score of 7.5 for what's effectively a DoS, but the default config means it's only exploitable if you have access to the loopback interface.

So, minus points for still being a C-based program, but bonus points for a default config that minimized exploitation.

If you enjoy reading C code, here's the patch.

If you enjoy reading Rust code, here's project to create a memory-safe Trust-DNS.

While it's not clear on how this info was sourced, it indeed tells a clear picture about Equifax's missteps that lead to the breach being so impactful. It starts with a 48-hour response to patch all the affected Apache Struts systems -- that they knew about.

There's legacy tech, unprotected secrets, unconstrained networks, and unnoticed certificate expirations.

Prioritizing patches against the KEV seems like one of the smarter ways to manage known vulns. And 1,000 doesn't sound like a terribly high volume, either. Especially considering the proliferation of CVEs.

It also seems to be driving improved patching behavior, which is a good outcome.

But CISA doesn't intend to just rely on the KEV catalog to encourage consumers to patch their apps, they're also pushing on secure by default and secure by design to make the need for such patches less common.

Check out CISA's statement here.

The Heartbleed vuln launched several projects that could take the place of OpenSSL.

Now OpenSSF is investing into the Rustls project to bring Rust's memory safety to the TLS and QUIC protocols. That's a good way to invest in improving the open source ecosystem, but normally I'd say it's mostly a benefit to the Rust community.

However, the project also has a lofty goal that could make it easier for existing apps to swap out OpenSSL for Rustls -- "We are also planning to implement a C-based OpenSSL compatibility layer so that OpenSSL consumers can easily switch to Rustls without needing to make major changes to their code or learn Rust."

Given OpenSSL's less than stellar API design, that would be an amazing feat and a significant step towards reducing memory safety vulns.

I like this approach to programming language security. There's a common mistake Go programmers make in for() loops with how they reference and use loop iterator variables. The Go project even documented this in their common mistakes wiki.

However, the project didn't stop with just documenting a "don't do this, please" to programmers and shift left the blame and implementation errors onto them.

Instead, it's now changing how those variables are scoped in order to more closely match what programmers (incorrectly) assumed and desired the behavior to be. The change in behavior is easily managed, so old code can remain the old way and not suddenly be unstable because of a compiler change.

It's cool to see a language adapt to how it's used and programmers think it ought to be rather than a rigid adherence to how things must be.

We highlighted a bunch of Trail of Bits work last episode, so I don't want to overdo it this episode. But the list of security issues in this review reads like topic list for an intentionally vulnerable web app. The successes here are the move to a memory-safe language, investing in security audits, and being transparent about the results of those audits.

We've covered Phil's take on complexity and security before, but it's always a good subject to revisit.

This time I wanted to focus on item 9 in his argument about why bad design is the true enemy, not complexity. Number 9 is, "Reduce Error Messages and Guidance."

I like this, of course, because it points out the anti-pattern of ever-increasing configuration and hardening guides. If those guides are getting bigger and bigger, maybe that's a sign the system's design is pushing too much decision-making onto a user. And that can be a sign of poor defaults, poor abstractions, and poor workflows.

This is mostly intended for our readers who check out the show notes. First, thank you!

This is a follow up to the libwebp article that John highlighted last episode. It adds some interesting technical details and insights into exploiting the vulns.

It's not a vuln in the direct endpoint protection code, but a utility that uninstalls 3rd party AV software. Still...security companies shouldn't have RCEs.

Via scheduled security scan policies, a user could run pipelines as an arbitrary (gitlab) user. CVSS 9.6 feels a little high, then I realize I'm thinking of GL from my previous use as a single tenant. Multi-tenant, the severity of this becomes more clear...

I think I already said this once today, but security devices shouldn't have RCEs.

I don't want to pick on PHP, but I'm going to pick on PHP. There's better languages to be coding security devices with that are faster, more secure, and have better tooling for performing static analysis.

I'm doing one of my non-security stories here, but I it serves a purpose: For the security peeps, think about how a change in code as small as this can have such an effect, and think about why developers will sometimes push back on your requests that seem to request trivial changes.

For the developers - as security people we talk about "avoiding surprise" - while this is a neat trick to improve performance, remember to at least document little hacks like this, or figure out a slightly less hackish way to squeeze out performance like this.