View Issue Details

IDProjectCategoryView StatusLast Update
0000847bareos-core[All Projects] Generalpublic2017-09-20 22:17
ReportermjoAssigned To 
Status acknowledgedResolutionopen 
Product Version13.2.4 
Fixed in Version 
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.
bareos-master: impactyes
bareos-master: action
bareos-19.2: impact
bareos-19.2: action
bareos-18.2: impact
bareos-18.2: action
bareos-17.2: impact
bareos-17.2: action
bareos-16.2: impactyes
bareos-16.2: action
bareos-15.2: impactyes
bareos-15.2: actionnone
bareos-14.2: impactyes
bareos-14.2: actionnone
bareos-13.2: impactyes
bareos-13.2: actionnone
bareos-12.4: impactyes
bareos-12.4: actionnone




2017-09-20 22:17

reporter   ~0002741

This has been assigned CVE-2017-14610.

Issue History

Date Modified Username Field Change
2017-08-23 21:50 mjo New Issue
2017-08-24 10:58 joergs bareos-master: impact => yes
2017-08-24 10:58 joergs bareos-16.2: impact => yes
2017-08-24 10:58 joergs bareos-15.2: impact => yes
2017-08-24 10:58 joergs bareos-15.2: action => none
2017-08-24 10:58 joergs bareos-14.2: impact => yes
2017-08-24 10:58 joergs bareos-14.2: action => none
2017-08-24 10:58 joergs bareos-13.2: impact => yes
2017-08-24 10:58 joergs bareos-13.2: action => none
2017-08-24 10:58 joergs bareos-12.4: impact => yes
2017-08-24 10:58 joergs bareos-12.4: action => none
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