Posted
by
Soulskillon Tuesday November 20, 2012 @11:08PM
from the what-could-possibly-go-wrong dept.

An anonymous reader writes "Dutch hosting provider Antagonist announced their in-house developed technology that automatically detects and fixes vulnerabilities in their customers' websites. The service is aimed at popular software such as WordPress, Drupal and Joomla. 'As soon as a vulnerability is detected, we inform the customer. We also explain how the customer can resolve the issue. In case the customer does not respond to our first notice within the next two weeks, we automatically patch the vulnerability.' Antagonist plans to license the technology to other hosting providers as well."

You're talking about customer data here. They may have some customizations in the code that break if you allow yourself to patch it.

I would take another approach: disable the vulnerable file until the customer fixes it. By fixing it for them you may generate expectations which you'll not be able to match in the long run: "don't worry about software updating, the hosting company will do it for us".

will it likely break the customer's site, sure it will, but it will also jolt them into action

while it may seem that the customer would be reasonably pissed off, you could have it as a clause in the signup agreement that if a vulnerability was found the vulnerable file will be made inaccessable till the vulnerability is patched... after all it may be their website, but its the service provider's hosting infrastructure. it woul

I would take another approach: disable the vulnerable file until the customer fixes it. By fixing it for them you may generate expectations which you'll not be able to match in the long run: "don't worry about software updating, the hosting company will do it for us".

The issue is not so much as "disable the file" but rather "disable the module/plugin/extension", which would be even worse if this happened automatically.

So, if you're running WordPress or a popular message board (e.g. phpBB, vBulletin, whatever, take your pick) and the developer releases a general security update that applies to everyone, you'd be fine with your host disabling essentially your entire site until you fixed it? And if you're on vacation for a week or two when it happens? What then? I rather like the fact that the stuff I run can essentially sustain itself in my absence.

I might be okay with it if it was in the terms of service and the customer had been given fair warning that their site would be disabled if they didn't take action (though I'd never host with them). I may also be okay with it in cases where a vulnerability is actively being exploited and it's causing some form of harm to the host. But to pro-actively disable "vulnerable files" which may be necessary to the functioning of a site without first providing notice is not something that I could condone. I'm still undecided on even having them apply their own fixes, to be honest.

>>the developer releases a general security update that applies to everyone, you'd be fine with your host disabling essentially your entire site until you fixed it?

It all depends on the TOS from the host. Maybe the host declares that they disable clients that are contributing to (or may contribute to) network abuse. Unpatched machines will get compromised and become launchpads for attacks on others.

>>And if you're on vacation for a week or two when it happens? What then?

Would you rather come back from vacation to a disabled but uncompromised site, or to a enabled but compromised site?

Oh, the first, no doubt, but that's missing the point by setting up a false dichotomy. The third possibility, and the far more likely one, is that I'll simply return to a vulnerable, uncompromised site, and will have time to patch it on my own terms. Again, I'm speaking purely about personal sites here, and it's not as if every single phpBB forum running X.Y gets compromised the day after X.Y+1 gets released. I should have time to decide whether X.Y+1 is right for me or not, as well as investigate the issue

So, if you're running WordPress or a popular message board (e.g. phpBB, vBulletin, whatever, take your pick) and the developer releases a general security update that applies to everyone, you'd be fine with your host disabling essentially your entire site until you fixed it? And if you're on vacation for a week or two when it happens? What then? I rather like the fact that the stuff I run can essentially sustain itself in my absence.

I might be okay with it if it was in the terms of service and the customer had been given fair warning that their site would be disabled if they didn't take action (though I'd never host with them). I may also be okay with it in cases where a vulnerability is actively being exploited and it's causing some form of harm to the host. But to pro-actively disable "vulnerable files" which may be necessary to the functioning of a site without first providing notice is not something that I could condone. I'm still undecided on even having them apply their own fixes, to be honest.

I partly agree with you. If it is a general security update that is not actively being exploited: let it be. However, if it concerns a widely exploited problem, then yes: disable either the vulnerable script or the entire website, if you are hosted on a shared platform. Reason for this is that your script may open the entire server for malicious users and be a stepping stone to exploit local vulnerabilities. So by keeping your vulnerable site enabled, the hoster would be risking damages to all other sites h

Seems like they could end up with a lawsuit on their hands. What happens when a customer gets hit with a previously undiscovered WP exploit, after their host had already told them that they patched all the WP vulnerabilities?

They probably claim no such thing as having patched all WP vulnerabilities. Also, keep in mind that culture in Netherlands is really not to sue people for any minor thing (and if there was a lawsuit, damages awarded would be quite proportional, and costs are lower than some other countries).

Why do you want that? If you're spelling metre "meter" you're American, so isn't feet more appropriate? Unless you're not talking about distance and want to convert the feet of an animal into an instrument for displaying data.

At this point, if you want control over your site you can easily run some kind of VPS. If you use shared hosting, do you really want to share your server with a bunch of vastly outdated joomla and wordpress sites? This constitutes the majority of sites on your average shared hosting provider... leading to potential escalations to other sites (not always true, but it's possible), being used to host or send spam, leading to blacklisting of the server on spam lists etc.

Yeah, you're right. Reading the article I assumed it was a VPS, but after browsing the rest of the site I get that it's a new Anglefire or whatever. That's something I have no issue with. I read the article assuming it was OS level patching. This I don't care about.

Why would you find a new host when you're obviously not a customer at the hosting provider implementing this change? Or did you mean that you want to change from your current one to actually use this new, because you approve of the changes? Your two messages here are very conflicting.

Why are you finding a new host?
You should have read terms and conditions you agreed to when you signed up. You are paying them to view your site and make changes to it. It's part of the service you're paying for.

The Slashdot headline looks to be a bit exaggerated. This sounds like they're just auto-patching certain versions of some software. They're not "detecting vulnerabilities", they're detecting your software version. Any pure-play hosting services (ie: a dedicated wordpress host) have been doing this for ages.

There are software packages out that watch files that are being touched and scan them for known matches, viruses, etc and can quarantine them. Also software that watches out for relaying of emails and scripts sending out a ton of email (spam). A decent shared hosting company already does these two things. Common practice would be to disable the malicious code if it's still there (a lot of bots upload, execute, then remove the files) or reset compromised passwords and notify customers of what's going on.

Having dabbled with running shared hosting for 10+ years, there is a very clear business need for something like that.

The first line of defense for the web hosting company is to set security layers so that when a website gets hacked, only that account is compromised. Most respectable host can do that now.

But where does that leave you when a website gets compromised? Sure, the hack is contained to that account only, but still, script kiddies are running all kind of stuff on that account, and you have no othe

They do not modify customer data; only the software that runs the customer's sites. Which to me is totally cool as of the reasons to use a shared hosting site would be to not have to worry about the software that runs it.

They do not modify customer data; only the software that runs the customer's sites. Which to me is totally cool as of the reasons to use a shared hosting site would be to not have to worry about the software that runs it.

If you modify the code that writes the data you could be indirectly modifying the data.

You nailed it right on the head. The customer will just take their crappy outmoded php or perl or whatever to some other host who will gladly take their money. I was in web hosting as a sysadmin for several years. I had a customer who had built his website in php, and very poorly. You could to http://hisjackasswebsite.bizfo/index.php?myawesomemalwaresite.com/virus.asp [hisjackasswebsite.bizfo] and frame ANY site into his. He refused to believe it was his problem, even after I proved it to him first hand. So, I suspended his site (I

It's trivial to fix most vulnerabilities in customer websites without spending effort on scanning their code. There's a simple configuration change that will deal with virtually all the problems in one swoop.

You could implement this in a limited fashion simply by scanning customers' installations for outdated versions of the CMS and its modules, and updating them. Updates for the CMS are simple with Drupal and possibly with other CMSes, and updates for the modules are handled from within the CMS in most cases. I would not be upset if someone would keep Drupal and the modules updated for me if I missed an important (security-related) update.