New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Root privilege escalation via insecure executable/config permissions (CVE-2017-14312) #424
Comments
|
I'm going to commit a masked version to gentoo and ask for help testing. My own limited testing has shown that most things continue to work if I run the following makefile targets with empty
For us, that's everything that we run except After we run all of those install targets, there are a few things to fix up:
Aside from that, I was able to start up the daemon and run the web interface. Back to testing... |
|
The only reason that's standing out at the moment for the configs to be owned by the specified user and group is that a lot of systems use those particular users/groups as the users and groups who own the configs! In the case of the group - you give specific users group access and then they are your monitoring team - they do not need root in order to update the configuration. Also, there are a few third party utilities that rely on the configs being writable by the user they run as. It is not uncommon to add the apache user to the nagios group to allow another web UI to adjust the configuration. Regardless - I look forward to your test results. If you'd post a link to the source here I wouldn't mind taking a look as well. |
|
Everything works fine on our installation. I removed I haven't modified the source to accomplish any of that -- I'm just running To have non-root users update the configuration is a legitimate use case, but the group that nagios runs as must be different from the group that can update the configuration. Otherwise, "nagios" can just upgrade himself to root. And I don't think there's a legitimate case to have the nagios user own anything at all except the stuff he creates under e.g. Our Gentoo bug is here: https://bugs.gentoo.org/show_bug.cgi?id=629380 Since everyone is running nagios as
Basically I would try to fix the immediate problem in (1), and then work on adding back the ability to have a "configuration editor" group in (2) through (5). |
I was just thinking about this in the shower (where all good work gets done) and even in the intended use case, this allows anyone in the So, I amend my previous comment -- I don't know what to do about that. Would it be safe if |
The obvious problem with that solution doesn't seem to be a problem: if I try to set |
|
There are use cases like in Nagios XI where the Core Configuration Manager allows you to edit |
|
crap =( I think it's pretty clear now how any non-root user who can edit
I know the first two are bad, and the third is a lot of work -- I'm just throwing stuff out as it comes to mind. |
|
We talked about this internally a bit today, and quite frankly I think your
third point is the one we landed on. Also, having a completely separate
group for config sounds reasonable, and it wouldn't be too terribly
difficult to port to XI once it's complete in core.
…On Sep 11, 2017 5:17 PM, "Michael Orlitzky" ***@***.***> wrote:
@box293 <https://github.com/box293>
crap =(
I think it's pretty clear now how any non-root user who can edit
nagios.cfg can easily gain root. I'm not familiar with Nagios XI, but
someone who is will have to evaluate the impact of this on it and similar
products that expect to be able to write to nagios.cfg.
- Can they live without that ability?
- Should we give up the charade, and ask those people to run their web
servers as root if they require that ability?
- Should the nagios_user and nagios_group parameters be removed from
the configuration file, and made command-line-only options? If we did the
same thing with the lock_file parameter and everything else that gets
used while the daemon is still root, then we could make it so that
nagios.cfg is read after dropping privileges. Then it doesn't matter
who can edit the file.
I know the first two are bad, and the third is a lot of work -- I'm just
throwing stuff out as it comes to mind.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#424 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AP4QcQ1AILPnysazfLP_1rTttLHQYXzUks5shbFegaJpZM4PHTlI>
.
|
|
Now. It's fixed? |
|
I am wondering if this is a issue in my install. I have nagios3 running as nagios user. Particularly this statement "The fundamental problem is that the nagios daemon is intended to be launched as root" - this is not true in my install of nagios core 3.5.1 . Can someone please explain the above quoted statement? here is a output of the nagios process running in the system: |
|
@rakesh-patnaik your |
|
we use the SysV init to start nagios3. |
Then you're safe from this, since you're using sudo to drop privileges before the daemon even starts. Just be sure you never execute Most people would just add the "nagios3" service to the default run level, and that's who this vulnerability affects. |
|
@orlitzky thanks for the clarification. appreciate your bringing this issue to attention and resolving it for those affected. |
|
Is there going to be a new nagios version once this issue is closed? |
|
Yes. 4.4.0 contains the fix. It was actually going to be released yesterday, but I've gotten tied up in other things. I'm anticipating releasing it Monday, as long as there are no blocking breakages discovered from now until then :) |
|
Nope. Ignore me. For some reason I thought this was a different issue. I'll take another look at this, as it's fallen off of the radar for a bit. |
|
Okay, so re-reading it, I have a bit of information regarding the issue. We'll add a configure group (which will likely default to the specified nagios group [so as to avoid breaking backwards compatibility where possible]) and a configure user - but this won't be done until a major release. I'll add it to Core 5 for now, as it isn't so much work as to not make it in that release. There have already been quite a lot of "breaking changes" released in in the last two enhancement/minor versions, I'd like that to stop where possible. By allowing configure flags to overwrite default behavior, the packagers for different distributions can use them as they see fit. @orlitzky How does this sound as an actual achievable goal? |
|
The timeline is fine, but the devil is in the details with regards to the implementation. Adding another user/group doesn't help if they can still edit the configuration file to say e.g. |
|
Hi, was this issue ever addressed? Is this CVE fixed? Thanks in advance! |
This is still a work-in-progress; our Nagios installation is pretty simple so I'll have to do some testing to make sure none of my proposed solutions break things.
Problem
When Nagios is configured, the user and group under which it will run are chosen:
Both default to "nagios" -- the following is from
configure.ac:Immediately after those two lines, this appears:
Those
INSTALL_OPTSare then used in every invocation of theinstallcommand during installation.This can lead to a root exploit in at least two ways. The fundamental problem is that the nagios daemon is intended to be launched as root, but the daemon itself and some critical configuration files are writable (in an exploitable way) by the restricted nagios user.
The binary for the daemon itself, i.e.
/usr/sbin/nagiosis owned by the$nagios_user, but will be run as root. The$nagios_usercan overwrite that binary with whatever he wants, and root will run it.The configuration file
nagios.cfgspecifies the user and group that nagios will run as, but is owned by that same$nagios_user. He can editnagios.cfghimself, and setnagios_user=root,nagios_group=root. The command definition fileobjects/commands.cfgis also owned by$nagios_user, and he can place whatever commands in there he likes. Considering that the daemon will run as root the next time it is launched, this will also let the$nagios_usergain root eventually.Resolution
At the very least,
nagios.cfgand the executables must not be writable by anyone other than root. To ensure that the executables aren't owned by the nagios user, it suffices to setINSTALL_OPTS=""inbase/Makefile.inandcgi/Makefile.in.For the configuration file, I'm not so sure: is there a reason for the other configs (besides
nagios.cfg) to be owned by the$nagios_userand$nagios_grp?The text was updated successfully, but these errors were encountered: