The Complexities, Configurations, and Challenges in Cloud Security – Scott Piper – ASW #304

This article hits one of my favorite topics -- parsers. And then it hits my even more favorite topic -- security flaws that come from inconsistent parser implementations. As the article points out, these inconsistencies arise from an ambiguous specification. In other words, there's a fundamental design problem with JSON that sets up developers for security failures. To make matters even more exciting, there are a few alternative JSON-like specifications as well.

If you're really interested in playing with parsers and creating a fuzzer (or just bored), check out the JSON format specification in RFC 8259.

Why not throw a protocol into the mix this week. Where the previous articles on parsers pointed out the problems of ambiguous standards, this article show how implementation choices still lead to inconsistent behaviors and potential security flaws.

You don't have to be implementing WebRTC to appreciate this problem. Any time you're defining an API and implementing an API (as well as the workflow or protocol to be supported by that API), you have to deal with the spirit of this type of problem. For me, the two key sentences of this article are:

"The behaviour discussed in this paper does not imply that a bug exists in the WebRTC specification. However, it highlights a gap that multiple implementors have failed to identify: checking the origin of the DTLS ClientHello."

In other words, "checking the origin" becomes a placeholder for any implementation detail that implementors fail to fully appreciate or adequately handle when working from a design.

Guess what -- there's even an RFC we can mention.

Check out the full guide here.

I like the spirit of it, since it can mostly be turned into a "do this" instead of a "don't do this" type of list. Although I admit I don't know why there's so much emphasis on CWEs. Does anyone really use CWEs in practice? Do they have anything meaningful for software architects?

You have until December 2 to turn this into a top 10 list -- or at least provide feedback on it.

p.s. I admit that I do remember CWE-22, but that's mostly to point out how ridiculously old it is.

There's indeed an appsec angle to this saga of corporate interests, competition, and open source. Essentially, a security policy was weaponized to take over a plugin. Ostensibly, this was because the plugin owner did not fix a disclosed vuln in a timely manner. What that reason chose to ignore was that the plugin owner's access was deliberately disabled as part of an effort that appears to be an overall bad faith endeavor to take over the plugin.

And now the new plugin is breaking sites for users who are caught in the middle.

The behavior is reminiscent of the recent polyfill.io situation where the new owner subtly inserted links to undesired destinations. In this case, the action is far more explicit and superficially associated with security interests.

Somewhat related, the WordPress plugin Jetpack had a recently discovered vuln that's been present since 2016.

More research demonstrating the power of probabilistic text processing -- and its limits in approximating human reasoning.

This type of research is also relevant for using LLMs as secure code authors or advisors. The appsec industry spent a lot of time going from grep to ASTs to source-and-sink analysis. Grep was still pretty successful and continues to be successful for some types of insecure patterns. But maybe LLMs are really just going to remain at the level of a grep command you can talk to without having to remember all the CLI flags.

I wanted to give this a brief mention for two reasons. One, because it relates to standards and protocols that the W3C is working on, and protocols will always be an area for security research. Two, because it shows where the trends are in terms of what those standards might cover.

Now, if only the "AI" at the top of the list stood for "appsec implementation" or maybe just "appsec involvement".

Quick reference about the growing adoption and success of passkeys. Also see this article about the benefits Amazon points to in deploying it.

This mostly caught my eye for its link to a free developing secure software course. I've only glanced at the syllabus so far and will report back once I've gone through it.

Why have just one article on parsing when you can have two! This research actually reaches back to August, but it's now been updated with the DEF CON video where Gareth Hayes describes his work. Well worth checking out for some surprising corners of security in handling email addresses -- and parsing.

And if you're really interested in another RFC, here's RFC 5322 about email address formats and an explanation about why regexes have so much trouble with that (in addition to missing regexes as parsers!).

The k8s image builder project builds VM images to make it easier for folks to bring up k8s clusters. Unfortunately it's been discovered that default credentials were used in this process.

Depending on which image builder provider that was being used, this could be a critical or medium level vulnerability.

The vulnerability has a cvss 7.8, but Trend's trying to say there's mitigating factors on the security vulnerability in their security agent.

The idea of making C++ "safe" is gaining steam. This proposal (which refers to Rust 50+ times) is a little long, but a good read with plenty of examples of how these extensions would work.

One of the things I like up front is the categorization of safety - Lifetime, Type, Thread safety, and Runtime checks. The proposal then frames some of the extensions in the eye of these categories.

If adopted, I'm curious to see what this does to the Rust ecosystem over the next year or two...