Disclosure of sensitive credentials and configuration in containerized deployments - ownCloud
Disclosure of sensitive credentials and configuration in containerized deployments - ownCloud
Note that Docker-Containers from before February 2023 are not vulnerable to the credential disclosure.
I haven't seen this posted yet here, but anybody self-hosting OwnCloud in a containerized environment may be exposing sensitive environment variables to the public internet. There may be other implications as well.
OwnCloud? More like PwnCloud
Nextcloud is the right answer
Any tips for speeding it up? Loading can be painfully slow at times. I was reading that it may be the database (I use MariaDB which in theory shouldn't limit it with 32gb RAM and an R7 1700x).
Is MariaDB on spinning disk or ssd?
I initially set up Nextcloud with MariaDB on spinning disk but it was slow even completely empty. I moved that container to ssd & performance was a lot better. The web UI may still have some slow loading parts but I can't say for sure since rarely use it. Caldav+carddav+Nextcloud client are how I usually interact with it.
Implement redis. Like shown here: ( you can ignore most stuff there) https://github.com/nextcloud/all-in-one/blob/main/manual-install/latest.yml
That's way exposing your home services to the internet is a bad idea. Accessing it through a secure tunnel is the way to go.
Also, they already "fixed" the docker image with an update, something todo with phpinfo...
Nobody cares about your home services unless they can use them to send spam or mine bitcoin. Owncloud is a funny name because it seems to imply it's for personal use: your own cloud. I didn't know until I found myself in one, but apparently a lot of schools use Owncloud.
phpinfo is just a bad idea. It's a built in facility that dumps everything without knowing whether it's sensitive or not, right into the current page, making it trivial to add this vulnerability to your own application or library that an unsuspecting developer will include into their application. There's not even a single security warning in the documentation. Here's practically the same problem from 21 years ago: https://nvd.nist.gov/vuln/detail/CVE-2002-1725
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:
Fewer Letters More Letters IP Internet Protocol NAT Network Address Translation VPN Virtual Private Network VPS Virtual Private Server (opposed to shared hosting) k8s Kubernetes container management package
5 acronyms in this thread; the most compressed thread commented on today has 11 acronyms.
[Thread #330 for this sub, first seen 3rd Dec 2023, 04:05] [FAQ] [Full list] [Contact] [Source code]
New Lemmy Post: Disclosure of sensitive credentials and configuration in containerized deployments - ownCloud (https://lemmy.world/post/9020812)
Tagging: #SelfHosted(Replying in the OP of this thread (NOT THIS BOT!) will appear as a comment in the lemmy discussion.)
I am a FOSS bot. Check my README: https://github.com/db0/lemmy-tagginator/blob/main/README.md
Remove this bot already
"Docker is safer" sure.
The only thing that makes this case worse in docker is that more info is in ENV variables. The vulnerability has nothing to do with containers though, and using ENV variables to provide sensitive data is in general a bad decision, since they can be leaked to any process with /proc access.
Unfortunately, ENV is still a common way which people use to pass data to applications inside containers, but it is not in any way a requirement imposed by the tech.
I'm using Kubernetes and many of the apps that I use require environment variables to pass secrets. Another option is the pod definition, which is viewable by anybody with read privileges to K8s. Secrets are great to secure it on the K8s side, but the application either needs to read the secret from a file or you build your own helm chart with a shell front end to create app config files on the fly. I'm sure there are other options, but there's no "one size fits all" type solution.
The real issue here is that the app is happy to expose it's environment variables with no consideration given to the fact that it may contain data that can be misused by bad actors. It's security 101 to not expose any more than the user needs to see which is why stack dumps are disabled on production implementations.
If you do it right, possibly.