View Issue Details

IDProjectCategoryView StatusLast Update
0000847bareos-coreGeneralpublic2021-12-21 14:02
Reportermjo Assigned Toarogge  
Status closedResolutionfixed 
Product Version13.2.4 
Fixed in Version21.0.0 
Summary0000847: Bareos should create its PID files before dropping privileges
Description(I actually tested this on the ancient 13.2.4, but I reviewed the source on Github to make sure that the report is still relevant.)

== Summary ==

The bareos daemons should create their PID files before dropping
privileges. This represents a minor security issue; additional factors
are needed to make it exploitable.

Daemons affected:

  * bareos-dir (src/dird/dird.c)
  * bareos-fd (src/filed/filed.c)
  * bareos-sd (src/stored/stored.c)

== Details ==

The purpose of the PID file is to hold the PID of the running daemon,
so that later it can be stopped, restarted, or otherwise signalled
(many daemons reload their configurations in response to a SIGHUP).
To fulfil that purpose, the contents of the PID file need to be
trustworthy. If the PID file is writable by a non-root user, then he
can replace its contents with the PID of a root process. Afterwards,
any attempt to signal the PID contained in the PID file will instead
signal a root process chosen by the non-root user (a vulnerability).

This is commonly exploitable through init scripts that are run as root and
which blindly trust the contents of their PID files. One of the
scripts included with bareos, scripts/bareos-ctl-funcs, makes the same
assumption (although I'm not sure if it's supposed to be run as root):

  pid=`head -n 1 ${PIDDIR}/$base.$`

== Exploitation ==

There is only a risk of exploitation when some other user relies on
the data in the PID file. However, the point of the PID file is to
provide a daemon's PID to other users (mainly root). Therefore any use
of the PID file is suspect.

An example of a problematic scenario involving an init script would be,

1. I run "/etc/init.d/bareos-dir start" to start the daemon.

2. bareos-dir drops to the "bareos" user.

3. bareos-dir writes its PID file, now owned by the "bareos" user.

4. Someone compromises the daemon.

5. The attacker is generally limited in what he can do because the
   daemon doesn't run as root. However, he can write "1" into the
   PID file, and he does.

6. I run "/etc/init.d/bareos-dir stop" to stop the daemon while I investigate
   the weird behavior resulting from the hack.

7. The machine reboots, because I killed PID 1 (this is normally restricted
   to root).

== Resolution ==

The most straightforward way to avoid the problem is to create the PID files as root, before dropping privileges. This does cause one annoyance: you can't remove the PID file after you've dropped privileges. However, that's relatively easy for the init system to handle.
TagsNo tags attached.


related to 0001289 closedarogge Release Bareos 21.0.0 




2017-09-20 22:17

reporter   ~0002741

This has been assigned CVE-2017-14610.


2021-08-22 10:58

reporter   ~0004215

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?


2021-09-06 12:22

reporter   ~0004250

Seems like this issue is NOT resolved yet. Version 20.0.2 is still affected.

Any ETA we can expect for a fix?



2021-09-14 13:53

manager   ~0004264

mschiff actual daily is showing correct rights for pid file here bareos-fd daemon.

ls -lah /var/lib/bareos/
-rw-r-----. 1 root bareos 5 Sep 14 04:19 /var/lib/bareos/

Also all systemd platforms got new services so there's no more script in use.


2021-09-14 14:21

manager   ~0004265

of course using bareos-dir you got a
```-rw-r----- 1 bareos bareos 6 Sep 14 14:14```
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.


2021-09-15 10:22

reporter   ~0004266

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?



2021-09-21 16:14

manager   ~0004271

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).


2021-09-22 01:19

reporter   ~0004272

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.


2021-09-22 10:53

manager   ~0004273

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?


2021-09-22 13:42

reporter   ~0004274

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!


2021-09-22 14:52

reporter   ~0004275

Depending on the information you want to update, there's either a web form (MITRE, or email address (NVD, that handles it:

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.


2021-12-21 14:02

manager   ~0004396

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.

Issue History

Date Modified Username Field Change
2017-08-23 21:50 mjo New Issue
2017-08-24 10:58 joergs Severity minor => feature
2017-08-24 10:58 joergs Status new => acknowledged
2017-09-20 22:17 mjo Note Added: 0002741
2021-08-22 10:58 mschiff Note Added: 0004215
2021-09-06 12:22 mschiff Note Added: 0004250
2021-09-14 13:53 bruno-at-bareos Note Added: 0004264
2021-09-14 14:21 bruno-at-bareos Note Added: 0004265
2021-09-15 10:22 mschiff Note Added: 0004266
2021-09-21 16:14 arogge Note Added: 0004271
2021-09-22 01:19 mjo Note Added: 0004272
2021-09-22 10:53 arogge Note Added: 0004273
2021-09-22 13:42 mschiff Note Added: 0004274
2021-09-22 14:52 mjo Note Added: 0004275
2021-12-21 13:56 arogge Relationship added related to 0001289
2021-12-21 14:02 arogge Assigned To => arogge
2021-12-21 14:02 arogge Status acknowledged => resolved
2021-12-21 14:02 arogge Resolution open => fixed
2021-12-21 14:02 arogge Fixed in Version => 21.0.0
2021-12-21 14:02 arogge Note Added: 0004396
2021-12-21 14:02 arogge Status resolved => closed