Hacker News Reader

Comment by zimbatm | Hacker News Reader

Unfortunately OwnCloud is fundamentally broken because all "apps" share the same process and have to be written in PHP. The bigger the ecosystem gets, the harder it is going to be to deal with security issues. If OwnCloud wants to become a reference platform for other developers it really has to tackle sandboxing and permissions.

View on HN

If we want to do this in a way where everyone can run their own infrastructure then we've got to tackle some of the distributed systems problems. Specifically, life-cycle management of software/apps, how things sync/backup, and issues of identity and connectivity. One method is to take a clean-slate approach and build up a new stack (with its own trade-offs) e.g. Using unikernels as a base http://amirchaudhry.com/brewing-miso-to-serve-nymote/

>and have to be written in PHP.

How is this different than other HN beloved products like Drupal or pretty much any CMS? I can't think of any single one that has proper sandboxing. OwnCloud is just a type of CMS really, but instead of managing HTML, it manages all sorts of filetypes.

I would argue that the security of what one would put in Owncloud is more important, as an individual, than what one would put into Drupal. But you can correct me on that, I haven't really used a CMS.

Just playing devil's advocate, but isn't this true with many CMSs? Most implement "users" (and or groups) either in-house or using the underlying OS, and when it is the underlying OS the CMS needs access to all of the user's files anyway to make cooperation and interoperability work, essentially placing a big bullseye on the CMS system itself.

It's true and is the reason why so many PHP powered CMS are so insecure, how many times do you hear about a new wordpress exploit?

It really has nothing to do with PHP. Changing the language or framework wouldn't inherently change the design.

e.g. http://www.cvedetails.com/vulnerability-list/vendor_id-26/pr...

Having said that PHP does make it very hard to run each interpreter process as the user it is doing work on behalf of. Some of the best systems out there run each user's process under it's own uid:gid (or equivalent), and each user has their own filespace and/or database. Obviously this pushes the separation issues down to the OS kernel rather than in the app, but most widely used OS kernels get at least an order of magnitude more, most of the time several orders more, testing for these user separation security features. NIH, re-inventing the wheel and all that.

how many times do you hear about a new linux kernel exploit?

Pretty much everything is insecure. Writing things in not-php isn't the magical fix you seem to think it is.

What an absurd comparison...

The linux kernel has 16 million lines of code, Wordpress has 300k.

Yet Wordpress[1] has had nearly as many security vulnerabilities as the kernel[2]; 194 vs 257 exploits.

Wordpress is one of the most exploited software packages ever created. It is the textbook example of bad programming.

Just mentioning the kernel when talking about Wordpress is pretty ridiculous.

[1] http://www.cvedetails.com/vulnerability-list/vendor_id-2337/...

[2] http://www.cvedetails.com/vulnerability-list/vendor_id-33/pr...

I am no fan of wordpress, and I agree that it is a textbook example of bad programming... but it is also a textbook example of good community management and success at empowering non-programmers to have their own web presence. And I believe that the amount of exploits has as much to do (if not moreso) with its sheer popularity as it does with the code.

> Wordpress is one of the most exploited software packages ever created.

Hyperbole much?

It's one of the most popular software packages installed on the web. It's not surprising it has a lot of eyes on it.

This has nothing to do with eyes.

Dozens of other packages have a much larger install base than Wordpress.

Wordpress has 32(!) CVE's tagged with "Exec Code" (remote code execution) alone. The last one a mere 6 months old.

If you know another project that comes even remotely close to that then I'd be genuinely curious which one that would be?

> This has nothing to do with eyes.

Yeah, it does. You can write a crappy piece of software that nobody uses and because nobody has interest in it, it has no known security issues! Big deal.

I'm not saying that Wordpress has a great code-base or that there's no correlation, but that popularity is a substantial variable in that equation.

> Dozens of other packages have a much larger install base than Wordpress.

Name one web based software suite that's installed more often.

Name one web based software suite that's installed more often.

What does "web based" have to do with anything?

Do you think SSH, Postfix, nginx, Apache & Co don't get the same amount of scrutiny? Each of them has a significantly larger install base than Wordpress.

> Do you think SSH, Postfix, nginx, Apache & Co don't get the same amount of scrutiny?

NO! Because they're behind a firewall AND each operates on a very restricted protocol! It has nothing to do with quality of codebase. If Wordpress was behind a firewall and only restricted to text-based input per spec, you wouldn't find many vulnerabilities either.

> What does "web based" have to do with anything?

Because "web based" is the client. It has to be flexible and with flexibility, comes complexity, and with complexity come exploits.

Try getting a CRM going on Postfix or all the myriad other things Wordpress is being used for.

NO! Because they're behind a firewall

Huh? SSH, Postfix and nginx are usually not firewalled.

Because "web based" is the client. It has to be flexible and with flexibility...

If "flexibility and complexity equal vulnerability" then why does the linux kernel, 53x the size of Wordpress and a tad more complex than a CMS, not have about 53x more exploits?

And why does no other CMS system or framework come even close to the number of critical vulnerabilities in Wordpress?

> And why does no other CMS system or framework come even close to the number of critical vulnerabilities in Wordpress?

Because no other CMS or framework has as many deployments. Not even close.

> If "flexibility and complexity equal vulnerability" then why does the linux kernel, 53x the size of Wordpress and a tad more complex than a CMS, not have about 53x more exploits?

Because it's behind a firewall. Do I really need to keep repeating myself?

If I could send remote commands to your kernel, don't you think there would be a few more exploits kicking around?

> Huh? SSH, Postfix and nginx are usually not firewalled.

If you're not restricting access to SSH using a firewall, then you're a bigger idiot than I thought you were.

>If you're not restricting access to SSH using a firewall, then you're a bigger idiot than I thought you were.

I'm not sure name calling is really appropriate here. Yes, firewalling stuff is certainly appropriate, particularly administrative things, but key based auth is pretty secure, firewall or no.

You're also nitpicking on a single point when he mentions other things that are definitely not usually firewalled. Your mail and web servers are generally open to the world, regardless of whether or not SSH is.

If you think that sshd gets restricted to "text-based input per spec", you should get out more. Or at least check your logs more.

My logs are clean. Because sshd is restricted to specific ip ranges. Ever hear of a firewall? Apparently the other guy on this thread hasn't either.

The difference is that OwnCloud is marketed as an operating system and is aimed at holding all the user's personal information. Users who aren't necessarily knowledgeable enough to distinguish trusted and untrusted "applications".

A CMS is usually used by a company and has different threat scenarios. Usually only sysadmins configure and install extensions.

It's still a bit ahead of launch, but we are preparing an open source alternative to OwnCloud (that also includes messaging platform) that acts as an OAuth server for apps/plugins and an API and does not impose all apps to be implemented in the same language. We are using a NodeJS runtime, but the code is generated using a strongly statically typed language, Opa.

Source code is not yet published, will be AGPL.

Docker containers: https://github.com/MLstate/PEPS

> It's still a bit ahead of launch, but we are preparing an open source alternative to OwnCloud

OwnCloud is licensed under the AGPLv3. Curious why you think it's not Open Source Software.

Was not speaking about OwnCloud, but PEPS which is going to be AGPLv3 in a few days.

FreeBSD is an open source alternative to Linux. Not saying that Linux is closed source.

Is there a better alternative to OwnCloud that doesn't have similar flaws?

I'm not being sarcastic, it's fine to say it's broken but that doesn't really make a difference if there are still no better alternatives!?

Sandstorm, a platform which allows users to run arbitrary applications on a server in a secure sandbox. Of course, OwnCloud is at version 8 and Sandstorm is still working out its permissions UI.

I think they've got different goals.

My impression OwnCloud aims to be a replacement for "the google suite" (not search, but mail, docs, calendar, etc) -- it's really focused at the app layer. I think this is appropriate and there is a need for this.

There's also a need for "a platform which allows users to run arbitrary applications on a server in a secure sandbox", and certainly you can hypothetically build what OwnCloud is aiming at on such a platform. But it's going to take a lot more time and be harder to get right and be reliable and be easy to install and run.

I think OwnCloud is trying to be as easy to install and run as possible, to get a replacement for the google suite wwith apps that work as well as possible and are as easy to use as possible. I think this is a good goal, and they are making reasonable choices toward accomplishing that goal. I am not sure how well they've succeeded.

I believe the point of Sandstorm is to allow people to install mail/docs/calendar apps as simply as possible. It already has multiple document editors ported.

To install apps into Sandstorm, you literally just click on a link - Sandstorm will manage grabbing the app and installing it for you. Sandstorm itself is a self-contained daemon that can run on any Linux server (and, at some point, there'll be an ISO to install an auto-updating Linux with Sandstorm on it).

I've been moving my Drive sheets over to EtherCalc on Sandstorm and all of my new documents I write on Etherpad for Sandstorm. Draw.io also just released for Sandstorm, which is one of Google Drive's original third party apps.

I think Sandstorm in principle is the sort of thing that would run and deploy Owncloud. It doesn't happen to have it in its list of apps at the moment. Similarly there's indieboxproject.org, which has a lot fewer apps, but it does support Owncloud.

The issue there is that ownCloud and Sandstorm share a lot of goals and functionality. Both are meant to be app platforms in a respect. And both are meant to organize your personal data. Since Sandstorm wants every file to be a granular document, putting the entirely of ownCloud in a file would be kinda odd. It'll likely happen sooner or later though.

For file syncing, this came up on hacker news once upon a time: http://syncthing.net/

An easy to use and powerful alternative is: http://www.emitcloud.com

The only feature it has is file sharing, but I quite like Seafile: http://seafile.com/en/home/

Shameless plug, but we use strong static typing to implement PEPS:

https://github.com/MLstate/PEPS

(will be open source AGPLv3, release this month)

wordpress is in php

wikipedia is in php

facebook is in php

flickr is in php

photobucket is in php

need i say more?

> wordpress is in php

That pretty much makes the point. 194 vulnerabilities in Wordpress with CVEs in 2014.

http://www.cvedetails.com/vulnerability-list/vendor_id-2337/...

I would argue it is the developer writing the code, not the language it's written in.

Tools can help developers write safer code.

Yes, a good developer can write safe code in bad environment. But an average developer writes safer code in a good environment.

That list appears to include CVE going back to 2006 at least. I count 17 in 2014, the highest rated of which is an arbitrary code exectution (CVE-2014-5203) rated 7.5.

Not sure number of disclosed flaws is a good metric to look at, whether it's high or low.

Arbitrary code execution is pretty damn bad. Anyway he wasn't just counting vulnerabilities. Wordpress is renowned for its terrible security (or plugins with terrible security often).

I avoided making any value judgement on purpose - you can't really do that off-the-cuff. Looking at the reports (linked here, [0]) it concerns hash checks on serialised widgets. The apparent vulnerability was reported by the Wordpress security team and reported as being hard to actually make work - I can't find a PoC or any actual exploit reports. It seems based on [1] that a fix was submitted 2 months before the report and made available to automatic updaters a few days prior (? I'm not sure how the reporting dates and such work here really, on a superficial view that's right though the bug is 2014-08-13 and the fix 2014-06-08 with the report of the update [2] coming 2014-08-06). So, whilst yes an arbitrary code execution is severe one that is fixed before it's made public and without any clear way to exploit it is perhaps less of an issue than it first appears. But then of course the number of installs mean you can very likely find vulnerable installs in the wild even today.

TL;DR simple statistics don't really seem to work well in providing a proper view of comparative levels of security of web apps.

[0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-5203

[1] https://core.trac.wordpress.org/changeset/29389

[2] https://wordpress.org/news/2014/08/wordpress-3-9-2/

Yes.

I thought Facebook made their own PHP fork type of language.

yeah, to say Facebook is written in PHP is misleading. Facebook was originally written in PHP. Now it runs on the HHVM, which foregoes supporting the dangerous parts of the PHP stdlib, and offers better performance (fixing the two biggest problems with PHP). As I understand, much of their new code is written in Hack which interoperates with their legacy PHP code but supports gradual typing and other safety features (and some niceties).

Facebook is written in PHP, but they have invested a lot into making their PHP not be PHP.

Reply on news.ycombinator.com