What’s the worst that could happen?
This is the kind of question anyone who aims to qualify risk must ask, repeatedly. It’s also not the kind of question we typically ask during software development.
A typical project starts with an idea. This evolves into user stories describing the kind of experience we want our customers to have while using our tool. We define the “happy path” customers will take and build the application as rapidly as we can to support those workflows.
After our minimum viable product is, well, viable we start on quality control. Where are the obvious bugs and how hard are they to fix? Do we have proper test coverage? Is the application performant enough to actually solve the problem we set out to solve?
These questions are important, but they leave a fairly large gap. It’s also not that obvious to most developers.
What is the worst that can happen?
What happens if two users have the same first and last name but different email addresses? What if a user subscribes with an expired credit card? How does the application behave if someone stands on one foot while humming a tune as their roommate changes the channel on the radio in the other room?
The last question here is intentionally facetious. It’s ridiculous and outrageous, but it illustrates the kind of thinking you need to have to truly envious threat models. Not every threat is obvious – like weak passwords. Some are obscure and the kind of thing you’d imagine no one would ever think about.
In early 2021, someone found a remote code execution vulnerability in the popular Zend Framework for PHP. This bug used a weakness in a particular object’s __destruct() functionality. Usually this function would help clean up the system but, when abused, allowed an attacker to do whatever they wanted. Actually triggering the bug, though, was fairly convoluted.
An attacker could serialize:
- A custom
Response\Stream - That itself included a custom
Gravatarimplementation - That leveraged a
Rendererinstance - itself wrapping a
ReaderPluginManager - The embedded a custom
Callback - That bundled whatever userland code they wanted to execute
If an attacker was able to do all of the above, they could generate a serialized string that, when fed into certain projects leveraging the Zend Framework, ran whatever code they desired. It’s a significant flaw that gives a malicious attacker a lot of power and is not that dissimilar from my “stand on one foot while…” example.
It’s also far from the happy path developers expected anyone to use. That an attacker could do all of the above is one of the worst things that could happen with this chunk of code. Learning to ask the question and think from an adversarial mindset will help avoid your application/framework/project from being the subject of blogs like this in the future.
