Posted by greggles on March 13, 2013 at 9:34pm
Several hosting companies and WAF (web applicaiton firewall)/IDS (Intrusion Detection System) vendors have asked the security team to provide more details around how to exploit the security vulnerabilities published as advisories. Some of these vendors have agreed to an NDA or other form of quiet period. Our response to the first of these requests is the basis for this post.
The Security Team's basic response is "probably not" but we are open to some variants on this idea. I'm posting this here to see what others think, so please post your perspective below on how to handle it.
Why can't we do it now
- It creates more work for us, and we're already pretty busy
- It doesn't directly benefit anyone on the team, so it's unlikely we
would find a volunteer interested in the task - It makes the "script kiddy attacker" job easier - right now
exploiting an issue requires some level of savvy - It's probably not really possible to create sufficiently robust WAF
rules to block attacks as well as upgrading does. There are lots of
urls and HTTP request parameters where the problem can be introduced
that are completely site-specific. - Historically we've said that we should wait somewhere around 2 weeks before disclosing information
Some counter-proposals:
- If you want to help with security team work it could be ok having
one of their team members on the security team (standard requirements
apply https://security.drupal.org/join ) - If you want to pay someone currently on the team to provide the
details you need then that seems OK. The exact terms would be worked
out with the individual, but they could do something like update the
SA after 2 weeks to include the information. This would let all hosts
benefit from it. You could promote your contribution (and we probably
would as well) though not inside of the security advisory. - A more fundamental solution is for you to make it easier to upgrade
(e.g. the way Pantheon does for Drupal and Dreamhost does for
WordPress) - It would be fine if folks wanted to create a place (maybe a project on drupal.org) to collaboratively find and publish the details and appropriate WAF rules. It's unlikely the security team would endorse that (e.g. by linking to it in the advisories) since our general stance is "people should upgrade"
One question:
- Are there any web application projects which do provide this
information at a level where you are satisfied?
Comments
Re: Should we provide details for how to exploit issues?
As for hosting companies, I'm not sure why there's any answer other than "upgrade." For WAF vendors, I can see where they're coming from and it makes sense to make this information available to them as early as possible. It makes sense to let them have a paid seat at the table in order to get early access to the information, allowing them to create rules/updates for their device and potentially push those out pretty close to when the patches for the broken code are available.
It would seem to make sense that the WAF vendor's people would know best how to quickly and efficiently write rules for their product. So if module "foobar" has a confirmed vulnerability, let the vendor write a rule that could block the vector, if possible. Whether enough of them will be possible to prevent is a business decision for the vendor, I would think.
Plus, having an internal seat at the table could be an extra "plus" for certain vendors that choose to do this, over others that might not choose to join. If it were to be opened to one WAF vendor, I'd make the option available to all.
I think it makes sense.
Thanks for your thoughts. I
Thanks for your thoughts.
I was surprised by this as well, but hosting companies increasingly are providing WAFs. Those that can do it effectively will use it as a competitive differentiator compared to other providers. I think this makes sense anyway - infected sites getting exploited abuse the resources of the hosting company. If they can deploy WAFs to block that it saves their resources. They could yell at their client to upgrade (unlikely to work beyond a small percent) or charge their customers for the resources consumed by the attackers (likely to push the client elsewhere) or... get some WAF rules.
I don't really like the idea of a paid seat for private info. How would we vet that list of people to get this info early? What rules would we have on them for disclosing? Given the nature of the project (open source) and our resources to do things like vet and enforce policy (limited) I think it has to be open to the world at the same time even if that's later than when the SA is released. So far, the seat at the table comes from being committed enough to Drupal and the security team that you join the team.
I agree the vendors should have the write the rules. What they're asking for is someone to give complete and concise details on how to exploit. That is often a very tough task to do which is why we have a hard time saying who will do it.
knaddison blog | Morris Animal Foundation
Considering the amount of
Considering the amount of hosts you might be better off doing a "deal" with auto install companies, like fantastico and installatron. Just a thought. I couldn't think of any others that do it immediately and unless there is money exchanging hands.
Who would pay whom in this
Who would pay whom in this deal?
Historically the installer companies have done a really poor job of keeping up to date. I think they're the long tail of the Drupal sites.
Here's how I see the hosting world.
It's really group 2 that is likely to be interested in creating WAF rules. Do you see it differently?
knaddison blog | Morris Animal Foundation
Re: Payment
Hmm, why not the Drupal Security Team? Are there things the committee could do with money? Maybe travel to conferences to give talks? Offer some kind of financial support for members in terms of training or tools? Offer free training somehow (online?) and that costs money. I'm guessing there are other things the Sec Team could think of that they could spend money on that would help to make Drupal security more efficient.
I was thinking it was WAF companies, not as much hosts, that would like to have the ability to craft WAF rules even before the vulnerability is disclosed. Then if (pick a fake name) "High Perch" the WAF vendor wants to have access to the data and make that a marketing point that they can push out Drupal WAF rules sooner, that is a great marketing angle for the business and a competitive advantage.
That's the direction I was looking at it. Right now, the WAF vendors get the information the same day as all the Drupal site owners and the black hats. I'm confident the better vendors get those rules in place very quickly if they want to, but if they could get the rules in place even before the patches are released, that's a potential competitive advantage.
Isn't it those WAF vendors that those in group 2 use? Or maybe they would if they had the rules in place early.
The Security Team is not a
The Security Team is not a legal entity and I'm not sure if it should become one. In order to take non-trivial amounts of money it would have to become some kind of legal entity. There are a few ways that some members of the team might take in some money and a few folks have said "what would we do with it" so there are definitely ideas that are on the verge of being "shovel ready".
It's totally possible that someone could get information in advance and integrate it into a WAF by being a member of the team and doing work as part of the team.
I'm hopeful that we'll be able to find a solution with these hosting companies/WAF vendors that is mutually beneficial, but so far haven't seen one that is practical for our volunteer-based team.
knaddison blog | Morris Animal Foundation