Security Concerns about the nsca daemon

[Andreas Ericsson]

Marc Haber wrote:
> On Tue, Feb 21, 2006 at 05:35:53PM +0100, Andreas Ericsson wrote:
> 
>>Marc Haber wrote:
>>
>>>On Tue, Feb 21, 2006 at 03:34:22PM +0100, Andreas Ericsson wrote:
>>>
>>>
>>>>Marc Haber wrote:
>>>>
>>>>
>>>>>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.
>>>
>>>
>>>Even better, one would have to worry about input processing though.
>>>
>>
>>Not sure I follow you there.
> 
> 
> A compile-time setting will end up in a #define, so one can assume
> that whatever is there isn't maliciously set.  For a run-time setting,
> one must verify that the parameter is acutally a valid path name, that
> no wildcard or relative path stunts are pulled, and one needs to go
> through the hassle of string handling in C, which is always a source
> for buffer overflow errors, which will have bad consequences at the
> time of option parsing since we are not yet chrooted and still hold
> root privileges at that point.
> 

No we don't. All we need to do is

	path = slurp_path(nagios_config_file);

	if (chdir(path) < 0)
		crash_horribly("Unable to chdir() to '%s'\n", path);

chdir() is a system call so shell metacharacters and the like are 
completely ignored.

Nagios doesn't care if it's a relative path or riddled with symlinks 
(well, it does, since it chdir()'s to '/' prior to opening anything, I 
think), so we shouldn't either. It doesn't really matter one way or another.

> 
>>>>>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.
>>>
>>>That, however, rules out the possible simplest implementation of
>>>allowing multiple command_file directives in nagios.cfg since nsca
>>>won't be able to grok its chroot location from there.
>>
>>But if we do this there's no need to support multiple command_file 
>>directives. It's the cleanest solution.
> 
> 
> Having multiple command_file directives is desireable, IMO, since one
> could then run multiple instances of programs that can deliver
> external commands (web, wap, nsca, e-mail, irc etc) to nagios, all of
> them potentially chrooted. It's like adapting nagios for a general
> thing, not just for nsca.
> 

Nothing prevents multiple daemons running in the same chroot() jail. The 
jail is still as secure as it would be if just one daemon was running 
inside it.

> otoh, all of these interfaces could lead to send_nsca being called,
> which would reduce the number of nagios interfaces to one: nsca.
> 

Now I don't follow you again. Do you mean to call send_nsca from the 
same host nsca is running on? That doesn't really make sense, since 
programs calling send_nsca either must reside in a fully featured chroot 
jail (i.e., one with a linker, libraries, /proc filesystem and whatnot) 
or have send_nsca statically linked.

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