Hosting Provider Automatically Fixes Vulnerabilities In Customers' Websites

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."

Comments

Why not fix it immediately?

[loufoque]

In two weeks it might be too late.

Re:Why not fix it immediately?

[sabri]

In two weeks it might be too late.

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".

Re:Why not fix it immediately?

[loufoque]

It would have to detect that it can safely apply the patch. Also it could be opt in, of course.

Re:Why not fix it immediately?

[Anubis IV]

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.

Re:Why not fix it immediately?

[Bios_Hakr]

>>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? For the first case, you'd need to apply the updates and then restart the server. For the second case, you'd need to scrub the machine, re-install all your software and customizations, then restore your databases and content directories from backup.

>>I rather like the fact that the stuff I run can essentially sustain itself in my absence.

The point is, it can't. You can't secure a box and walk away for days/weeks/months. You need to be actively maintaining your servers.

Re:Why not fix it immediately?

[Anubis IV]

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 issues I might encounter with upgrading. By taking that decision away from me, my hand gets forced in ways that could impact my visitor's ability to use my site.

Re:first!

[noobermin]

Fail bro...fail...

What can possibly go wrong?

[adius]

The road to hell is paved with good intentions

Liability

[rebelwarlock]

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?

Re:Liability

[Njovich]

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).

Thanks for your help

[RobbieCrash]

I'll be finding a new host now.

You're not being paid to view my site or make changes to it, let me know and shut it down if it becomes a problem; keep your fingers out of my site.

Re:Thanks for your help

[Njovich]

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.

Re:Thanks for your help

[LordLucless]

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.

Re:Thanks for your help

[pipatron]

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.

Good idea, wrong solution

[Anonymous Coward]

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 other choices but suspend that account, and write an explanation letter to the customer.

And then what? The small business owner has no effing clue what the hell you are talking about and is furious that his website is down. You then proceed to explain that his site is hacked, and that nothing on it can be trusted no more. Does he have a clean backup? Of course not.. He contacts his buddy that set up the site 2 years ago. He has no clue of course. Blames the host for suspending the site of not being secure enough.. Buys some cheap hosting elsewhere and moves the site away from you.

This is a LOOSE LOOSE situation...

SO: I clearly see why they are being pro-active on this problem. There is a certain market segment of the shared hosting business that can benefit. That being said, I much, much prefer the mod_security approach, which works as a filter on the HTTP layer, to mitigate most script kiddies and automated hacks, which covers pretty much all the potential hacks these small websites can be targeted with and has much less potential side-effects.. Modifying customer data is a big no-no IMHO...

Re:Good idea, wrong solution

[wvmarle]

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.

Re:Good idea, wrong solution

[toygeek]

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 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 was getting sick of getting that server blocked on sorbs etc) and he went somewhere else. I contacted his new provider and let them know the score and advised them to watch out. They were actually thankful for the heads up. Could this program have fixed that? Doubtfully. Will the problem persist? Yes. Because people are lazy and cheap!

Re:Good idea, wrong solution

[BradleyUffner]

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.

Re:first!

[Fnord666]

For your own sake, please get a (w/l)ife.

I like the implication that the two are mutually exclusive.