The topic of Magento module security has been heating up. Here are just a few things that have happened recently:
I have some strong thoughts on the matter which I haven’t been shy about sharing in the past…
So I think a requirement that @ext_dn should impose is around proper disclosure of vulnerabilities in modules.— Max Chadwick (@maxpchadwick) November 27, 2018
Here, I want to express them in long form.
Code vulnerabilities are an unfortunate, but inevitable reality of software development. One needs look no further than the recent Facetime bug to realize that no matter how big a company, and how sophisticated its testing procedures, it is impossible to produce code that is free of them
Therefore, the fact that a vendor ships code that contains vulnerabilities should NOT create a negative perception about that vendor. Instead, what is critical in assessing the quality of a vendor is how that vendor responds when vulnerabilities are identified in their code
The worst thing a vendor can do when they become aware of a vulnerability is to attempt to hide it from public knowledge. Doing so makes it more likely that customers will continue to run the vulnerable code, increasing the odds of being breached.
Instead, the vendor should transparently publicly disclose the existence of the vulnerability, ensuring that customers are aware and are able to patch.
The Magento ecosystem is an interesting one. A module may have been purchased and installed on a Magento site by a company that no longer supports that site. It also may have been purchased by a non-technical individual working at the merchant who is not able to accurately assess the severity of the issue. As such private disclosures such as emails to customers on file who have purchased the module are not enough. Instead, providers should attempt to disclose vulnerabilities in a way that will reach the entire community who is potentially impacted by the issue.
The Magento community tends to be heavily active on Twitter, so I’d suggest that Magento module providers share the information there, including a link to an article on their website with additional information about the vulnerability.
Another good question. It’s not always easy to correlate a module advertised on a vendor’s website back to its usage in the Magento codebase. As such I’d recommend that vendors always include instructions for customers to check if they’re impacted. For example:
“Check your composer.lock file for acme/foobar. If you have a version older than 2.9.1 you are impacted”.
Also, I’d suggest providing some details to assist in assessing the severity of the vulnerability. Magento publishes CVSSv3 scores for each vulnerability it patches. You could try these, but more importantly, the following questions should be answered:
Additionally, for highly critical issues (especially unauthenticated RCE / SQL injection) I’d suggest publishing an immediate mitigation patch that doesn’t require going through support to obtain.
The problem with this all is that despite the fact that I’ve said people shouldn’t have negative perceptions about code vulnerabilities, they do. As such there’s a clear incentive for module providers to attempt to hide or downplay vulnerabilities. Unfortunately, as mentioned, this has a negative impact on customers. As such, in parting, I leave the following message:
And finally, if you are a journalist, stop with the harmful sensationalization of software vulnerabilities. This only helps feed this awful, harmful cycle.
Hi, I'm Max!
If you'd like to get in touch with me the best way is on Twitter.