OwnCloud vulnerability with max severity score comes under "mass" exploitation
arstechnica.com
arstechnica.com
Doing that itself certainly isn't perfect, obviously if facing actual targeted APTs horizontal movement efforts can be expected. But running a service with any kind of public exposure is pretty different in terms of threat profile and the sheer volume of attacks one can expect. Even with something really simple, some minimal static page serving, I'd still want it somewhere completely on a different network from my main stuff. Let alone huge gigantic complex many moving part apps like these cloud options! Individuals or small teams need to manage their available time/resources pretty tightly, and even a huge team would have trouble locking down something like that.
i run multiple zerotier networks at different levels and they all work transparently.
i dont like tailscale as the hosted platform wants you to use an oath login and i have had bitter experiences with it so zerotier it is.
zerotier does not have a public gateway option where you can have a network only access the internet via a certain point (maybe it can be done but it isnt easy as tailscale) but i am happy with it.
i also do not have to worry about VPNs and all that because zerotier does that for me.
you can self host both so you are in control at all times
i know we can self host zerotier and headscale but i feel like i am invested in the zerotier network and i don't want to try another thing.
Seriously, how could anyone, ever, think that putting any sensitive information like credentials in to your environment is fine? That's just so incredibly ridiculous.
They have to be somewhere the app can read them, which means if the app can be persuaded to reveal them they are readable.
You probably should have extra restrictions on how those credentials are used (e.g. your database server should only accept connections from known IPs) or minimise the number (e.g. with a small install run the database and app on the same machine and accept only local connections).
This is probably the crux of the issue. Environment variables are available on most systems where you might want to run software, containers included. For lots of configuration, they seemed to make sense: https://12factor.net/config
Of course, most container solutions (Docker, Kubernetes, Nomad) nowadays include solutions for managing secrets better, as do most cloud platforms, but they're not exactly as standardized or simple as environment variables are, maybe like a file mounted inside of the container that the app can read, at best.
That said, I'm not excusing the fact that the vulnerability is caused by a package that lets you run phpinfo, since that does leak a lot of information - it's more like you need to be careful every step of the way, both with how you store and access your secrets, as well what you include with your code.
>Delete the file owncloud/apps/graphapi/vendor/microsoft/microsoft-graph/tests/GetPhpInfo.php
Imagine deploying tests in production.
Not choosing is not an option, it leads to this ‘max severity score’ ‘vulnerability’.
The issue i see being exploited is that the owncloud codebase contains this function, and its in the unit/integration tests, which shouldnt be in production code (or should be inaccessible at least).
That all being said, the real issue here is that there are sysadmins and devops people who are deploying php.ini configurations to production that allow the use of phpinfo (and probably other functions too), by not explicitly denying those functions, which is totally something the php configuration supports, and is absolutely something that should be done, as there are a number of unsafe php functions.
https://www.php.net/manual/en/ini.core.php#ini.disable-funct...
If the environment is safe, don’t expose it, functions that expose it are unsafe and should be documented as unsafe and unavailable in production.
If the functions are normal, the environment is unsafe, don’t store secrets there.
You have to make a choice, it can’t be half of both. That is the real issue.
But to your point docker secrets are a thing and have been available for a while. And a publicly exposed phpinfo has been a severe dataleak since before time began.
Neither of these are unknown or new. They're just an unfortunate composite enabled by containers.
I'd much prefer pulling credentials from a file or pulling down credentials based on properties that the application is oblivious to. There's risks to using files too, but in my experience, environment variables are used a bit more carelessly.