Unforgivable Vulns, DeepSeek iOS App Security Flaws, Memory Safety Standards – ASW #317

Last week we covered RFC 9700, the "Best Current Practice for OAuth 2.0 Security".

This article is a nice companion that explains some of the vulns called out in that RFC.

Shaming as an infosec tactic has rightly fallen out of favor, as it's rarely effective and often misdirected. For example, shaming users who fall prey to phishing scams tends to reduce their collaboration with security teams and centers the burden for security on end users when there's a lot of designs, defaults, and mitigations that security teams could be putting in place instead.

But the point of this article is very much a constructive call to action on eradicating vuln classes. It attempts to help orgs identity and prioritize classes to go after, and calls on the cybersecurity industry to make mitigations easier to implement.

For me, the real challenge is in the section, Assessing ‘ease of implementation', since that requires insights and (shock!) engagement with developers to understand the kinds of technical and architectural constraints they encounter.

Another way to think about this article is as a reference for how to approach threat modeling. Ask what always goes wrong, how bad the consequences are, and how easy a mitigation could be.

This ties in nicely with the article on "unforgivable" flaws. After all, the very first problem the researchers list is "Unencrypted Data Transmission" because the app disable App Transport Security (ATS) on iOS. In other words, the secure design is the default option. Disabling that is easily unforgivable.

The last point, "Data Sent to China & Governed by PRC Laws", highlights that appsec can't be a purely technical consideration. It's like the physics joke about, "First, assume a spherical cow in a vacuum..."

I often lump OAuth 2.0 and OIDC into the same blob of IAM problems. Just like RFC 9700 showed how the design and implementation of OAuth 2.0 ran into ambiguities and complexities that turned into vulns, this article shows how similar complexities in AWS come from ambiguities and variance in what vendors describe for their OIDC integrations.

We talked about .NET security in the guest segment, so why not have a .NET security example in the news?

Despite touring on parsing, it's...not really exciting. But there's one important line that's on theme and speaks to me: "The security updates in January 2024 changed the default behavior of parsing HTTP headers…and no longer allow overwriting of trusted values..."

There we are -- a default that improves security. That's much better than adding another bullet to a hardening guide.

Videos are available now. Three that I'd highlight are:

• Project Zero: Ten Years of 'Make 0-Day Hard'
• Achilles' Heel of JS Engines: Exploiting Modern Browsers During WASM Execution
• Confusion Attacks: Exploiting Hidden Semantic Ambiguity in Apache HTTP Server!

The list is live!

Stick around. We'll talk about this with James Kettle in the next episode.

We had one article with a call for figuring out "unforgivable" flaws. Now this article calls for better defining what "memory safety" means and how to standardize that into software development.

Right now I'm really just including this as a parallel to the first article and as something I plan to check back on in six months.

Check out the announcement and call to action.

This also put the CHERI Alliance on my radar.

p.s. as a lovely gesture to one of my common (unending) reminders, the cert for the call to action link expired while I was writing this up. So, yes, memory safety is important in a Trusted Computing Base (TCB), but security problems don't end with memory safe software.