NRPE enhancement

[Carroll, Jim P [Contractor]]

I'm not a C programmer by profession, so I defer your query to those who
have a strong background, both in C code and system/network security.  It
does presume that every other link in the chain is bulletproof.  [Insert
ObRef to Bugtraq here.]

At any rate, I'm curious to hear why Ethan didn't choose that approach to
begin with.

jc

> -----Original Message-----
> From: Dave Viner [mailto:dviner at yahoo-inc.com]
> Sent: Friday, December 27, 2002 12:49 PM
> To: Nagios-users at lists.sourceforge.net
> Subject: RE: [Nagios-users] NRPE enhancement
> 
> 
> This sounds interesting, but I have a question about the 
> security implications of this code.  I'm not a security 
> expert, so please excuse the somewhat basic question.  The 
> struct packet as defined in common/common.h has an argv 
> member which is a character array of length 2048.   I believe 
> this means that if the incoming packet has an argv member 
> whose length is greater than 2048 chars, then the  
> 	rc=recvall(sock,(char 
> *)&receive_packet,&bytes_to_recv,socket_timeout);
> should fail, should it not?  
> 
> However, I think your suggestions regarding stunnel, and 
> encryption are good ones, regardless of the inclusion of this code.
> 
> thanks
> 
> dave
> 
> 
> -----Original Message-----
> From: Carroll, Jim P [Contractor] [mailto:jcarro10 at sprintspectrum.com]
> Sent: Friday, December 27, 2002 10:20 AM
> To: 'Dave Viner'; Nagios-users at lists.sourceforge.net
> Subject: RE: [Nagios-users] NRPE enhancement
> 
> 
> I think it's a good idea, but with the following provisions:
> 
> - This should not be enabled by default.
> 
> - The configure script, the Makefile and any/all NRPE docs 
> should explicitly
> state the security risks in forcing the non-default (added feature)
> behaviour.
> 
> - If the daemon is compiled with this option, anytime the 
> daemon starts, it
> should briefly mention that it has been compiled for this 
> behaviour, and a
> quick remark about the increased risks.  (Sent to stderr if 
> standalone, else
> sent to syslog if running under (x)inetd).  It should scream 
> loud and clear
> if it's started under root; preferably it would simply not 
> run as root, full
> stop.
> 
> - Perhaps a reference to implementing NRPE with stunnel (and 
> only permitting
> connections from localhost, as defined in nrpe.cfg) would be 
> desireable.
> 
> I'm not a security guru, but it seems to me that facilitating 
> this feature
> would open oneself up to a buffer overflow attack.  If you're 
> on a trusted
> network, it's a non-issue.
> 
> On a related note, I'd be much more comfy with this feature 
> if there were a
> facility to enforce some level of native encryption, such as 
> what NSCA uses.
> If you don't have the keys to the house, you get dropped on 
> the floor.  (I
> have a similar wish for NSClient.)
> 
> Food for thought.
> 
> jc
> 
> > -----Original Message-----
> > From: Dave Viner [mailto:dviner at yahoo-inc.com]
> > Sent: Friday, December 27, 2002 11:48 AM
> > To: Nagios-users at lists.sourceforge.net
> > Subject: RE: [Nagios-users] NRPE enhancement
> > 
> > 
> > In order to clarify the idea that I'm proposing, I've made a 
> > patch to the nrpe source that implements what I'm describing. 
> >  This patch is made against the nrpe-1.5.tar.gz from sourceforge.
> > 
> > Essentially, these changes allow us to specify in the 
> > nrpe.cfg file lines like this:
> >   command[check_disk_gen]=/usr/local/libexec/nagios/check_disk
> > 
> > Then when invoking check_nrpe, you can invoke it like this:
> >   ./check_nrpe 127.0.0.1 -V 2 -c check_disk_gen -a "-w 50000 
> > -c 10000 -p /dev/ad0s1e"
> > 
> > And the effect is that /usr/local/libexec/nagios/check_disk 
> > is invoked with the -w 50000 -c 10000 -p /dev/ad0s1e as the 
> > argument string.  For example:
> > 
> > ~/nagios/nrpe-1.5.new/src>./check_nrpe 127.0.0.1 -V 2 -c 
> > check_disk_gen -a "-w 50000 -c 10000 -p /dev/ad0s1e"
> > DISK OK - [1484108 kB (9%) free on /dev/ad0s1e]
> > ~/nagios/nrpe-1.5.new/src>
> > 
> > I think this is really useful and would greatly reduce the 
> > size of the nrpe.cfg and, more importantly, would reduce the 
> > number of times you'd need to modify that configuration file. 
> >  Instead the modifications would occur on the centralized 
> > Nagios server's configuration file.
> > 
> > What does everyone think?  Should we add this to the main 
> > source for NRPE-1.6?
> > 
> > dave
> > 
> > 
> > -----Original Message-----
> > From: nagios-users-admin at lists.sourceforge.net
> > [mailto:nagios-users-admin at lists.sourceforge.net]On Behalf Of 
> > Dave Viner
> > Sent: Monday, December 23, 2002 8:51 AM
> > To: Naios Users
> > Subject: RE: [Nagios-users] NRPE enhancement
> > 
> > 
> > Hi Rue,
> > 	Security is a great reason for limiting the commands 
> > that NRPE is able to execute.  But my suggested enhancement 
> > wouldn't allow NRPE to execute any command that isn't listed 
> > in the cfg file.  That is, the NRPE would still need to find 
> > the path to the executable in the nrpe.cfg file, then use any 
> > remaining information as arguments passed to the executable.  
> > It is true that this is less secure that forcing the entire 
> > command line (executable and arguments) in the config file.  
> > But, so long as the executables are well authored and handle 
> > unexpected arguments well, I think this enhancement would not 
> > significantly decrease security.  Do you think that 
> > specifying arguments would make NRPE significantly less secure?
> > 
> > 
> > Dave
> > 
> > 
> > -----Original Message-----
> > From: nagios-users-admin at lists.sourceforge.net
> > [mailto:nagios-users-admin at lists.sourceforge.net]On Behalf Of 
> > Rue Turner
> > Sent: Friday, December 20, 2002 1:33 PM
> > To: Naios Users
> > Subject: Re: [Nagios-users] NRPE enhancement
> > 
> > 
> > dave,
> > 
> > I think the reson for this choice of configuration is 
> security. If the
> > nrpe was allowed to run whatever it was asked it would be easy to
> > compromise your machines. This way although your configs are 
> > hefty (mine
> > have almost a hundred lines in) you can only ask it to run 
> > commands from
> > this library.
> > 
> > rue
> > 
> > 
> > On Fri, 2002-12-20 at 17:35, Dave Viner wrote:
> > > Hi,
> > > 	I'd like to suggest an enhancement to NRPE, and if 
> > people think this is a
> > > good idea, I'll try to make a patch to support my 
> > suggestion.  Currently the
> > > nrpe.cfg file specifies all the commands in this fashion:
> > > 	
> > command[check_disk1]=/usr/local/nagios/libexec/check_disk 80 
> > 95 /dev/hda1
> > > As result of this design is that if you want to check 
> something like
> > > /dev/hda1 and /dev/hdb1, you need two seperate lines in the 
> > nrpe.cfg file.
> > > 	So, I'd like to propose that we extend NRPE to allow 
> > for the arguments to a
> > > command to be specified by the central Nagios server 
> > instead of in the
> > > nrpe.cfg.  The idea is that the nrpe.cfg would have one 
> > command line which
> > > maps a key, 'check_disk', to a local executable,
> > > '/usr/local/nagios/libexec/check_disk'.  The rest would be 
> > specified from
> > > the central Nagios server in some manner.
> > > 	I think this would great simplify the nrpe.cfg files, 
> > and reduce a lot of
> > > redundant command definitions that differ only in the 
> arguments they
> > > require.  Also, it would mean that you'd need to update 
> > your nrpe.cfg very
> > > rarely.  In fact, you'd only need to update it when you add 
> > a new plugin.
> > > 	I don't have a concrete suggestion for implementing 
> > this yet, because I
> > > want to see if the community is interested in this idea 
> > first.  Has this
> > > idea been suggested previously?  Is anyone currently 
> > interested in the idea
> > > or would I be the only consumer of such a service?
> > > 
> > > thanks
> > > dave
> > > 
> > > 
> > > 
> > > -------------------------------------------------------
> > > This SF.NET email is sponsored by:  The Best Geek Holiday Gifts!
> > > Time is running out!  Thinkgeek.com has the coolest gifts for
> > > your favorite geek.   Let your fingers do the typing.   Visit Now.
> > > T H I N K G E E K . C O M        http://www.thinkgeek.com/sf/
> > > _______________________________________________
> > > Nagios-users mailing list
> > > Nagios-users at lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/nagios-users
> > 
> > 
> >                       r u e  t u r n e r
> >   · t · h · i · n · l · a · y · e · r · 
> >  
> > -- index, n.: Alphabetical list of words of no possible 
> interest where
> > an alphabetical list of subjects with references ought to be.
> > 
> > 
> > -------------------------------------------------------
> > This SF.NET email is sponsored by:  The Best Geek Holiday Gifts!
> > Time is running out!  Thinkgeek.com has the coolest gifts for
> > your favorite geek.   Let your fingers do the typing.   Visit Now.
> > T H I N K G E E K . C O M        http://www.thinkgeek.com/sf/
> > _______________________________________________
> > Nagios-users mailing list
> > Nagios-users at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/nagios-users
> > 
> > 
> > 
> > 
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Nagios-users mailing list
> > Nagios-users at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/nagios-users
> > 
> > 
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Nagios-users mailing list
> Nagios-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagios-users
> 


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf