[obnauticus]

I originally wanted to do this but the CVE history is a bit too colorful for something I’d want to trust as a “cloud replacement”:

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=nextcloud

A common misconception IMO is that running and owning your own infrastructure is somehow more secure. To that I lol, and I’m confident that the thousands of AWS/GCP/Azure/iCloud security engineers are all doing a more thorough job than you can. At the very very least they receive embargoed bugs which they often mitigate before the general public.

[bravetraveler]

One doesn't have to expose it to malicious actors. It is most-useful that way, sure. Mine is at 10.27.0.68. Have fun, hackers!

Also, I lol at most CVEs. Butterfly farted outside, oh uh.

Take the top one: In Nextcloud Desktop Client 3.13.1 through 3.13.3 on Linux, synchronized files (between the server and client) may become world writable or world readable. This is fixed in 3.13.4.

You mean to tell me a few minor point releases imitated umask, making world-readable [and possibly added writable]? Oh no! The tragedy! Keep in mind most clients are single user systems anyway.

Judge them on their facts, there are vulns and then there are vulns. CVEs are a sign of attention on a project. No more or less.

[uselpa]

I find that one concerning in an enterprise setup (which they target). Or the fact that the desktop client has 999 open issues. Or that the last version silently takes you off the stable channel. I could go on … Nextcloud desktop has severe quality control issues.

[laymansterms]

Yeah, one CVE is literally "You can use the MacOS variant of LD_PRELOAD on the client to hook libc calls! Oh no!!" This is a bogus CVE; any application can perform arbitrary actions when its system calls are hooked, but it requires such a strong threat model that the adversary realistically gains no ground by doing so.

("A code injection in Nextcloud Desktop Client for macOS allowed to load arbitrary code when starting the client with DYLD_INSERT_LIBRARIES set in the enviroment")

[MrDresden]

Your right of course. No way an individual can compete with an army of specialists.

But for some of us it is a bit of a hobby to run our own infrastructure. And some of it only ever runs on a private network.

I rolled my own docker setup for Nextcloud a few years ago, and couldn't be happier with the outcome. It does require me to log in and update the system and setup from time to time, but that's just a good time to drink a hot bevarage and listen to podcasts in my mind.

For anyone hosting their own instance, Nextcloud offers this scan[0] of your public facing url which might come up with something worth fixing.

[0] https://scan.nextcloud.com/

[zigzag312]

> I’m confident that the thousands of AWS/GCP/Azure/iCloud security engineers are all doing a more thorough job than you can

I'm not so confident about that:

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=azure

It really depends on what you self-host.

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=syncthing

"Do everything" solutions go against the principle of minimizing the attack surface.

EDIT: More is not always better in security. With more people doing more things, the statistical odds of miscommunication and misconfiguration increases.

[notepad0x90]

I would dig a bit more into the breakdown of the CVEs:

https://www.cvedetails.com/product/34622/Nextcloud-Nextcloud...

As well as if this reflects a systemic issue with the codebase or if it is just getting much needed attention from security researchers. More CVEs can just mean they're cleaning up after vulns really well. But at the same time, if they have critical vulns over and over again, that might indicate bad coding practices or carelessness.

[n_plus_1_acc]

Nextcloud is well known for it shitty legacy PHP codebase.

[obnauticus]

Agreed. The breakdown is indeed pretty poor IIRC.

Generally you use these disclosures to make directional decisions about infrastructure. The list of fixed and disclosed CVEs combined with the legacy PHP code base doesn’t really pass the security sniff test. You really wouldn’t know for sure without doing a full code audit.

[ReptileMan]

>A common misconception IMO is that running and owning your own infrastructure is somehow more secure.

If done properly cve-s don't matter that much. You create a headscale install on a pi and the headscale port and your router's ssh (key only) are the only things visible from the outside. Take any other than a home router - aka something with support. And you are done.

[hypeatei]

> If done properly cve-s don't matter that much.

I think it depends on the CVEs and where they are. If it's a software vuln that requires root or some other complex prerequisites then w/e. But, if we're talking about low level problems in either the OS or network layer (e.g. firewalls, routers) then big clouds are most likely going to have that patched and rolled out more quickly IMO.

[Jnr]

Or go with Wireguard. It uses UDP, it has a silent protocol, no one from the outside can see it. (unless they can MITM you)

[Timber-6539]

> thousands of AWS/GCP/Azure/iCloud security engineers are all doing a more thorough job than you

All these cloud services are just attack surfaces with a huge target on their backs. And the security engineers slip up too [0], in the case of Microsoft it's become more of a meme now. The North Korean hackers basically own them.

[0] https://www.techspot.com/news/102573-microsoft-left-server-c...

[obnauticus]

Somewhat depends on your threat model. The relative value of an iCloud/aws/gDrive 0day is going to be higher than Nextcloud. If you’re in the category of people concerned about this type of breach, self-hosting a PHP web app and claiming it’s somehow safer wont save you either. For this risky population, neither solution works since attackers are willing to throw expensive exploits at your data in either scenario.

If you aren’t being specifically targeted, then you would care about low hanging fruits discovered by something like automated scanning. Not exposing your service to the internet does solve this assuming you’re confident in the stack which provides this isolation. But managing this stack and performing risk calculus here is actually where the security horse trading happens. I think most people aren’t safer managing this themselves — arguably they’re actually worse off.

I have high standards for the confidentiality of my data. I care about things like lateral movement and the massive attack surface that isolation tech to prevent such movement has. I also won’t design monitoring and alerting, ensure a patch state, or perform code audits on Nextcloud and all the isolation tech required to secure it to a comporable level of security. Because of this, I instead reason around the cost of exploitation. I want it to be higher than what I believe Nextcloud provides and I’d rather require an attacker to use an expensive 0day to extract my data off a cloud provider like Google versus a potentially cheap one against my own infra.

[izacus]

Those cloud specialists aren't configuring your ACLs and firewalls - the most common source of severe security problems in the cloud.

[hypeatei]

Yes, there is a concept of "shared responsibility" in the cloud. Obviously the provider is going to handle some things and you have to take care of others.

[MaxBarraclough]

I'm not a security specialist, but it seems to me that while managed services typically have better security and sysadmin resourcing, they also have the downside that their security can fail at a massive scale. If someone defeated the security of, say, GitHub, they could leak all the private repos stored there.

Managed services also have to accept connections from the public Internet, which on-premises solutions do not.

[akdev1l]

> If someone defeated the security of, say, GitHub, they could leak all the private repos stored there.

In theory you are correct but this is like saying keeping your money under your mattress is safer than a bank.

Yes, in theory someone can still all the money at a bank but the bank is infinitely more qualified/competent to not get robbed than you would be.

[bpfrh]

Running and owning your own infrastructure exposed to the outside world can be more insecure, running your own infrastructure at home in segmented networks with wireguard will solve most problems.

[exe34]

I think the threat model isn't that these popular services are going to be attacked, but that they will engage in the denial of service themselves without legal recourse.

[protocolture]

Secure from who I guess.

Like sure, someone particularly interested in your home nextcloud instance could probably find their way in eventually.

But if you are concerned more about dropbox killing your account due to nonpayment, cloud backups getting encrypted and the master key being lost, cloud engineers snooping on your files, cloud platforms targeting ads based on your downloaded files etc etc etc it offers an alternative.

[CodeCompost]

It's written in PHP, the most insecure web language on the planet.

[touggourt]

This is a very very old opinion, and not true for years.

[klaussilveira]

What, in your opinion, makes PHP less secure than Python or JavaScript?