NRPE enhancement

[Tom Welsh]

In my humble opinion an option that allows an arbitary command to be
executed and which by "default" is switched off is an accident waiting
to happen.

It only takes 1 security breach via a plugin to completely destroy the
good name Nagios and its associated plugins have. 

There is a good truism that states "good news travels fast, but bad news
travels even faster"

I for one would not be too happy having a command available on my
network, trusted or not that would allow commands to be executed
remotely pon a box. For one. It’s the kind of thing im always looking
for when im "playing on my " networks.

Well that’s my two cents worth

Cheers

Tom Welsh
twelsh at square-box.com

-----Original Message-----
From: nagios-users-admin at lists.sourceforge.net
[mailto:nagios-users-admin at lists.sourceforge.net] On Behalf Of Dave
Viner
Sent: 28 December 2002 21:46
To: Ethan Galstad; nagios-users
Subject: RE: [Nagios-users] NRPE enhancement

These are excellent arguments for not incorporating the enhancement I am
suggesting.  However, I suspect that there are lots of installations of
Nagios and NRPE that run on completely trusted network.  (Or the risk of
network intrusion through NRPE is worth the benefit of reduced
configuration
management.)

What do you think about incorporating this enhancement but have it
turned
off by default, and enabled only at configure time?

dave


-----Original Message-----
From: nagios-users-admin at lists.sourceforge.net
[mailto:nagios-users-admin at lists.sourceforge.net]On Behalf Of Ethan
Galstad
Sent: Friday, December 27, 2002 7:38 PM
To: nagios-users
Subject: RE: [Nagios-users] NRPE enhancement


There are several reasons why I have not added support for arguments
to checks in NRPE.  Most have been touched on in the past on the
list, but I'll reiterate them here.  The main issue is not overruning
the 2K packet that the check_nrpe plugin and NRPE daemon pass back
and forth - that can be easily avoided...

1.
Users connecting to the NRPE are not authenticated.  Sure, you can
restrict connection based on IP address using TCP wrappers, but they
are still not authenticated.  Also, I am not too familiar with IP
spoofing, but I'm sure its possible for someone to fake the
originating address of the connection and get the NRPE daemon to
accept the packet and execute the necessary plugin without too much
trouble.

2.
Some plugins (like check_dhcp) may (have to) be installed suid root.
Regardless of what user the NRPE daemon is running as, these plugins
will be executed with higher privs.

3.
Plugins can be made to segfault under the right conditions.  Sure, we
can try and eliminate this possibility, but it will probably always
exist to some extent since many plugins call system commands to get
their data.

---

Most remote exploits rely on buffer overflows/segfaults to get their
work done, so allowing unauthenticated users to pass arbitrary
arguments/data to plugins that might be running suid commands is a
very bad idea indeed.

Stunnel would provide some security, but there is no guarantee that
everyone would use it.  There would undoubtably be many people that
would put off implementing it until they finished "testing" NRPE.  In
the worst case, they might never get around to implementing stunnel
at all.  In the likely best case scenario, there is at least a window
of opportunity.  I just don't want to be responsible for the possible
carnage that happens at that point. :-)

Also, incorporating native encryption into NRPE involves reinventing
the wheel called "check_by_ssh", so I'm really interested in doing
that.



On 27 Dec 2002 at 13:46, Carroll, Jim P [Contractor] wrote:

> 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
> _______________________________________________
> Nagios-users mailing list
> Nagios-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagios-users
>



Ethan Galstad,
Nagios Developer
---
Email: nagios at nagios.org
Website: http://www.nagios.org



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