Security Concerns about the nsca daemon

Andreas Ericsson ae at op5.se
Tue Feb 21 15:34:22 CET 2006


Marc Haber wrote:
> On Tue, Feb 21, 2006 at 01:48:14AM +0100, Andreas Ericsson wrote:
> 
>>Marc Haber wrote:
>>
>>>I'm having a headache about using nsca to receive passive service
>>>checks. My concern is possible bugs which could lead to a local user
>>>compromise on the nagios host, which in turn could be escalated to
>>>root privileges by exploiting one of the numerous kernel bugs that
>>>today's Linux systems are plagued with.
>>>
>>>Since Nagios systems are usually allowed to connect to important
>>>systems to be able to conduct active service checks, the nagios host
>>>could then be abused to stage attacks against productive services
>>>holding valuable data.
>>>
>>>I would be more comfortable if it would be easily possible to run nsca
>>>chrooted. If the chroot is sufficiently minimal, exploting privilege
>>>escalation bugs from inside the chroot is significantly harder than if
>>>a full system including all binaries would be visible.
>>>
>>
>>Normally, /var/empty is used. It is supposed to have mode 01700 and be 
>>owned by root:root, which means it's as secure as it can get.
> 
> 
> The directory to chroot to should be configurable at compile time to
> help FHS-compliant distributions. On Debian, the directory to use
> would be /var/run/nsca, by example of sshd.
> 

At run-time, I'd say.

> 
>>>I am dreaming of an option which would make nsca chroot itself after
>>>starting up like bind9 does. This greatly decreases the number of
>>>files that need to be visible in the chroot, but nsca would need to be
>>>started with root privileges to allow it to chroot itself. It would
>>>then need to drop privileges after chrooting itself. The code needed
>>>to do so can probably be pulled from bind.
>>>
>>
>>I've got a nifty snippet that does this in a secure fashion that also 
>>prevents chroot jail breakouts (which bind had troubles with at first). 
>>I'm not sure how portable it is though, but for the nsca daemon that 
>>shouldn't be extremely important.
> 
> 
> It would be great to have that patched into nsca. Portability issues
> can be detemined and worked out by use of the Debian buildd network
> and the experimental distribution. Since both sean and me are members
> of the Debian Nagios team, Debian infrastructure is available for this
> effort.
> 

That's good to know. I'll let you know when I have something worth 
looking at.

> 
>>>For the interface to nagios, it would be extremely handy if the nagios
>>>daemon would be able to establish more than one named pipe as a
>>>command file. In that case, one could place one extra named pipe
>>>inside the nsca chroot, allowing nsca and nagios to communicate
>>>without any extra scripting effort.
>>>
>>
>>This is trickier. Currently, FIFO is emptied continuously in a separate 
>>thread that *only* polls the socket. Creating another thread to check 
>>one more FIFO is not a good idea, as lots of code need to be made 
>>reentrant (i.e. they need to be capable of safely executing in several 
>>threads at one time).
> 
> 
> And they're hard to make reentrant?
> 

Very much so, I'm afraid. Nagios was originally written as a 
single-thread program. Such are fairly easy to write because there are 
few constraints, but the monolithic design unfortunately means that 
adding constraints now that it's done means rewriting a fairly big chunk 
of code. It's further complicated by the fact that some thread-libraries 
(and standard C libraries) will allow things others will not, so a bug 
can go unnoticed until you try to install on some system you haven't tested.

> 
>>Another option is to make the current thread 
>>multiplex several FIFO's, but that too is a far from simple solution.
> 
> 
> Sean has pointed out a way to do this which doesn't look that
> complicated.
> 

True. For the archives:
select() won't work on fifo's with most filesystems, because a read(2) 
on them never blocks but rather causes it to read the EOF. poll(2) works 
differently on Linux, which detects FIFO's inside the system call and 
doesn't return until there's input on the FIFO or the timeout is 
reached. I'm not sure how well it works on other systems.

> 
>>Fortunately, it's also completely unnecessary. A process can open(2) a 
>>file, FIFO or socket prior to doing a chroot and then write(2) to it 
>>from the chroot jail, even though the file (or FIFO, or socket) doesn't 
>>reside anywhere below that path.
> 
> 
> As sean has already said, this breaks as soon as the nagios daemon
> re-creates the named pipe for some reason.
> 

True. That means setting the jail-dir at compile-time goes out the 
window though. It would be better to grok the jail from the nagios 
config file.

> 
>>>Unfortunately, I do not have the coding expertise to submit a patch.
>>>
>>>I would therefore like to see my suggestion discussed - maybe I am
>>>completely misled. Any comments will be greatly appreciated.
>>>
>>
>>I do, and this suggestion is a good one. I'll see what I can do, 
>>although I'm fairly drowning in work at the moment (as usual).
> 
> 
> If I can help in any way, please say so.
> 

I will, when I have something.


-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642




More information about the Developers mailing list