Perl & PHP Vulns, Fuzzing & Parsers, Protecting Multi-Hosted Tenants, Secure Design – ASW #303

A quite enjoyable read through one of the many vulns that have plagued these devices over the past year(s). What struck me about this vuln, is that I can imagine a threat modeling discussion that based some assumptions on these interfaces are reserved for trusted admins. But so much of the implementation seems like a cascade of design flaws -- or at least opportunities to have a stronger design that wouldn't impeded the intended functionality.

And, of course, it's been a while since I've bothered to actually read through some code written in Perl. Perl, plus writing to config files, plus influencing OpenSSL's behavior all seem like avoidable errors. So, how do we get to the point where such errors are avoided?

There's a similar theme here with the Ivanti article. In this case, deserialization flaws enable an attacker to instantiate libxml and use that to read arbitrary files (and eventually obtain an RCE).

Whereas I suspect the other article was about old code written in Perl (and the lack of choices that could lead to a more secure design), this is about modern PHP whose design introduces inherent security challenges. We talk a lot about rewriting memory unsafe code into Rust and writing new code with secure design principles, but how do you deal with legacy code or brittle architectures?

This article initially caught my attention just because of the fuzzing aspect. (I admittedly wasn't familiar with Lima.)

However, what really grabbed me was the tangent on not having one, but three YAML parsers included by the project. And then seeing that one of the parsers turns the YAML into JSON for processing and back to YAML when it's done.

Next time I ask my co-hosts about their preferred file format for human-readable configs, I'll have to clarify that they aren't allowed to nest formats within each other.

p.s. The CosmicString article also had an example of submitting a POST request that contained JSON that in turn contained a value that was an XML blob.

The title feels a little bit like a misdirection -- the thrust of the article is really about isolating code execution in a multi-tenant environment. It just so happens to be an environment where code execution is used to train models. But if we set that quibble aside, it's still a good read about sandboxing systems, isolating tenants, and abusing authorization privileges.

Here's a welcome secure design improvement in how Windows handles privileged admin actions. Rather than relying on UAC (which was never a strict security boundary), it uses an ephemeral admin profile to execute the requested command. The intention is to constrain what malicious software might do by separating the privileges and execution from the "regular" admin profile of the system.

One more Microsoft article, which shows how one consequence of insecure design is to shift more burden onto the user to harden systems. We might say the problem comes from insecure operations in the sense of not following recommended practices, choosing poor passwords, or having an environment that's compromised first through some other vector. But at least two out of three of those items feel like something that software developers can better address through secure defaults plus secure design.

Not purely appsec related, but it's interesting to see how folks can manage to turn almost any feature into use for "evil"

Feels like this is code repo security week! GitLab's identified and patched a RCE vuln, where users can run pipelines on arbitrary branches.

Qualcomm has announced updates for a collection of it's chips and software after attackers were found to be exploiting vulns on Android devices. I checked to see if this was a quarterly release, or other reason for a large collection of issues but nope - this is just the October announcement.