 |
This has been assigned CVE-2017-14610. |
|
|
This is a security issue with CVE-2017-14610 Can this bug be closed? I think this is fixed in all current versions of bareos, right? |
|
|
Seems like this issue is NOT resolved yet. Version 20.0.2 is still affected. Any ETA we can expect for a fix? Thanks! |
|
|
mschiff actual daily is showing correct rights for pid file here bareos-fd daemon. ``` ls -lah /var/lib/bareos/bareos-fd.9102.pid -rw-r-----. 1 root bareos 5 Sep 14 04:19 /var/lib/bareos/bareos-fd.9102.pid ``` Also all systemd platforms got new services so there's no more script in use. |
|
|
of course using bareos-dir you got a ```-rw-r----- 1 bareos bareos 6 Sep 14 14:14 bareos-dir.9101.pid``` which can be exploited as described by a bareos user But as stated before, with systemd control you could put whatever even 1 in this file, systemd will react correctly and use its own pid knowledge. |
|
|
OK, this may be a possible workaround for systems using systemd. But other systems are still affected. So do you have any ETA when we can expect a security-fix? Thanks! |
|
|
There is no easy way to fix this, as the current implementation requires us to parse the configuration to determine the name and location of the PID file. As the configuration should be read with limited privileges, we need to drop privileges first. Having said that, we will replace the current mechanism in Bareos 21, but I don't think there will be a real fix for the existing versions. We're investigating if we can at least provide a reasonable workaround though. While this is a real issue, it is effectively limited to the director and the storage daemon. The file daemon usually runs as root and as such the pid-file gets also written as root. Also, I have objections when it comes to the CVE's risk assessment. The CVSS that has been set declares it is affecting Confidentiality, Integrity and Availability. While I agree that killing the wrong PID may affect availability, it should not affect confidentiality and integrity and if it does that should be a CVE for the program that has been killed. Also, as there are no measures in place that will automatically stop or restart the daemons without user interaction, the attack vector will in fact require user interaction. Last but not least you must be able to act as user "bareos", which is considered as "High Privilege". So my CVSS assessment is CVSS:3.1/AV:L/AC:L/PR:H/UI:R/S:U/C:N/I:N/A:H which results in 4.2 (moderate) and not 7.8 (high) as in the original report. If you take a closer look at the availability scores in CVSS, this probably wouldn't even count as an availability issue, as that would require Bareos is being disrupted, while the attack vector is disrupting any other service (but I'm not claiming that). |
|
|
I just spent half an hour typing up an in-depth response that was met with an "APPLICATION ERROR #2800 Invalid form security token", so you'll have to excuse my brevity. The security risk is indeed minor (I didn't make up the rating). The remaining difficulty stems from using the same file for two separate purposes that have different security requirements. MIMEDefang had the same issue and fixed it in v2.81 by separating the PID and lock files. To fix it: 1. Use separate PID and lock files. 2. Make the PID file a command-line only argument, and create it as root. Only the init system cares about it, and it's sensitive. 3. Create the lockfile as the "bareos" user. Only Bareos cares about it, and it's not sensitive. |
|
|
Thank you for the quick response and sorry for the application error - the timeout for the CSRF-token in Mantis is a bit short if you're writing something more in-depth. We already have PR#928 where we started to do the PID as a command-line only argument. We had not yet considered the splitting of PID and lock file, so thank you for bringing this up. I'll take a look at what you did in MIMEDefang v2.81 to see if we can do it like that in Bareos. As you're the reporter of the issue: do you have any idea who we need to contact to update the CVE when we have a fix/workaround in place? |
|
|
In Gentoo we now use a workaround in the packages: systemd an openrc do not rely on or use the pid file anymore. When considering split of pid and lock file: Please also consider, that the directory where files will be written also have to be different or the run directory needs group write permissions and must be group-owned by bareos... Good to see progess here, thank you! |
|
|
Depending on the information you want to update, there's either a web form (MITRE, cveform.mitre.org) or email address (NVD, nvd@nist.gov) that handles it: https://cve.mitre.org/cve/update_cve_records.html The CVE information is synchronized to NVD automatically, but NVD contains additional information like the "high" vulnerability score that can't be fixed with a CVE update. |
|
|
We finally have resolved this issue in Bareos 21. The previous handling has been completely revised. As the PID file is not required anymore, we don't create one by default. If you still want one, you can have it by passing "-p" and a path to the daemon. Pid files created will be created before dropping privileges. |
- Anonymous
