While I do not host OwnCloud, I do selfhost a significant amount of other services and strongly believe it can offer a lot of value in certain areas (or stages of business/work). However, part of what I think makes it viable in the current era is how good VPN options like WireGuard and Nebula are, along with various solid open source firewall/gateway options (VyOS, OPNsense, roll with OpenBSD etc). I can't imagine actually exposing anything I selfhost on the open internet, the surface area and lack of security practices is scary and has been for ages. At least separate VLANs for everything and access only via VPN from external, or at all for that matter (internal VPN or hard wire required for any access whatsoever to management interfaces, sensitive equipment etc whether internal or not, no trusting local clients by default).
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.
zerotier and tailscale is very good at this. you can lock down everything and it wouldn't matter because you still can connect from anywhere with all the security you want at each places.
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
Considering you run already run these zerotier networks, I would assume you heard of it, but since I don't see it mentioned and you (for obvious reasons) don't like tailscale, have you heard/used headscale (the opensource implementation of the controller(hosted) for tailscale) ?
"Containerize everything", they said. "What could go wrong?"
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.
>The “graphapi” app relies on a third-party library that provides a URL. When this URL is accessed, it reveals the configuration details of the PHP environment (phpinfo).
>Delete the file owncloud/apps/graphapi/vendor/microsoft/microsoft-graph/tests/GetPhpInfo.php
Then perhaps you shouldn’t be doing that? Or if the position is that environment variables are suitable to hold secrets, the php folks should document the phpinfo function as a security risk and something that should not be available to unauthenticated users.
Not choosing is not an option, it leads to this ‘max severity score’ ‘vulnerability’.
phpinfo is like a very in-depth system info function for php. Its a debugging function, and shouldn't be in production code to begin with.
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.
Environmental variables have always been available to the environment. Thats the point. Saying dont use them to transmit info is like the hysteria of "dont use the clipboard because any app can access it." Well yeah, the point of the clipboard is ipc.
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 agree, but this affects far more than PHP. There are a LOT of projects that use environment variables for secret credentials, and it's especially scary because a number of tools love dumping environment variables.
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.
20 comments
[ 4.7 ms ] story [ 54.9 ms ] threadDoing 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.