Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 629282 - net-analyzer/icinga: root privilege escalation via init script
Summary: net-analyzer/icinga: root privilege escalation via init script
Status: RESOLVED DUPLICATE of bug 638186
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Auditing (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Security Audit Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-08-29 12:56 UTC by Michael Orlitzky
Modified: 2017-12-05 01:29 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Orlitzky gentoo-dev 2017-08-29 12:56:46 UTC
After installing net-analyzer/icinga, its configuration file /etc/icinga/icinga.cfg is owned (and writable) by the "icinga" user. In the init script, we have,

  start_pre() {
      checkpath -d -o icinga:icinga \
                      $(get_config temp_path) \
                      $(dirname $(get_config lock_file)) \
                      $(dirname $(get_config log_file)) \
                      $(dirname $(get_config status_file))
      checkpath -f -o icinga:icinga $(get_config log_file)
      rm -f $(get_config command_file)
  }

But what does get_config do? It reads data from /etc/icinga/icinga.cfg! So to gain root, all the icinga user has to do is e.g. set the temp_path to /root, and the next time the init script is started, checkpath will make /root owned by icinga:icinga.
Comment 1 Matthew Thode ( prometheanfire ) archtester Gentoo Infrastructure gentoo-dev Security 2017-08-31 16:50:10 UTC
Well, we could change the ownership of the directory and the file to root.

I cannot do anything while this bug is locked down, so unlock it and I'll fix it, or you can fix it.
Comment 2 Michael Orlitzky gentoo-dev 2017-08-31 17:15:40 UTC
(In reply to Matthew Thode ( prometheanfire ) from comment #1)
> Well, we could change the ownership of the directory and the file to root.
> 
> I cannot do anything while this bug is locked down, so unlock it and I'll
> fix it, or you can fix it.

I'm no longer able to modify the bug's visibility =/

I found this while I was looking for init scripts with vulnerable "get_config" functions, but a day later, I found a much bigger issue with nagios-core (bug 629380) that supersedes this one. Since that bug is public, this one might as well be.

Basically, all of the files installed by nagios (and icinga) have the wrong ownership. For example, so long as "icinga" owns the daemon executable,

  $ ls /usr/sbin/icinga
  -rwxr-xr-x 1 icinga icinga 760K 2017-08-31 13:11 /usr/sbin/icinga

there's no point in fixing the config file -- he can gain root whenever the service is started.

I think that *all* of the installed files should be owned by root, but maybe there's an edge case I'm missing. The masked nagios-core-4.3.4 in the tree is an experiment to see what I can get away with -- the same thing will probably be right for icinga.
Comment 3 Matthew Thode ( prometheanfire ) archtester Gentoo Infrastructure gentoo-dev Security 2017-08-31 17:23:27 UTC
ya, the way I packaged icinga was to basically copy the nagios ebuild, so that makes sense.  icinga is a fork of nagios (icinga2 is a rewrite).  I'll open this bug up then.  I'm cc'd on the other bug, but let me know what you find for perms.  I migrated to icinga2 a while ago so it's harder for me to test.
Comment 4 Matthew Thode ( prometheanfire ) archtester Gentoo Infrastructure gentoo-dev Security 2017-12-03 03:37:52 UTC
changed it to root:root in 1.14.0-r1 (in the dependant bug), not sure if we want to close this in favor of that one.
Comment 5 Michael Orlitzky gentoo-dev 2017-12-05 01:29:52 UTC
Yeah, the problem turned out to be a lot larger and is covered in the other bug.

*** This bug has been marked as a duplicate of bug 638186 ***