Closed haarp closed 1 year ago
It's been answered before but some pieces are harder to find than others...
The situation is gradually improving, but we are still a couple of years away from any sort of significant change to that overall situation.
I think that 22.7.1 finally phased in restricted access for /root directory which had been a FreeBSD oversight until version 13 came out, but needed a bit more prepping on our end.
Cheers, Franco
Thanks for the information, @fichtner. Sounds like a tough situation.
Since PHP still runs root most attempts to protect files is in vain in case of a security breach.
Isn't this easily solved by not giving users any GUI privileges? And an attacker exploiting a vuln in a daemon (e.g. unbound) will still be constrained to the daemon's user (but will gain access to config.xml
)
The only legit way to get file content is shell access which should not be given to non-administrators for that particular reason.
The compromised daemon scenario also applies here. An attacker taking over a running process can potentially have it read arbitrary files it has fs perms to.
Isn't this easily solved by not giving users any GUI privileges?
No. PHP code requires root rights to configure the system no matter how little the user might be able to do in the GUI. There is no full abstraction and thus it's creating the problem as is.
Also PHP loads the config.xml for even the most restrictive user so find the exploit find the data even if protected...
Permission of config.xml can be adjusted if (2) is addressed. Won't help much because of the above.
Cheers, Franco
This issue has been automatically timed-out (after 180 days of inactivity).
For more information about the policies for this repository, please read https://github.com/opnsense/core/blob/master/CONTRIBUTING.md for further details.
If someone wants to step up and work on this issue, just let us know, so we can reopen the issue and assign an owner to it.
For completeness sake, Logcial Trust also mentioned this in their recent Security Assessment
Important notices
Before you add a new report, we ask you kindly to acknowledge the following:
Describe the bug
Hello,
File permissions on my boxes are very random. Some sensitive files are world-readable, while less sensitive ones aren't. Or only sometimes. It's all very inconsistent.
If there are users besides admins on the box, they'll be able to read these. Likewise, if there's a vulnerability in a system daemon, the compromised daemon might also easily access them.
Here are some examples I noticed:
/conf/
``` # ls -la /conf total 3208 drwxr-xr-x 4 root wheel 512 Sep 22 00:00 . drwxr-xr-x 21 root wheel 1024 Sep 20 00:33 .. drwxr-xr-x 2 root wheel 4096 Sep 25 18:42 backup -rw-r--r-- 1 root wheel 72669 Sep 25 18:42 config.xml -rw-r----- 1 root wheel 16 Sep 20 00:32 dhcp6c_duid -rw-r----- 1 root wheel 1188 Sep 26 00:00 dhcpleases.tgz -rw-r----- 1 root wheel 40 Sep 25 18:42 event_config_changed.json -rw-r--r-- 1 root wheel 193 Sep 26 00:00 netflow.tgz -rw-r--r-- 1 root wheel 3118009 Sep 26 00:00 rrd.tgz drwxr-xr-x 2 root wheel 512 Sep 19 19:53 sshd ```
config.xml
is the most glaring offender here. Among other things, it contains passwords (e.g. for PPPoE connections) and private keys (Wireguard). They're merely base64-encoded.Curiously, less sensitive files like DHCP leases are actually not world-readable.
And yes,
/conf/
itself is also-rw-r--r--
./conf/backup/
``` # ls -l /conf/backup/ total 6940 ... -rw-r--r-- 1 root wheel 68528 Sep 24 18:45 config-1664037914.2469.xml -rw-r--r-- 1 root wheel 68528 Sep 24 18:45 config-1664037937.8241.xml -rw-r--r-- 1 root wheel 68528 Sep 24 18:46 config-1664037962.2448.xml -rw-r--r-- 1 root wheel 68528 Sep 24 18:46 config-1664037991.7203.xml -rw-r----- 1 root wheel 68554 Sep 24 21:42 config-1664048568.2761.xml -rw-r--r-- 1 root wheel 68578 Sep 24 21:43 config-1664048598.6686.xml -rw-r--r-- 1 root wheel 68539 Sep 24 21:43 config-1664048614.8054.xml -rw-r----- 1 root wheel 68541 Sep 24 21:43 config-1664048622.5233.xml -rw-r----- 1 root wheel 68557 Sep 25 00:07 config-1664057261.2542.xml -rw-r----- 1 root wheel 68576 Sep 25 00:07 config-1664057277.9778.xml -rw-r----- 1 root wheel 68591 Sep 25 00:08 config-1664057296.3447.xml -rw-r----- 1 root wheel 68607 Sep 25 00:08 config-1664057316.1442.xml -rw-r--r-- 1 root wheel 68585 Sep 25 00:10 config-1664057456.9764.xml -rw-r--r-- 1 root wheel 68585 Sep 25 00:11 config-1664057490.4406.xml -rw-r--r-- 1 root wheel 68588 Sep 25 00:11 config-1664057504.5839.xml -rw-r--r-- 1 root wheel 68584 Sep 25 00:12 config-1664057523.7194.xml -rw-r--r-- 1 root wheel 68585 Sep 25 00:12 config-1664057544.9892.xml -rw-r----- 1 root wheel 68586 Sep 25 00:12 config-1664057578.5212.xml -rw-r----- 1 root wheel 68571 Sep 25 00:13 config-1664057587.2883.xml -rw-r----- 1 root wheel 68555 Sep 25 00:13 config-1664057595.2089.xml -rw-r--r-- 1 root wheel 68503 Sep 25 00:55 config-1664060159.0759.xml -rw-r--r-- 1 root wheel 68507 Sep 25 00:56 config-1664060189.2357.xml -rw-r--r-- 1 root wheel 68544 Sep 25 00:56 config-1664060205.9514.xml -rw-r--r-- 1 root wheel 68564 Sep 25 00:57 config-1664060256.1142.xml -rw-r--r-- 1 root wheel 68592 Sep 25 00:57 config-1664060257.819.xml ```
It's nice to have these config backups. But world-readable again. And why aren't all of them? Are there different backup mechanisms at work? In different envrionments, with different umasks?
/var/dhcpd/var/db/
``` # ls -la /var/dhcpd/var/db/ total 24 drwxr-xr-x 2 dhcpd dhcpd 512 Sep 25 15:21 . drwxr-xr-x 4 dhcpd dhcpd 512 Sep 19 19:53 .. -rw-r--r-- 1 dhcpd dhcpd 2494 Sep 25 15:27 dhcpd.leases -rw-r--r-- 1 root dhcpd 1987 Sep 25 15:21 dhcpd.leases~ -rw-r--r-- 1 dhcpd dhcpd 595 Sep 25 15:21 dhcpd6.leases -rw-r----- 1 dhcpd dhcpd 534 Sep 25 15:21 dhcpd6.leases~ ```
Assuming DHCP leases are sensitive (they're non-world-readable in
/conf/
), then they should be here aswell. But these files are world-readable. Onlydhcpd6.leases~
isn't (?). Even weirder,dhcpd6.leases
has also becomerw-r-----
since making this dump.Others:
To Reproduce
Navigate around the filesystem of a OPNsense install that has been running for a bit
Expected behavior
Sensitive files need to be consistently identified and be made accessible only to admin users and the daemons who need them.
Describe alternatives you considered
There isn't really an alternative to reducing attack surface.
Screenshots
--
Relevant log files
--
Additional context
It looks like
umask
is not consistently applied when files are created or rotated or backuped.Environment
Software version used and hardware type if relevant, e.g.:
OPNsense 22.7.4 (amd64, OpenSSL).
Thanks! :)