Why Release Software Vulnerability Details?
For more than a week now, I have been aware of a very serious security flaw in a popular WordPress plugin. When a security flaw is discovered, there are a number of steps that must be taken to defend against a malicious hacker exploiting the flaw.
- Secure affected sites against such an attack.
- Notify software developer of flaw and proof-of-concept demonstrating the exploit.
- Make Public Disclosure.
Later today, I will be making public disclosure. THIS IS NOT THE NOTICE.
When we discovered this flaw (Cheers Duncan Riley for reporting it to me), the first thing was to ensure that b5media was not vulnerable to this exploit. After a few days, I made the plugin author aware of the flaw and at the same time, gave him a time table to fix the flaw. That timetable was seven days. Today, at 5pm EST some point, I’ll be posting my findings and proof of concept.
To be clear, I could have easily posted the exploit details when I discovered it. Taking software security to heart and realizing that bugs happen (I’ve been programming for over six years now), I’d rather be told of the problem and allowed the chance to fix it rather than having thousands of potential hack victims.
He thanked me and has put in significant effort on a new version of the plugin, but it would seem that at this point, the plugin author would rather whine about not having his next version ready than to get the job done. Of course, as a plugin author, you own the problem. It’s your fault and it’s on your head if someone else gets hacked. At the end of the day, it doesn’t matter to the guy with the hacked blog that you go to high school and don’t have time in your day to take care of unpaid work. You put the plugin out there. Thousands like it and use it. And thousands of blogs could be hacked.
At the end of the day, security flaw details are released to protect the public by forcing the programmer to take care of business. If I were black hat, I could already be wreaking havoc on blogs and not tell the plugin author or anyone else how it was happening.
My advice to programmers: Quit getting defensive about your work. Do the work cleanly. When someone reports a bug, fix it. Even if it’s just a patched version of the same plugin. You can’t be blamed if you show due diligence. Sit on your ass and complain that someone is going to expose the flaw and you’ll lose credibility, your reputation and the reputation of your plugin will be tainted.
I’ll be posting the details of this flaw this afternoon as planned. Stay tuned.
Pick up your copy of the WordPress Bible, a wildly popular resource for beginners and experts alike.
Written by Aaron Brazell on September 22, 2006
Popularity: 1% [?]
Aaron Brazell
Steven Fisher
Ray Capece
Carlos Granier-Phelps
Andrew Feinberg
Mike Dougherty
Chris Bachmann
Leslie Poston
Jerald Sheets
Scott Goldblatt
Mykel Nahorniak
Peter Corbett
Jonathan Dingman
Geoff Livingston
Jeremy Toeman
Rachel James
Chris Parandian
Warren Sukernek
Joseph Hauckes
Shana Glickfield
Vinnie Garcia
David Nick
Duncan Riley
Carol Ott
Darren McLaughlin
Mike Oliver
Rico Masterson
Lou P. Nuts
No personal enmity at all, Andrew. I alerted you I’d post this a week ago and you gave me a hard time when I kindly reminded you this morning. Like I said, this particular post (not the detailed vulnerability one), has value in it no matter what flaw or what chunk of code. It’s why I post this stuff.
Darren,
It was quite a shock when someone else (oh yeah, it was Aaron) sent me a link to your blog. You made no concerted effort to let me know about the problem. I never got a good response about how to fix the problems. And now, I’ve implemented nofollow in 2.0. I have a feeling that’s not a full solution. But I’m not an SEO expert, and I don’t know what is a good solution. If you or anyone could let me know, I would really like to be sure for Dem 2.0.
And Aaron, I just read over our emails together. You did tell me I you would post in one week. I completely didn’t register that line. I had no idea you had put me on a track. Of course, I have no one to blame but myself. Sorry.
I’m not trying to make enemies with anyone here. What you two have found are indeed grave problems with Democracy. It’s just been very frustrating to see all these posts arise without any chance for review or discussion.
We’ll get over it though. Democracy 2.0 is a step in the right direction. It’s not perfect yet. But it’s all I have to offer right now. What’s past is past.
Darren,
It was quite a shock when someone else (oh yeah, it was Aaron) sent me a link to your blog. You made no concerted effort to let me know about the problem. I never got a good response about how to fix the problems. And now, I’ve implemented nofollow in 2.0. I have a feeling that’s not a full solution. But I’m not an SEO expert, and I don’t know what is a good solution. If you or anyone could let me know, I would really like to be sure for Dem 2.0.
And Aaron, I just read over our emails together. You did tell me I you would post in one week. I completely didn’t register that line. I had no idea you had put me on a track. Of course, I have no one to blame but myself. Sorry.
I’m not trying to make enemies with anyone here. What you two have found are indeed grave problems with Democracy. It’s just been very frustrating to see all these posts arise without any chance for review or discussion.
We’ll get over it though. Democracy 2.0 is a step in the right direction. It’s not perfect yet. But it’s all I have to offer right now. What’s past is past.
Darren,
It was quite a shock when someone else (oh yeah, it was Aaron) sent me a link to your blog. You made no concerted effort to let me know about the problem. I never got a good response about how to fix the problems. And now, I’ve implemented nofollow in 2.0. I have a feeling that’s not a full solution. But I’m not an SEO expert, and I don’t know what is a good solution. If you or anyone could let me know, I would really like to be sure for Dem 2.0.
And Aaron, I just read over our emails together. You did tell me I you would post in one week. I completely didn’t register that line. I had no idea you had put me on a track. Of course, I have no one to blame but myself. Sorry.
I’m not trying to make enemies with anyone here. What you two have found are indeed grave problems with Democracy. It’s just been very frustrating to see all these posts arise without any chance for review or discussion.
We’ll get over it though. Democracy 2.0 is a step in the right direction. It’s not perfect yet. But it’s all I have to offer right now. What’s past is past.
Jalenack,
Don’t feel too bad — I think this pain is something everyone goes through the first time they release a piece of software that turns out to have a security hole (I learned it via an early version of Subversion, though it was a bit easier because I wasn’t the only maintainer, i.e., the only person able to make an official-sounding release as a source people already trust).
I strongly recommend making a 1.2 release that is exactly 1.1 plus the bugfix (it would have been better to do that first, really). For a careful site administrator, upgrading and closing a security hole are two distinct things, and they usually want the choice to do one but not the other, conveniently. I say “conveniently” because, sure, anyone can get the patch and apply it themselves… But in practice, people are counting on the maintainers to make this stuff easy. That’d be you :-).
Um, at the risk of pontificating even more: here’s some material on security announcements and releases that may be helpful:
http://producingoss.com/html-chunk/publicity.ht...
http://producingoss.com/html-chunk/release-line...
Good luck,
-Karl
P.S. Jim, to answer your question: I think the key thing is giving the maintainer(s) a window of time to make a security release. Since a security release is, by definition, just the most recent public release plus the security fix, it should never take more than a day or so to put one together. Since the discover of the bug usually understands that the maintainers are volunteers and may not check their mail within 24 hours, though, a typical window size is 5 days to a week (I’ve seen as low as 3 days). Of course, you should also go public with the flaw! But by waiting until the maintainers have had a chance to put together a patch and a release, you can include links to those things in your announcement of the flaw. That way no one’s helpless: the moment they see the news, they also see a solution, and they’re not stuck improvising.
This method has proven to be a good compromise between going public immediately and sitting on the discovery forever, I think.
Jalenack,
Don’t feel too bad — I think this pain is something everyone goes through the first time they release a piece of software that turns out to have a security hole (I learned it via an early version of Subversion, though it was a bit easier because I wasn’t the only maintainer, i.e., the only person able to make an official-sounding release as a source people already trust).
I strongly recommend making a 1.2 release that is exactly 1.1 plus the bugfix (it would have been better to do that first, really). For a careful site administrator, upgrading and closing a security hole are two distinct things, and they usually want the choice to do one but not the other, conveniently. I say “conveniently” because, sure, anyone can get the patch and apply it themselves… But in practice, people are counting on the maintainers to make this stuff easy. That’d be you :-).
Um, at the risk of pontificating even more: here’s some material on security announcements and releases that may be helpful:
http://producingoss.com/html-chunk/publicity.ht...
http://producingoss.com/html-chunk/release-line...
Good luck,
-Karl
P.S. Jim, to answer your question: I think the key thing is giving the maintainer(s) a window of time to make a security release. Since a security release is, by definition, just the most recent public release plus the security fix, it should never take more than a day or so to put one together. Since the discover of the bug usually understands that the maintainers are volunteers and may not check their mail within 24 hours, though, a typical window size is 5 days to a week (I’ve seen as low as 3 days). Of course, you should also go public with the flaw! But by waiting until the maintainers have had a chance to put together a patch and a release, you can include links to those things in your announcement of the flaw. That way no one’s helpless: the moment they see the news, they also see a solution, and they’re not stuck improvising.
This method has proven to be a good compromise between going public immediately and sitting on the discovery forever, I think.
Jalenack,
Don’t feel too bad — I think this pain is something everyone goes through the first time they release a piece of software that turns out to have a security hole (I learned it via an early version of Subversion, though it was a bit easier because I wasn’t the only maintainer, i.e., the only person able to make an official-sounding release as a source people already trust).
I strongly recommend making a 1.2 release that is exactly 1.1 plus the bugfix (it would have been better to do that first, really). For a careful site administrator, upgrading and closing a security hole are two distinct things, and they usually want the choice to do one but not the other, conveniently. I say “conveniently” because, sure, anyone can get the patch and apply it themselves… But in practice, people are counting on the maintainers to make this stuff easy. That’d be you :-).
Um, at the risk of pontificating even more: here’s some material on security announcements and releases that may be helpful:
http://producingoss.com/html-chunk/publicity.ht...
http://producingoss.com/html-chunk/release-line...
Good luck,
-Karl
P.S. Jim, to answer your question: I think the key thing is giving the maintainer(s) a window of time to make a security release. Since a security release is, by definition, just the most recent public release plus the security fix, it should never take more than a day or so to put one together. Since the discover of the bug usually understands that the maintainers are volunteers and may not check their mail within 24 hours, though, a typical window size is 5 days to a week (I’ve seen as low as 3 days). Of course, you should also go public with the flaw! But by waiting until the maintainers have had a chance to put together a patch and a release, you can include links to those things in your announcement of the flaw. That way no one’s helpless: the moment they see the news, they also see a solution, and they’re not stuck improvising.
This method has proven to be a good compromise between going public immediately and sitting on the discovery forever, I think.
Good feedback coming in. Just released a fix for the SEO problems mentioned above.
Good feedback coming in. Just released a fix for the SEO problems mentioned above.
Good feedback coming in. Just released a fix for the SEO problems mentioned above.
I’m amazed that a group of adults would get nasty with a highschool kid. Nice. :p
Who invited the woman to the party? :p
I’m amazed that a group of adults would get nasty with a highschool kid. Nice. :p
I’m amazed that a group of adults would get nasty with a highschool kid. Nice. :p
I’m amazed that a group of adults would get nasty with a highschool kid. Nice. :p
LOL — I invite myself. You haven’t figured that out by now?
:: douses the crowd with a cloud of estrogen ::
Who invited the woman to the party? :p
Who invited the woman to the party? :p
Who invited the woman to the party? :p
LOL — I invite myself. You haven’t figured that out by now?
:: douses the crowd with a cloud of estrogen ::
LOL — I invite myself. You haven’t figured that out by now?
:: douses the crowd with a cloud of estrogen ::
LOL — I invite myself. You haven’t figured that out by now?
:: douses the crowd with a cloud of estrogen ::