Comment by scr4ve | Hacker News Reader

Comment by scr4ve | Hacker News Reader

Parent Full thread

I don't really get why one wants to trust ownCloud with private files:

- "logging changes": https://github.com/owncloud/core/commit/eea96298951805dfc6eb... vs https://owncloud.org/security/advisory/?id=oc-sa-2014-020

- ownCloud is a PHP application with quite a few third-party modules of varying quality. Looking at the security history of Wordpress, it's not hard to imagine what's going to happen.

- The maximum bug bounty for ownCloud is 500 USD. I think my data easily exceeds that.

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

To their credit, ownCloud openly publishes security advisories for every vulnerability, but I still think it's architecturally designed to fail. Exposing this to the internet is probably a bad idea. If you just need storage, you probably should just use dumb storage. If you need project management stuff and care about privacy, maybe look at https://protonet.info/ or something along those lines. Also https://www.boxcryptor.com is really nice - the Dropbox desktop client does proper cert pinning (ownCloud doesn't) at least.

Other than that, storage connected to a raspi via USB will probably yield rather bad transfer speeds?

So an open source product with active and transparent security patching with a bug bounty isn't good enough?

Yet you want to offer two closed-source alternatives. I am not defending Owncloud's record, I'm attacking your logic. A low-effort all-in-one groupware and private doc cloud (Google Apps replacement) is an awesome thing - if Owncloud could make deploying an email server as simple as the rest of its toolset, they will have hit the home run.

And sandstorm.io - still waiting on internal user stores.

> internal user stores

Can you please elaborate why this is a blocker for you since they offer email-based login?

The entire premise of self-hosting is SELF hosting. Internal network, no operational, day-to-day necessity for Internet connectivity post-install.

If I install such a product, it's because I want total control over my data and the terms by which I access it. Being forced to use Google/Github/email as auth goes against that.

His point is that a properly built proprietary product is better than a hacked together open source project.

Active and transparent patching does not improve the code quality.

How do you know a proprietary product is "properly built"?

Especially considering, unlike those proprietary products, our open source product and the engineers we pay to work on it are under constant and public scrutiny thanks to availability of the source.

Honestly, I think you should not even consider trusting a proprietary product with your most important private data. There's no guarantee it isn't full of back doors and you can't audit the code or pay somebody to do it - some companies would even sue you if you try (see the Oracle debacle some weeks ago).

I don't agree with him, I just understand his point. Actually, I wouldn't really trust either product at this point - there have been too many vulnerabilities in OwnCloud for my taste, but buying a proprietary application is not an alternative either for my personal use.

https://www.youtube.com/watch?v=iUMsPppwIH4&index=5&list=PLt... might bring some confidence. We hear from other security experts that we're considered an example in how we handle security.

If you're interested in something ownCloud-ish but with more security emphasis, you might like Sandstorm:

https://sandstorm.io

https://docs.sandstorm.io/en/latest/developing/security-prac...

(Disclosure: I'm the lead developer.)

Happy user here. Sandstorm works amazingly well.

Especially enjoy

- the usability of Sandstorm, -it just works.

- extensibility - you can adapt other apps, open source or commercial, to run on sandstorm. As far as I'm aware you can even upload them to the hosted version.

- security seems to be taken good care of by pragmatic and experienced people.

- the fact that I can pay a small amount monthly for it depending on my storage and computing needs, making sure incentives are aligned (although last time I checked I think Sandstorm hadn't even started the billing machine I think.)

Furthermore it seems to be completely, real, free software, -I ran the OS version at a maching at home for months before oasis became available to me, and I haven't noticed any juicy parts missing or filed under "Enterprise only". The only difference between the versions seems to be the storage and compute resources available. (OK, the billing system doesn't seem to be in the Open Source version, but that is OK to me. : )

Thanks for the kind words. :)

+1

Kenton, thanks for all of the work you and your contributors do on sandstorm.io; I have referred this project to many people wanting to get their feet wet "running a server" as a way to do something without instantly cutting yourself. Have you considered writing a how-to article on replicating ownCloud-like functionality within Sandstorm using apps? It might be a good first step, and I believe that it has the possibility to help people move onto (what I personally believe is) a superior platform.

Well, mostly I see ownCloud as the good guys, and my hope is to have it available as a Sandstorm app soon.

So I'd rather focus on replacing SaaS, like Google Docs/Drive. :) Here's a blog post about that:

https://opensource.com/life/15/12/5-open-source-web-apps-sel...

The biggest things I see ownCloud still having a huge advantage on is contacts and calendars, nobody's ported or written good apps for Sandstorm to do that yet.

There's an awesome file storage app called Davros though, that's actually compatible with the ownCloud desktop client for file syncing!

AFAIK sandstorm self hosting only works on 64bit x86 machines and there's certain files I don't want hosted outside my own walls. The various ARMs are great for that use case, any future plans on supporting ARM?

Otherwise sandstorm looks pretty great overall. I always appreciate a focus on security :)

The primary problem with supporting ARM is that Sandstorm apps run native binaries. So in order to support ARM, every single Sandstorm app would need to be able to also be recompiled for ARM, or you end up fragmenting the ecosystem.

I'm also not sure how many board PCs like a Raspberry Pi or what have you would handle Sandstorm well performance-wise, though I do think there's some 64-bit board PCs you can get now to try it on.

Curious, why the scripts to install a simple series of binaries? If you packaged it natively then all the stuff you're doing with both GPG and install.sh simplifies dramatically from 2k lines of bash. With added benefit of pushing out security updates or releases becomes pretty simple.

Bunch of reasons...

- There is sadly no universal package manager on Linux.

- A lot of that 2k-line bash script is implementing an interactive setup that configures your server, optionally claims a hostname and obtains SSL certificates, etc. A package manager wouldn't replace any of that.

- Sandstorm's auto-updater will automatically update your server within 24 hours of any release. That's actually pretty hard to achieve with package managers. Most are not designed to auto-run in a cron job. Worse, many distros have long release cycles (6 months, 2 years, etc.) during which they only accept bugfixes.

- Most package managers don't verify PGP signatures back to the upstream author, but rather to the distro maintainer (which in Debian's case is any one of thousands of people). It's debatable which is preferable, but note in any case that it's a very different property from what our installer implements.

- Sandstorm self-containerizes in its own corner of the filesystem, basically avoiding any dependency on the rest of your system other than the kernel. This strategy works well for us -- it relieves us from having to test on every distro separately, and it avoids messing up the user's system -- but it probably wouldn't meet the guidelines required to get a package into a distro. So we'd still have to distribute our packages direct from our own server, or do a _lot_ more work.

With all that said, when Sandstorm stabilizes more we do plan to figure out a way to let people "apt-get install sandstorm", since a lot of people are more comfortable with this.

Can I use sandstorm without having a Google or GitHub account?

EDIT: Thanks for the reply. Will check it out. And yes, I last gave it a try a while ago.

There's an email option as well. Check the demo, then choose "Create Account" - you'll see "with email" as an option, including an email field.

Yes, of course.

(It sounds like you might have tried a very early version a year or more ago... lots has changed since then.)

Your project looks really exciting! I'd love to run it on my home server, any plans for supporting 32 bit servers?

Unfortunately probably not any time soon, for the same reason as ARM: Sandstorm app packages include binaries built for x86-64. We'll need a lot of tooling to make it easy for developers to package for multiple architectures. :/

How well does this work with mobile? Are there mobile apps. I couldn't tell just clicking around.

Sandstorm works decently on mobile browsers, they do test it. But how well different Sandstorm apps work on mobile depends on those apps.

It's also possible to use native apps that sync to Sandstorm. My Tiny Tiny RSS instance on Sandstorm I can access through a native Android app, for instance.

Oh, ok. I'll probably try and spin up a container or vm and install it and play around. Thanks!

Unclear from the page, would it support SFTP, SMB protocols?

At present, apps can implement HTTP and WebDAV APIs but not SFTP nor SMB. In the future we plan to generalize things so that apps could potentially implement any protocol, but we want to be careful to do it in a way that lets us keep our strong security guarantees.

> logging changes

"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

What makes you thinl they are more secure? Note that most of the vulnerabilities within ownCloud are found internally: https://statuscode.ch/2015/09/ownCloud-security-development-...

We could easily never have published any information as do a lot of other projects and companies.

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

[1] https://owncloud.org/blog/owncloud-and-php/ [2] https://events.ccc.de/congress/2005/fahrplan/attachments/542...

When was there a single very grave vulnerability within the core of Wordpress?

The list is current and very extensive:

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

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.

There are still 4 CVEs there with CVSS score > 7.0.

There's really no reason to discount bugs based on having score < 7 though, it's a very rough measure and as you say not very reliable.

> I don't really get why one wants to trust ownCloud with private files

Because

1. You get to host and control the data, and have 100% access to the code managing that data. You don't have to trust anyone else for anything.

2. The chances of somebody attacking you (a small target) vs somebody attacking a big centralized service is fairly small.

I'm not saying I believe Owncloud to be 100% secure (it being a semi-shoddy PHP application and all), but there are reasons someone may want to trust it over centralized, US-hosted and NSA-friendly online services.

No. 2 is not right. For fingerprintable service with known exploits, dragnet type attacks are very common. If the GP is right about OwnCloud having a poorly written code base then you have a very high chance of getting hacked unless you can stay on top of updates, which is unlikely for most people.

If your data is important enough that it needs to stay on self hosted machine, you should look at commercial solutions. Otherwise use dropbox/gdrive/s3 with self encrypted files.

But why would it be shoddy? We put a lot of effort in security and have a lot of people working on our code, with good automated testing and clear processes. See https://owncloud.org/security/ and https://doc.owncloud.org/server/9.0/developer_manual/general...

We're a large project (often an order of magnitude larger than others trying something similar) and a company behind it with many large enterprise customers, which explains of course why we have good, transparent processes and dedicated security people.

None of that has to lead to good code as a rule, I admit that. And there sure is lots of less than perfect code in ownCloud. But I don't think it is fair to just claim it is any more shoddy than any competitor without any evidence of that.

I am not claiming that owncloud is shoddy, I am just refuting the claim that somehow hosting your own server makes you a smaller target and somehow safer. Every code base eventually has security problems, sometime a big as heartbleed. If you are Amazon, you get a preferential disclosure and patches before it is publicly revealed. If you are John Doe, you better hope that you read the cve as soon as it's published and that you can patch the server right then.

That is why we publish updates with fixes 2 weeks before we publish CVE's. If a would-be-hacker follows CVE's, all users who updated in the last 2 weeks are safe.

On top of that, while we prepare updates mostly in public in github we only release the security-related fixes the moment we release the update.

So a would-be-hacker would have to look through the source code of the update to identify security fixes, and then he/she can hack ownCloud instances. (Lukas should check this, btw, I'm only 75% sure about this)

There is nothing we, or anybody working on any product can do about users not updating, though we do give warnings, offer packages which makes updating easier and do all we can to use security hardening to limit the damage security problems can do.

It is true that hosting your own server doesn't make you safer from targeted attacks. If you follow our security recommendations, you'll be quite OK, though, and there are tricks like using a special port and port knocking and what-not to improve security even more.

But this is no different to any other self-hosting tech.

Yeah, a public cloud can do better - they don't publish any source. They also have, almost by default, a back door to the NSA so that's like saying "let's give up on trying to build a roof because if you do, it could have a leak".

BTW if your ownCloud just presents a login screen to others, I mean, how often can somebody break in through that with automated means? Not 'never' I suppose but it should be rare...

Owncloud wrote this blog some time back:

> https://owncloud.org/blog/owncloud-and-php/

The discussions there around a "low barrier for entry" being a major goal of the project is, in my view, opposed to high levels of security.

Edit: This quote showcases my point:

    “nobody will dig into a complex build system for a week

before they send their first patch,”

At the very least, yes, it makes it a lot harder.

But, for many users, security is complicated and us making it easy to run ownCloud includes that. You won't find many competitors with such extensive documentation, nor automatic security setup tips and warnings in the ownCloud admin interface.

Second, this is a matter of focus. For home and small server users, ease of use trumps perfect security, that is a simple risk model assumption: your security has to be good enough, not perfect. Better than others and all that.

For enterprise users, however, security IS paramount and ownCloud lends itself for that. We get security audits by the financial institutions and others which run ownCloud and have extensive security hardening and best practices in place. Of course, these enterprise users don't use the many 'random' community apps, which is where the vast majority of security issues can be expected. I think that, for enterprise usage, you'll find that ownCloud security practice belongs to the best. And that is in no small part thanks to the awesome that is Lukas Reschke.

For home and small server users, ease of use trumps perfect security, that is a simple risk model assumption: your security has to be good enough, not perfect. Better than others and all that.

As someone else points out in a neighbouring thread, OwnCloud is generally less secure than any of the large services, because of automated vulnerability scanning. If an OwnCloud user updates their server days or even hours to late, it can be game over and your data is on the street. It does not matter if the attacked service is OwnCloud or some other service with enough privileges.

This does not mean that open source and/or decentralized services are at a disadvantage, but you have to make the right security choices. The storage service[1] should never see unencrypted data - encryption at rest is not good enough. For instance, Bittorrent Sync provides this with their encrypted read-only keys. A cloud peer with such a key never sees unencrypted folder data. The only thing you lose when a cloud peer is hacked is a node in the swarm, but it'll never result in visibility of plain-text (unless you subvert AES-128). One SyncThing developer is currently also working on similar functionality for SyncThing.

For this reason, I would never recommend OwnCloud to anyone outside a large company that has the capacity to do continuous security auditing and monitoring, unless you apply client-side encryption (but then you could use Dropbox et al. as well if privacy is the primary consideration).

[1] I know that OwnCloud does more than just storage.

Self hosting does have this issue in general, yes. It is a bit harder to get at security vulnerabilities in ownCloud as was initially portrayed in the thread you mention (we publish CVE's 2 weeks after updates have hit the net, and these updates contain unmarked security updates).

Client side encryption is a great solution but you lose out on most of the benefits of the cloud.

Honestly, I don't know. I haven't seen any of such attacks but of course, with about 3 million users, ownCloud isn't a HUGE target. I just don't like the idea of giving up on self hosting ;-)

I also wonder how successful such automated scanning attacks are against a simple login screen. Esp compared with the fact that on the big services people routinely call the helpdesk and manage to get passwords reset and all that so they get into accounts. That won't happen with your private ownCloud...

With regards to 'usability first' vs 'security first' approaches, this is what 'security first' gets you: https://twitter.com/davide_paltri/status/676696685456826368

I rest my case ;-)

Reply on news.ycombinator.com