In 1984, Ken Thompson wrote Reflections on Trusting Trust which provided a formal demonstration that absolute security of software is unachievable. Running any software at all involves an act of trust between people.
These days, this holds not only for the case of trusting that a software author is not malicious, but also trusting that the security model for a piece of software makes sense, and that the authors will follow best practices which are consistent with the chosen security model for their software.
Recently the author of Redis wrote a blog post in which he expressed frustration that despite documentation to the contrary, users of Redis continued to make false assumptions about the Redis security model. He explained that Redis had no security model by design, and set out to “show the Redis ‘security model’ in a cruel way”.
He proceeded to give an exploit which would allow, in some circumstances, an attacker to gain access to a ‘misconfigured’ Redis server.
The 'misconfiguration’ unfortunately had also been the default configuration. Not surprisingly, a number of machines running Redis were compromised within days of his post.
Insecure by Design
The Redis design decision around security is seemingly in line with another design goal: allowing a user to get a Redis server up and running quickly with minimal configuration.
These design goals seem to make sense – fast, quick, easy to use software, which is insecure by default. But there is a contradiction in terms of trust and expectations. Software that purports to require minimal configuration should also have reasonable defaults, including a reasonable default security setting.
The default low security setting was a mistake that led to a vulnerability.
The etiquette for disclosing vulnerabilities has generally been: inform the author, so they have time to fix things, let the author release a new version of their software, then finally announce it, preferably someplace like the bugtraq mailing list so that sysadmins can quickly patch their systems.
In the case when an author is not responsive, providing an exploit is a good way to get their attention.
The Redis vulnerability was posted in a blog by the author of the software itself and an exploit was provided. Clearly, posting an exploit does not make sense if the intention is to get the attention of the author. In this case, posting an exploit had the effect of allowing unskilled attackers to quickly find vulnerable servers.
Easy to configure software should have reasonable default security settings.
Releasing an exploit for software without providing a window to secure the software increases the number of compromised servers.
Providing an exploit for your own software is cruel, and it turns a simple misconfiguration into a zero-day vulnerability.
For a given piece of software, it’s important to be able to trust the author not only to not be malicious but to handle vulnerabilities responsibly.