Good questions! Note, that I'm affilated with Nextcloud so obviously a bit biased.
Only because a project is very transparent about security vulnerabilities does not necessarily mean it's inherently insecure. In fact, at ownCloud we found all critical vulnerabilities ourself and also run a successful bug bounty program. (for Nextcloud we are also considering one)
Since you're referred to in that article as a "security engineer", I'll ask the following:
I know nothing of PHP other than its reputation. But apparently ownCloud is written in PHP and JavaScript. And PHP has its own "Security" section in its Wikipedia entry. And it has a reputation for security problems.
So, how "secure" (whatever that means) is ownCloud / Nextcloud? Has security been a problem for this software in real life?
Happy to answer this. First of all: Makes using a specific programming language a software much less secure? Probably not. You can do mistakes in every programming language. But since a lot of software is written in PHP and there are also many unexperienced PHP developers this reflects kinda bad on the language.
There is often the perceiption that ownCloud would be insecure because we have so many advisories. But these are just there because we proactively look for security vulnerabilities and patch them. (see also https://statuscode.ch/2015/09/ownCloud-security-development-...)
Oh! And we also run a bug bounty program for ownCloud and Nextcloud will have one with probably even higher rewards soon! - HackerOne did even do a case study with us so it can't be too bad ;)
(https://hackerone.com/resources)
> First of all: Makes using a specific programming language a software much less secure? Probably not.
Quite the contrary, most probably yes. Mistakes happen, but different
languages make different kinds of mistakes impossible or very easy. You can't
get segfault when manipulating strings in Perl or Python, while in C it takes
plenty of effort to avoid.
That is true, yes. Base ruby or C or PHP make it easy to make entire classes of mistakes you won't get using certain other languages.
But many of these problems can also be caught using the right tools and framework. With Ruby, using Rails will eliminate entire groups of risks you would have without it.
This is the same with PHP and frameworks like Symfony - which, incidentally, we use large parts off. And Lukas has been working a LOT on doing this kind of work, making sure we eliminate types of problems and mistakes developers could make. Combined with training (giving talks and workshops on writing secure code to our developers at events), code reviews by him and others, static code checking and so on, you get something that is really quite secure.
I am confident enough to say that our code base is the most secure way of sharing and syncing files using open source. Of course, before you or somebody else brings it up, SSH and rsync makes for a more secure experience but that's not exactly what Nextcloud competes with so perhaps add 'that gives a dropbox-like experience' to the above qualification :D
I've been following OwnCloud for years, and the one thing that has kept me from using it is the lack of delta sync. This fork has piqued my curiosity again. Is delta sync going to be a priority for NextCloud?
Whilst I have your attention ;) Are there any plans to add CalDav/iCal client functionality to NextCloud? I'd like my NextCloud server to sync with external calendars (E.g my work Google calendar) so that I only have to point my client devices at my own server.
I strongly recommend radicale with DavDroid. I've been using this set up (that only took a few minutes to complete, especially with Caddy for TLS) for months now with great success.
Radicale will also automatically commit every change into a Git repo, so you can always go back to any point in time. Just amazing.
Radicale sounds interesting, but it looks like it's just a CalDAV server? OwnCloud/NextCloud already gives me that. What I'm looking for is a way of syncing calendars which have to be off-site, to my own server. I don't have control over the fact that my company uses Google calendars for work and I'd like to dump my Facebook events into an OwnCloud/NextCloud calendar too.
Not in the way that you require it. But you can always file an issue or enhancement request :-)
That said, we'll likely have Webcal support (https://github.com/owncloud/calendar/pull/443), that way you can at least in ownCloud view your Google calendars. (it's not synced though)
The impact is a different one though. In that scenario pointed by Hanno somebody needs to have access to the storage which already requires some kind of previous gained access. What could be done by an attacker then is to infect EXE files or so.
In the case of Seafile one could simply change passwords of any user etc.
But yes, crypto is hard and I agree that the way we did it at ownCloud is far away from the best way. :-)
I sincerely hope that Nextcould embraces the C4 contract for community building. That would be IMHO the best way to create and grow a community that is truly open and will survive for a long time.
Excellent link, and thanks, but the branching thing is hardly touched on, other than a quick small paragraph that reads like "it's too hard for people to learn".
The archive.org links were used at the creation of the blog post. (which was not necessarily the release date ;-) - needed to find some time to write it)
So Wordpress is an interesting example. Because the CVE assignment date has nothing to do with the release date of the patches. Wordpress doesn't request the CVE on their own.
So we're still at a 4-5 day delay (https://wordpress.org/news/2016/02/wordpress-4-4-2-security-...) for security fixes for a web-facing software. This is still far worse than just enabling automatic updates in Wordpress. I have not much problems if that would be a locally exploitable vuln, but web software usually is exploitable via web.
When it comes to web software I believe it's unacceptable to add any additional delay. (sure those bugs were not that severe, but as other examples in the blog show the problem with delayed or never updated packages is inherent)
> This is still far worse than just enabling automatic updates in Wordpress.
A webapp updating itself, having write access to its files (I see zero privilege separation in [1]) and getting updates from a hopefully not compromised source (see Linux Mint lately), that's just asking for trouble. I trust the Debian mirror infrastructure with signed packages that are updated by a privileged system user way more.
The archive.org links were used at the creation of the blog post.
I still find it disingenuous to use an archive.org link dated February 7 on February 13.
So we're still at a 4-5 day delay for security fixes for a web-facing software.
I agree that this is (far) too long. I just dislike the sensational tone of your blog post and subtle bending of facts. Linking to the Wordpress 4.4.2 release page and the Debian changelog would have been factual and convincing. Pointing to a week-old webpage, which was outdated on even the original date is just sloppy or manipulative.
"Please look at this commit so you know how you can hack us", sounds certainly like a much better idea ;-)
> Security history at Wordpress
When was there a single very grave vulnerability within the core of Wordpress? Mostly plugins are the root of all evil there.
(besides the nasty XSS one in Jetpack, which was caused by a static HTML file)
> - From what I've heard, security fixes are provided to enterprise customers first, so if you're lucky your adversary is one of them and knows about vulnerabilities way ahead of you.
This is wrong. Until now there has not been a single moment where customers did receive patches in advance. The only difference being is that they see the advisories earlier, but at this moment patches are already available for all.
> maximum bug bounty is $500
For the record we receiced until now 340 reports by over 150 individuals and until now only 1 vulnerability within the server has been pointed out.
(Full Path Disclosure of the ownCloud root folder such as "/var/www")
> If you need project management stuff and care about privacy, maybe look at https://protonet.info/ or something along those lines
> "Please look at this commit so you know how you can hack us", sounds certainly like a much better idea ;-)
I think that'd be better than a deceptive commit message, yes. ;-)
IMO, security-related changes should clearly be marked as such - if you don't want to have them publicly, you can keep it on a private branch for the time being.
> When was there a single very grave vulnerability within the core of Wordpress? Mostly plugins are the root of all evil there.
The same (plugins) probably applies to ownCloud, still that doesn't make it better. I personally think that embracing PHP's low entry barrier [1] is the wrong approach and I'd rather see a security-driven design.
> This is wrong. Until now there has not been a single moment where customers did receive patches in advance. The only difference being is that they see the advisories earlier, but at this moment patches are already available for all.
Thanks for the clarification - very sorry for the FUD. I got this info at a conference from one of your enterprise customers not-so-technical management guys, who is apparently misinformed.
> For the record we receiced until now 340 reports by over 150 individuals and until now only 1 vulnerability within the server has been pointed out. (Full Path Disclosure of the ownCloud root folder such as "/var/www")
My argument was that the market price of vulnerability is more or less a metric for security strength [2], and 500 USD doesn't seem to be much. If we presume that the value of a critical ownCloud exploit exceeds 500 USD, your bounty program provides very little incentive to search for or report critical vulnerabilities and you'd only get low-quality reports (which seems to be the case).
> What makes you thinl they are more secure?
I think that ownCloud has a big problem with automated vulnerability scanning and the security properties of managed appliances are generally superior. I unfortunately can't edit my original post anymore, but I should have added that running ownCloud behind a VPN is a very good idea as well.
So, if we ignore all lower and medium severity ones we're basically only left with CVE-2015-2213 which requires authentication. Also XSS is barely something one can blame PHP for. That's pretty low number.
For the record: ownCloud protects you against XSS using Content-Security-Policy.
This is an arbitrary wishfulness. I'm not even sure why you're debating Wordpress vulnerabilities -- if your point is that PHP is a secure application development environment, then even if WP was riddled with 9.0 severity exploits, it shouldn't matter. It seems to me that by correlating your product's security with WP's, solely because they are both PHP apps, is conceding the ponit.
The one column at the link with that has "medium" and "low" values is "complexity" which means CVSS's "access complexity". So having many rows like this means there are many vulnerabilities that are easy to exploit!
Also CVE-2015-2213 is marked as NOT requiring authentication (along with about 7 other straight remote code execution CVEs).
> The one column at the link with that has "medium" and "low" values is "complexity" which means CVSS's "access complexity". So it means there are many vulnerabilities that are easy to exploit.
I'm aware of that, I have a ton of CVE entries filed myself. I was referring to the score (https://nvd.nist.gov/cvss.cfm), anything below 7.0 is not deemed "high".
> Also CVE-2015-2213 is marked as NOT requiring authentication (along with about 7 other straight remote code execution CVEs).
CVE entries are often terribly done wrong if they are not provided by the vendor (which is what ownCloud does).
See https://core.trac.wordpress.org/changeset/33555 for the patch for CVE-2015-2213. As you can see this is within the function "wp_untrash_post_comments" which is called by "wp_untrash_post" which only accepts user-input from the Wordpress admin panel.
That's correct.