Escaping from BlastDoor’s Sandbox, Spring RCE, Old Zlib Flaw, Startup Security – ASW #191

The biggest takeaway of this article is how attackers leveraged a series of logic bugs to avoid the security boundaries and controls created by Apple's "BlastDoor" sandbox for iMessage. This doesn't mean that sandbox and hardening was ineffective -- that design addressed many previous attack techniques. What it does show is that even sandboxes will fail against clever misuse of language capabilities. If you're really into iOS security, check out the deep dive on Objective-C linked to in the article: https://blog.chichou.me/2021/01/16/see-no-eval-runtime-code-execution-objc/ Check out our discussion of BlastDoor and links to additional resources from episode 166 at https://securityweekly.com/asw166/

It's a Java flaw, but not a log4j level of Java flaw. For once, it seems that a default config seems secure. The whole Java ecosystem still has its challenges, though. One of the workarounds includes downgrading to Java 8, which seems like the most unfortunate path to have to go with if that's the only viable option for your application.

We mentioned this briefly last week. Now the flaw has an official CVE -- from 2018! An interesting angle on this is the lifetime of a flaw, its discovery, and seeing processes fail such that a patch never makes it into the project. Maybe we should appreciate the impact that CVEs have on tracking and patching security issues.

A deep dive into programs most useful to fuzzers for eliciting errors with their targets. It's not something you're likely to need in your day-to-day appsec program, but if you've been interested in fuzzers and strategies for producing test cases, this paper has some neat ideas, observations about the difference between human-generated programs (chaotic!) and machine-generated ones (predictable!?), and how that makes a difference to successful fuzzing runs.

We touch on this topic quite often -- where do you start with appsec and what should an early hire or investment focus on. Ransomware is good to mention, although I'd characterize it differently. A common outcome may be ransomware, but the attacks typically come from social engineering attacks that then take advantage of over-permissive access to production systems. So instead of focusing on a particular threat (ransomware), focus on deploying FIDO keys to 100% of your company and employing least-privilege access to production systems. That will make social engineering attacks significantly more difficult and minimize the ability of a malicious actor to execute ransomware on a system of consequence.

Pushing for memory-safe languages is a great way to address an entire class of flaws. But that doesn't mean a language or the application that uses such as language is secure -- there are plenty of other classes of flaws beyond buffer and heap overflows. It's cool to see Rust have another security analysis tool available for it (albeit one still in early days). The write-up explains what a model check is and why it's different from other approaches like fuzzing. Be sure to check out the comparison to other approaches for additional tools or techniques you may wish to adopt, or even just to understand what types of issues those other approaches are geared towards identifying: https://model-checking.github.io/kani/tool-comparison.html

Here's a subtle flaw that comes from a slight mismatch between two HTML parsers within Chromium. In one parser, an iframe's srcdoc attribute passes through an HTML sanitizer, where the other parser doesn't send srcdoc through the same parsing workflow. This leads to a flaw that looks like it could become a universal XSS, which is bad news for browsers. Read more discussion about the flaw in the Chromium issue tracker at https://bugs.chromium.org/p/chromium/issues/detail?id=1231037

We don't cover PHP vulns too often. This one stems from PHP's underlying implementation - C. It's a classic signed/unsigned integer mismatch from a strlen() function whose input can be influenced by an attacker. It looks like the kind of flaw that code reviews, whether human or automated, should at least be suspicious of. It's also the type of flaw that requires a 2GB+ payload, which probably makes it much less conducive to unit tests, but probably still the type of situation of integer size boundaries for fuzzers to target.

This looks very much like a vulnerability that was just patched in Sophos and Sonicwall devices... ????