It was bound to happen to Habari eventually, right? And in the dark recesses of my mind, I’m happy for two reasons. First because at last we merit inspection by “security consultants”. Second because we are staffed well enough to have addressed the issue within a reasonable amount of time. But some questions have arisen about how to handle security announcements, and there are distinct sides on the issues.
Spinning out of Control
People are going to publish security notices about your software whether you want them to or not. Sometimes there is altruism at work - people want others to know that something is unsafe. Sometimes it’s open malice - people sharing secrets of how to exploit software for their own malicious uses. In either case, as a software author, you can’t control what people say about you, and specifically what exploits in your software they expose to the world. So in the end, security exploits result in more spin control than controlling the information.
Obviously, the most powerful thing you can do to spin the news in your favor is to provide an immediate release that addresses the issue. This may be harder to do with smaller teams, since you have so many fronts on which you fight: New features, documentation, support, bug-fixing, and now security-notice tracking. An advantage with open source teams is in the speed with which you can address the issue quickly and reliably, since there can be many people working at once.
Of course, when you have a fix for the issue, you need to tell people that the fix is ready, and that they should use it. I think the announcement, rather than the circumstances around the issue itself, is the point of most contention.
Human Factor
There are a lot of things to consider when crafting the message to go along with your release. I’ve been given some advice over the past couple of days on how to handle it, and I’m not really pleased with any of it. What people have been suggesting to me is that since anyone can publish a full step-by-step tutorial about how to hack your software on their own site, that there’s no reason to avoid doing the same on your own site. I think these people, who must be on the outside, often forget the human factor.
Having a critical release announcement is more than just about the exploit and how to properly deal with it. In most cases, the critical issue affects many live installations of your software. I do not expect that explaining to the bad guys how to exploit someone’s install of your software is the best way to engender loyalty to your product. Publishing those instructions in plain view on the product’s own site seems unwise for that reason alone, even if those instructions are available in a myriad of places.
The rationale for publishing the instructions is that this will give users the information they need to decide if the critical update is something they need to apply. This rationale is mindbogglingly naive for a couple of reasons.
What Is a Non-Critical Critical Update?
When the developer says that an update is critical, should you believe them? Who knows better than the developer whether an update is critical or not? I would guess nobody does. And if you don’t trust the developer, then why are you running their software?
In this age of all-too frequent “critical updates” for popular operating systems, we’ve become somewhat numb to the word “critical”. Still, if you found yourself affected by an exploit that a critical update might have addressed, would you not consider that critical? I think it’s unfortunate that critical software updates have become optional; something that you can choose to put off at your own discretion, as if you know better.
It says “critical”. Update or suffer the consequences.
I agree that to some extent it’s a matter of trust. If you do not trust a developer to label things as critical when they are indeed critical and not trivial, then you might put off updates. It’s like a developer crying wolf.
Habari has a system for distinguishing critical updates from bugfixes and feature releases. Because we’re pre-1.0, we haven’t had a lot of opportunity to do bugfix releases, so users might see all of our releases as critical and not realize that we would actually distinguish them if there was a reason to do so. It just happens that we’re doing all of our significant bugfixes along with feature releases, so you only really currently see critical and feature releases. Don’t mistake that for us thinking that every future release is critical!
Isn’t there a weird psychology where people will upgrade immediately for a feature they want, but not for a critical “takes your server down and eats your first-born” software update that’s simple to perform. Unreal.
I'm a User and I Know What I'm Talking About, I Think
The other problem with giving users all of the information is that they most likely have no idea what to do with it.
This recent critical issue with Habari was a XSS issue. If you know what a Cross-Site Scripting issue is (and I’m not even sure that technically it was that, or maybe it was a specific subset of XSS – I digress) and how to exploit them, then you don’t need me to explain it. You can easily visit the open source code browser and see what code we changed to see how you could affect the XSS.
On the other hand, if you have no idea what XSS is, then the only thing you’d take away from an explanation would likely be “XSS is bad, and I should upgrade”, which is easily conveyed by “You are encouraged to apply this critical security update immediately.”
In either case, there is no need to lay out specifics about the issue, and there’s always the mailing list or IRC if you are interested in what the issue was and can’t figure it out on your own.
When you combine this with the thought of being prudent about posting the details of the software exploit on the same site where the software is distributed, perhaps you will come to the same conclusion as me – you really shouldn’t provide too many details on the main site feed. I’m personally of the opinion that common users will appreciate more that malicious users can’t as easily find (and what would be easier than having those details right on the software’s home page?!) the way to exploit their sites than they will that they have full detailed instructions for performing the exploit themselves. Why on Earth would they do that anyway?
What Are You Hiding?
I’m not saying that security updates should be hidden. I think people hear me saying the above and interpret it as me wanting to hide something that is in plain view elsewhere on various security clearinghouses. That’s not what I mean at all.
In fact, I think it would behoove us to report our own issues to those clearinghouses as they occur. People watch those lists who are intelligent and have experience in dealing with and testing those issues. We’d be grateful for their help.
Nonetheless, I think that some restraint should be shown in regard to spilling the beans on security issues directly to the primary forum for any software. I don’t know of any major software vendor that exposes step-by-step security exploits to their home page. Habari shouldn’t do this, either.
A balanced approach is warranted, one where we tell users that they really must upgrade. With security upgrades, we should never say, “You might choose to do this if you feel like it.” No, you really must. Your site exploited could potentially affect me or anyone else, if used for spamming, for example. Be a good citizen.
The balance should be that there is enough information in the announcement to send curious developers who need to know (Really? I’m curious who these people are.) to the mailing lists or source code repositories for the information they need.
And so, Habari 0.5.2...
All that said, Habari’s recent security flaw isn’t so awful. There is potential for data loss, which is one of the criteria we’ve outlined for an immediate release. But it’s only if a malicious user figures out how to use the exploit in a certain way, and only if they trick you into using it. Still, the potential is there, so there’s a fix.
If you haven’t updated to 0.5.2, you really should. I hope that real Habari users perceive our response as proactive, and if they have concerns with how we’ve handled security updates in the past, they step forward and voice their concerns on our users’ mailing list, where developers listen to users’ needs.
