Hosting Provider Automatically Fixes Vulnerabilities In Customers' Websites 73
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."
Why not fix it immediately? (Score:4, Insightful)
In two weeks it might be too late.
Re:Why not fix it immediately? (Score:5, Interesting)
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? (Score:4, Interesting)
It would have to detect that it can safely apply the patch. Also it could be opt in, of course.
Re: (Score:1)
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
What action? (Score:2)
will it likely break the customer's site, sure it will, but it will also jolt them into action
Yep, it sure will jolt them into action ... in court
It would be extremely foolish to forget that we do live in a sue-happy world
Re: (Score:1)
It would be extremely foolish to forget that we do live in a sue-happy world
not as foolish as assuming that the US means the world
Re: (Score:2)
Try UK, Australia, France, Germany, Japan, Korea, Hongkong, Singapore ...
You think lawyers in countries other than the good ol' US of A just sit there all day and do nothing?
Re: (Score:1)
Try UK, Australia, France, Germany, Japan, Korea, Hongkong, Singapore ...
You think lawyers in countries other than the good ol' US of A just sit there all day and do nothing?
If you mean 'Nothing useful', Yes :0)
Re: (Score:1)
http://yro.slashdot.org/story/12/04/20/0058202/australian-isp-wins-case-against-movie-studios [slashdot.org]
Re: (Score:2)
Er disable the vulnerable file? You either seem to be confusing an infection for a vulnerability, or you have no idea how web services like this actually work.
Yes. A simple chown root:wheel and chmod 000 will usually do the trick*. And I'm pretty familiar with webhosting services, I used to work for the largest hosting provider in that country.
*yes, I know that is easily circumvented. However, someone proficient enough to circumvent that would be proficient enough to fix the root cause as well.
Re: (Score:2)
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.
Re:Why not fix it immediately? (Score:4, Insightful)
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: (Score:3)
>>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 b
Re: (Score:3)
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
Re: (Score:2)
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
Re: (Score:1)
Re: (Score:2)
They may have some customizations in the code that break if you allow yourself to patch it.
yeah, 'cos it's not going to break when someone hacks the shit out of it...
Re: (Score:2)
Re: (Score:3, Funny)
Fail bro...fail...
Re: (Score:2)
Re: (Score:3)
For your own sake, please get a (w/l)ife.
I like the implication that the two are mutually exclusive.
What can possibly go wrong? (Score:2)
Re: (Score:2)
i think the good intention here is letting a vulnerable site with vulnerable user data stay accessible from the internet.
Doing business with a company named 'Antagonist'.. (Score:2)
It doesn't help that their logo is colorful.
Re: (Score:2)
It doesn't help that their logo is colorful.
Well, can be worse... imagine the doing business with the Contrarian [slashdot.org]
Liability (Score:3)
Re:Liability (Score:5, Insightful)
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).
will it automatically convert feet to meters ??? (Score:1)
just curious, will it convert feet to meters ???
Re: (Score:2)
Re: (Score:1)
you misspelled "to" and "realy" in a two line post... so if you aren't American, then I'm going to go with illiterate.
Re: (Score:1)
If you assume the britts are the only ones using "metres" you're an american, it's spelled meter in most other languages.
Re: (Score:2)
Well DUH. A meter is only a few inches longer than a yard, just multiply by three. If you need accurate measurements, use a meterstick instead of a yardstick.
Thanks for your help (Score:3)
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 (Score:5, Insightful)
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: (Score:2)
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.
Re: (Score:3)
Re: (Score:2)
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.
Re: (Score:3)
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: (Score:1)
Good idea, wrong solution (Score:2, Interesting)
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
Re:Good idea, wrong solution (Score:4, Informative)
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: (Score:2)
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: (Score:3)
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
Re: (Score:2)
This is a LOOSE LOOSE situation...
I don't know, it seems pretty tight to me.
Detection is nice, auto-patching leads to trouble (Score:1)
We do the same where I work (detection part only), but wouldn't touch customer data. So the most we can do is warn the customers.
Easy! (Score:2)
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.
Turn off PHP and ASP.
Re: (Score:1)
Or you can implement your own (Score:1)
[Disclaimer: gratuitous plug] https://www.shone.co.za/ [shone.co.za]
Well, it could be done, kind of (Score:2)
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.